| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
breakpoint if no breakpoint id is specified.
<rdar://problem/17885160>
llvm-svn: 216637
|
| |
|
|
| |
llvm-svn: 216630
|
| |
|
|
|
|
|
|
|
|
|
|
| |
such. This was causing:
(lldb) disassemble -n '-<TAB>
to crash.
<rdar://problem/18134531>
llvm-svn: 216626
|
| |
|
|
| |
llvm-svn: 216612
|
| |
|
|
|
|
|
|
|
|
|
| |
This is a lightweight wrapper around a pid. It is intended to be
lightweight enough to serve as a replacement anywhere we currently
store a pid. It provides convenience methods and common process
operations.
This patch does not yet make use of HostProcess anywhere.
llvm-svn: 216607
|
| |
|
|
|
|
|
|
|
| |
LLDB had implemented its own DynamicLibrary class for plugin
support. LLVM has an equivalent mechanism, so this patch deletes
the duplicated code in LLDB and updates LLDB to reference the
mechanism provided by LLVM.
llvm-svn: 216606
|
| |
|
|
| |
llvm-svn: 216603
|
| |
|
|
|
|
|
|
|
|
|
| |
I copied this originally based on what debugserver was doing. This appears to
be incorrect and unncessary for Linux. The LinuxSignals on the lldb side
don't look for these and therefore they get handled incorrectly.
Leaving the hook in place since I think darwin will continue to need to
translate those signal numbers.
llvm-svn: 216564
|
| |
|
|
|
|
|
|
| |
See http://reviews.llvm.org/D5078.
Change by Paul Osmialowski.
llvm-svn: 216559
|
| |
|
|
|
|
|
|
|
|
| |
HostInfoBase.
See http://reviews.llvm.org/D5070.
Change by Paul Osmialowski.
llvm-svn: 216556
|
| |
|
|
|
|
|
|
| |
See http://reviews.llvm.org/D5069.
Change by Paul Osmialowski.
llvm-svn: 216554
|
| |
|
|
|
|
|
|
| |
See http://reviews.llvm.org/D5073.
Change by Paul Osmialowski.
llvm-svn: 216553
|
| |
|
|
|
|
|
|
| |
Add entries to core_definitions and elf_arch_entries for
those variants. Select the subtype for the variant by parsing
the e_flags field of the elf header.
llvm-svn: 216541
|
| |
|
|
|
|
| |
know to generate synthetic children
llvm-svn: 216513
|
| |
|
|
|
|
|
|
|
|
| |
creating the ModuleSpec to load the core file - we won't have a fat
core file and we can end up with cpu subtype mismatches if the core
file header isn't written out completely accurately. We need to
be a little loose in this particular case.
<rdar://problem/17843388>
llvm-svn: 216498
|
| |
|
|
|
|
| |
always for C++, and this API claims to be general enough that it should not drop C++ usability on the floor for no good reason. Fix it with an explicit offset argument
llvm-svn: 216487
|
| |
|
|
|
|
|
| |
This updates the DWARF language identifiers to include recent additions to
the DWARF 5 specification (draft).
llvm-svn: 216486
|
| |
|
|
|
|
| |
type. Note that in this commit, the term synthetic child is not meant to refer to data formatters, but to the programmatically-generated children stored inside a ValueObject itself
llvm-svn: 216483
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This change addresses this bug:
http://llvm.org/bugs/show_bug.cgi?id=20755
This change:
* Modifies llgs to send triple instead of cputype and cpusubtype when not on Apple platforms in qProcessInfo.
* Modifies lldb's GDBRemoteCommunicationClient to handle the triple returned from qProcessInfo if given.
When given, it will prefer to use triple over cputype and cpusubtype.
* Adds gdb-remote protocol tests to verify that cputype and cpusubtype are specified on darwin, and that triple is specified on Linux.
llvm-svn: 216470
|
| |
|
|
|
|
| |
DWARF2/3 compliant producers.
llvm-svn: 216440
|
| |
|
|
|
|
| |
changes.
llvm-svn: 216420
|
| |
|
|
|
|
|
|
| |
I wrote this originally as a part of an unwind library that was using
a different coding convention and some of that old style remained after
its integration into lldb.
llvm-svn: 216419
|
| |
|
|
|
|
|
|
| |
prints different plans for asynchronous and synchronous.
Change by Tong Shen.
llvm-svn: 216416
|
| |
|
|
|
|
|
| |
name/from-compiler settings to indicate that it was augmented
by assembly profiling.
llvm-svn: 216412
|
| |
|
|
|
|
|
|
|
|
| |
In practice, 64bit eh_frame is not used even for x86_64 binaries. The main reason is in eh_frame we almost always use pc-relative addressing, so addresses are within 32bits and gcc just sticks to 32bit eh_frame.
I generated 64bit eh_frame for Android Java runtime and unwind successfully in gdb, and in lldb with this patch.
Patch by Tong Shen.
llvm-svn: 216409
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We decided to use assmbly profiler instead of eh_frame for frame 0 because for compiler generated code, eh_frame is usually synchronous(a.k.a. only valid at call site); and we have no way to tell if it's asynchronous or not.
But for x86 & x86_64 compiler generated code:
1. clang & GCC describes all prologue instructions in eh_frame;
2. mid-function stack pointer altering instructions can be easily detected.
So we can grab eh_frame, and use assembly profiler to augment it into asynchronous unwind table.
This change also benefits hand-written assembly; eh_frame for hand-written assembly is often asynchronous,so we have a much better chance to successfully unwind through them.
Change by Tong Shen.
llvm-svn: 216406
|
| |
|
|
|
|
| |
HostInfo::GetLLDBPath() to return the directories in the FileSpec.m_directory field to match previous implementations. This change previously broke some path stuff in upstream branches.
llvm-svn: 216398
|
| |
|
|
|
|
|
|
|
|
| |
When building without XCode on sytems where these constants are
not in the system header (or I presume with older versions of XCode),
these are needed to make this file compile, since unlike most other
uses of MachO specific constants, these use the system headers
rather than the LLVM-defined ones.
llvm-svn: 216332
|
| |
|
|
|
|
| |
Linux build. Push a fix out. Patch suggested by Paul Osmialowski and Randy Smith
llvm-svn: 216323
|
| |
|
|
|
|
|
|
| |
install a crash handler.
<rdar://problem/18083226>
llvm-svn: 216309
|
| |
|
|
|
|
| |
object types
llvm-svn: 216305
|
| |
|
|
|
|
| |
putback data
llvm-svn: 216304
|
| |
|
|
| |
llvm-svn: 216286
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with binaries in the dyld shared cache (esp on iOS) where the file
address for the executable binary (maybe from memory, maybe from
an expanded copy of the dyld shared cache) is different from the
file address in the dSYM. In that case, ObjectFileMachO replaces
the file addresses from the original binary with the dSYM file
addresses (usually 0-based) -- lldb doesn't have a notion of two
file addresses for a given module so they need to agree.
There was a cache of file addresses over in the Symtab so I added
a method to the Module and the objects within to clear any file address
caches if they exist, and added an implementation in the Symtab
module to do that.
<rdar://problem/16929569>
llvm-svn: 216258
|
| |
|
|
| |
llvm-svn: 216247
|
| |
|
|
| |
llvm-svn: 216245
|
| |
|
|
|
|
|
| |
HostInfo et al changes from Zachary. Changes suggested by Zachary
- fixes the problems I was seeing.
llvm-svn: 216243
|
| |
|
|
|
|
|
|
|
| |
This should bring HostInfo up to 99% completion. The remainder
of code in Host will be split into instantiatable classes
representing host processes, threads, dynamic libraries, and
process launching strategies.
llvm-svn: 216230
|
| |
|
|
| |
llvm-svn: 216227
|
| |
|
|
| |
llvm-svn: 216210
|
| |
|
|
| |
llvm-svn: 216197
|
| |
|
|
|
|
|
|
| |
This continues the effort to get Host code moved over to HostInfo,
and removes many more instances of preprocessor defines along the
way.
llvm-svn: 216195
|
| |
|
|
|
|
|
|
|
|
|
| |
See this email thread:
http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140818/012487.html
This patch handles the case where the inferior process exits but leaves the ReadThread in a continuous loop reading from the communication pipe. On MacOSX, the ReadThread exits when it receives a 0 return value from the read due to EOF. On Linux the read returns -1 and sets errno to EIO error, this does not currently cause the thread to shutdown so it continues to read from the comm. In Communication::ReadThread I added a handler for eConnectionStatusError to disconnect and shutdown the thread.
Change by Alex Pepper.
llvm-svn: 216194
|
| |
|
|
|
|
| |
<rdar://problem/18084105>
llvm-svn: 216189
|
| |
|
|
|
|
|
|
| |
See http://reviews.llvm.org/D4969 for details.
Change by Paul Osmialowski.
llvm-svn: 216188
|
| |
|
|
|
|
|
|
| |
See http://reviews.llvm.org/D4803 for more details.
Change by Paul Osmialowski.
llvm-svn: 216185
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
inside classes as static local variables and remove the static
ivars. Subclasses should use the accessor functions."
This change moved global statics to function local statics, but
forgot to make the locals static in the function, breaking all
platforms. Furthermore, MSVC doesn't support thread-safe function
local statics, so any use of a function local static on non
primitive types is undefined behavior on MSVC.
Reverting due to the fact that it's broken on all platforms, but
would like to have a discussion about the thread-safety issue
before it goes back in.
llvm-svn: 216123
|
| |
|
|
|
|
|
|
|
|
| |
than one architecture select a compatible platform if all architectures match the same platform.
This helps us "do the right thing" when loading a file without having to specify an architecture.
<rdar://problem/18021558>
llvm-svn: 216115
|
| |
|
|
|
|
| |
static local variables and remove the static ivars. Subclasses should use the accessor functions.
llvm-svn: 216080
|
| |
|
|
| |
llvm-svn: 216077
|