Summary:
Since this is within the lldb namespace, the compiler tries to
export a symbol for it. Unfortunately, since it is inlined, the
symbol is hidden and this results in a mess of warnings when
building on OS X with cmake.
Moving it to the lldb_private namespace eliminates that problem.
Reviewers: clayborg
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D14417
llvm-svn: 252396
To do this I added a few new ways to determine the OS from PT_NOTE notes in the ELF file:
1 - Look for "LINUX" notes which indicate "linux" should be the OS
2 - Look through the "CORE" notes with NT_FILE as the type and sniff data from the paths listed in this section. On Ubuntu they contain "/lib/x86_64-linux-gnu" which has the triple and allows us to set "linux" as the OS in the architecture returned from ObjectFileELF::GetArchitecture().
Setting the OS correctly allows us to get the triple correct so we can extract registers without asserting and killing LLDB.
Also use the data from the NT_FILE to set the main executable if one isn't set in ProcessElfCore::DoLoadCore().
llvm-svn: 251537
* Remove an unneccessary re-computaion on arch spec from the ELF file
* Use a local cache to optimize name based section lookups in symtab
parsing
* Optimize C++ method basename validation with replacing a regex with
hand written code
These modifications reduce the time required to parse the symtab from
large applications by ~25% (tested with LLDB as inferior)
Differential revision: http://reviews.llvm.org/D14088
llvm-svn: 251402
* ArchSpec::MergeFrom() would erroneously promote an unspecified
unknown to a specified unknown when both the ArchSpec and the merged
in ArchSpec were both unspecified unknowns. This no longer happens,
which fixes issues with global module cache lookup in some
situations.
* Added ArchSpec::DumpTriple(Stream&) that now properly prints
unspecified unknowns as '*' and specified unknows as 'unknown'.
This makes it trivial to tell the difference between the two.
Converted printing code over ot using DumpTriple() rather than
building from scratch.
* Fixed up a couple places that were not guaranteeing that an
unspecified unknown was recorded as such.
llvm-svn: 250253
GP registers for o32 applications were always giving zero value because SetType() on the RegisterValue was causing the accessor functions to pickup the value from m_scalar of RegisterValue which is zero.
In this patch byte size and byte order of register value is set at the time of setting the value of the register.
llvm-svn: 249020
.ARM.exidx/.ARM.extab sections contain unwind information used on ARM
architecture from unwinding from an exception.
Differential revision: http://reviews.llvm.org/D13245
llvm-svn: 248903
The Go runtime schedules user level threads (goroutines) across real threads.
This adds an OS plugin to create memory threads for goroutines.
It supports the 1.4 and 1.5 go runtime.
Differential Revision: http://reviews.llvm.org/D5871
llvm-svn: 247852
SUMMARY:
This patch provides support for MIPS specific DT_MIPS_RLD_MAP_REL tag in LLDB.
This tag allows debugging of MIPS position independent executables and provides access to shared library information.
Reviewers: clayborg
Subscribers: mohit.bhakkad, sagar, jaydeep, lldb-commits
Differential Revision: http://reviews.llvm.org/D12794
llvm-svn: 247666
Change the mapping symbol handling to handle the case when the mapping
symbols are prefixed with an arbitrary prefix. This isn't strictly standard
compliance, but if all symbols in an object file is prefixed with objcopy
then the prefix will be added to the mapping symbol also. We still want to
treat these symbols as mapping symbols to get the correct address class data.
Differential revision: http://reviews.llvm.org/D12755
llvm-svn: 247400
* Create new dwo symbol file class
* Add handling for .dwo sections
* Change indexes in SymbolFileDWARF to store compile unit offset next to
DIE offset
* Propagate queries from dwarf compile unit to the dwo compile unit
where applicable
Differential revision: http://reviews.llvm.org/D12291
llvm-svn: 247132
Summary:
This doesn't exist in other LLVM projects any longer and doesn't
do anything.
Reviewers: chaoren, labath
Subscribers: emaste, tberghammer, lldb-commits, danalbert
Differential Revision: http://reviews.llvm.org/D12586
llvm-svn: 246749
These are 2 new value currently in experimental status used when split
debug info is enabled.
Differential revision: http://reviews.llvm.org/D12238
llvm-svn: 245931
Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files.
Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types.
Bulk renames for things that used to return a ClangASTType which is now CompilerType:
"Type::GetClangFullType()" to "Type::GetFullCompilerType()"
"Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()"
"Type::GetClangForwardType()" to "Type::GetForwardCompilerType()"
"Value::GetClangType()" to "Value::GetCompilerType()"
"Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)"
"ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()"
many more renames that are similar.
llvm-svn: 245905
The POSIX linker generally reports the load bias for the loaded
libraries but in some case it is useful to handle a library based on
absolute load address. Example usecases:
* Windows linker uses absolute addresses
* Library list came from different source (e.g. /proc/<pid>/maps)
Differential revision: http://reviews.llvm.org/D12233
llvm-svn: 245834
This was breaking disassembly for arm machines that we force to be
thumb mode all the time because we were only checking for llvm::Triple::arm.
i.e.
armv6m (ARM Cortex-M0)
armv7m (ARM Cortex-M3)
armv7em (ARM Cortex-M4)
<rdar://problem/22334522>
llvm-svn: 245645
for eh_frame and stabs register numberings. This is not
complete but it's a step in the right direction. It's almost
entirely mechanical.
lldb informally uses "gcc register numbering" to mean eh_frame.
Why? Probably because there's a notorious bug with gcc on i386
darwin where the register numbers in eh_frame were incorrect.
In all other cases, eh_frame register numbering is identical to
dwarf.
lldb informally uses "gdb register numbering" to mean stabs.
There are no official definitions of stabs register numbers
for different architectures, so the implementations of gdb
and gcc are the de facto reference source.
There were some incorrect uses of these register number types
in lldb already. I fixed the ones that I saw as I made
this change.
This commit changes all references to "gcc" and "gdb" register
numbers in lldb to "eh_frame" and "stabs" to make it clear
what is actually being represented.
lldb cannot parse the stabs debug format, and given that no
one is using stabs any more, it is unlikely that it ever will.
A more comprehensive cleanup would remove the stabs register
numbers altogether - it's unnecessary cruft / complication to
all of our register structures.
In ProcessGDBRemote, when we get register definitions from
the gdb-remote stub, we expect to see "gcc:" (qRegisterInfo)
or "gcc_regnum" (qXfer:features:read: packet to get xml payload).
This patch changes ProcessGDBRemote to also accept "ehframe:"
and "ehframe_regnum" from these remotes.
I did not change GDBRemoteCommunicationServerLLGS or debugserver
to send these new packets. I don't know what kind of interoperability
constraints we might be working under. At some point in the future
we should transition to using the more descriptive names.
Throughout lldb we're still using enum names like "gcc_r0" and "gdb_r0",
for eh_frame and stabs register numberings. These should be cleaned
up eventually too.
The sources link cleanly on macosx native with xcode build. I
don't think we'll see problems on other platforms but please let
me know if I broke anyone.
llvm-svn: 245141
SUMMARY:
The patch detects MIPS application specific extensions (ASE) like micromips by reading
ELF header.e_flags and SHT_MIPS_ABIFLAGS section. MIPS triple does not contain ASE
information like micromips, mips16, DSP, MSA etc. These can be read from header.e_flags
or SHT_MIPS_ABIFLAGS section.
Reviewers: clayborg
Subscribers: mohit.bhakkad, sagar, lldb-commits
Differential Revision: http://reviews.llvm.org/D11133
llvm-svn: 242381
On Android the oatdata and the oatexec symbols in
system@framework@boot.oat covers the full .text section what causes
issues with displaying unusable symbol name to the user and very slow
unwinding speed because the instruction emulation based unwind plans
try to emulate all instructions in these symbols. Don't add these
symbols to the symbol list as they have no use for the debugger and
they are causing a lot of trouble.
Differential revision: http://reviews.llvm.org/D11065
llvm-svn: 242017
Summary: Use string::find(char) for single character strings.
Reviewers: abidh, ki.stfu, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D10943
llvm-svn: 241390
* Add in-memory object file handling to the core dynamic loader
* Fix in memory object file handling in ObjectFileELF (previously
only part of the file was loaded before parsing)
* Fix load address setting in ObjectFileELF for 32-bit targets
when the load bias is negative
* Change hack in DYLDRendezvous.cpp to be more specific and not to
interfere with object files with fixed load address
Differential revision: http://reviews.llvm.org/D10800
llvm-svn: 241057
Whatever problem I saw that caused me to disable this
initially is not a problem today.
<rdar://problem/21173317>
<rdar://problem/20266253>
llvm-svn: 240737
A few extras were fixed
- Symbol::GetAddress() now returns an Address object, not a reference. There were places where people were accessing the address of a symbol when the symbol's value wasn't an address symbol. On MacOSX, undefined symbols have a value zero and some places where using the symbol's address and getting an absolute address of zero (since an Address object with no section and an m_offset whose value isn't LLDB_INVALID_ADDRESS is considered an absolute address). So fixing this required some changes to make sure people were getting what they expected.
- Since some places want to access the address as a reference, I added a few new functions to symbol:
Address &Symbol::GetAddressRef();
const Address &Symbol::GetAddressRef() const;
Linux test suite passes just fine now.
<rdar://problem/21494354>
llvm-svn: 240702
* Add and fix the emulation of several instruction.
* Disable frame pointer usage on Android.
* Specify return address register for the unwind plan instead of explict
tracking the value of RA.
* Replace prologue detection heuristics (unreliable in several cases)
with a logic to follow the branch instructions and restore the CFI
value based on them. The target address for a branch should have the
same CFI as the source address (if they are in the same function).
* Handle symbols in ELF files where the symbol size is not specified
with calcualting their size based on the next symbol (already done
in MachO files).
* Fix architecture in FuncUnwinders with filling up the inforamtion
missing from the object file with the architecture of the target.
* Add code to read register wehn the value is set to "IsSame" as it
meanse the value of a register in the parent frame is the same as the
value in the current frame.
Differential revision: http://reviews.llvm.org/D10447
llvm-svn: 240533
Setting the OSType in the ArchSpec triple is needed to correctly setup
up the register context plugin. ArchSpec::SetArchitecture, for Mach-O
only, sets the OSType. For ELF it was left to the ObjectFileELF to fill
in the missing OSType.
This change moves the ObjectFileELF logic into ArchSpec.
A new optional 'os' parameter has been added to SetArchitecture.
For ELF, this value is the from the ELF header.e_ident[EI_OSABI].
The default value is 0 or ELFOSABI_NONE.
The real work of determining the OSType was done by the ObjectFileELF
helper function GetOsFromOSABI. This logic has been moved
SetArchitecture.
GetOsFromOSABI has been commented as being deprectated. It is left in
to support asserts.
For ELF the vendor value returned from SetArchitecture should be
UnknownVendor. An unneeded resetting in ObjectFileELF has been removed
and replaced with an assert.
This fixes a problem reading a core file on FreeBSD/ARM because the spec
triple was arm-unknown-unknown.
Patch by Tom Rix.
Differential Revision: http://reviews.llvm.org/D9292
llvm-svn: 239148
The ELF data contains two different errors in some ELF files on android.
* The link field of the symbol table don't point to the plt section or
to the dynsym section even when it is present in the ELF files.
* The size of the plt entries aren't specified in the section header of
the plt section.
This CL adds some workarounds for these two issue with finding the
sections by name if the link field is empty and by using a heuristic to
calculate the size and offset of the plt entries.
Differential revision: http://reviews.llvm.org/D9560
llvm-svn: 236818
Patch by Jaydeep Patil
Added MIPS32 and MIPS64 core revisions. This would be followed by register context and emulate-instruction for MIPS32.
DYLDRendezvous.cpp:
On Linux link map struct does not contain extra load offset field.
Reviewers: clayborg
Subscribers: bhushan, mohit.bhakkad, sagar, lldb-commits.
Differential Revision: http://reviews.llvm.org/D9190
llvm-svn: 235574
The debug info section contains some $d mapping symbol what is
overlapping with code sections in other sections of the object file
causing problem in the address class detection. This CL ignores these
symboles from the address class map as the debug info sections don't use
this map.
Differential revision: http://reviews.llvm.org/D9050
llvm-svn: 235171
ELF symbol tables on aarch64 may contains some mapping symbols. They
provide information about the underlying data but interfere with symbol
look-up of lldb. They are already ignored on arm32. With this CL they
will be ignored on aarch64 also.
Differential revision: http://reviews.llvm.org/D8776
llvm-svn: 234307
So that we don't have to update every single #include in the entire
codebase to #include this new header (which used to get included by
lldb-private-log.h, we automatically #include "Logging.h" from
within "Log.h".
llvm-svn: 232653
In android a .note.android.ident section header is added to the elf
files to provide information for the debuggers that it is an android
specific module. This CL add logic to parse it out from the elf files
and set the module specification based on it.
Differential revision: http://reviews.llvm.org/D8377
llvm-svn: 232625
Summary:
Symbol table generation code was failing to take into account the debug symbols because
the object file was looking only into its own section list when doing the generation, even though
the debug symbols from another object file were correctly detected and loaded by the
SymbolVendor. This changes the code to use the unified section list, which fixes this problem.
Test Plan:
I do not intend do submit this yet since it causes (or more like, exposes) the issue
in D7884, but I wanted to put this out here, so that anyone who wants to take a look at it can do
so. (And I also wanted to know if this is the right approach to the problem :).
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7913
llvm-svn: 231229
Summary:
Symbols in ELF files can be versioned, but LLDB currently does not understand these. This problem
becomes apparent once one loads glibc with debug info. Here (in the .symtab section) the versions
are embedded in the name (name@VERSION), which causes issues when evaluating expressions
referencing memcpy for example (current glibc contains memcpy@@GLIBC_2.14 and
memcpy@GLIBC_2.2.5).
This problem was not evident without debug symbols as the .dynsym section
stores the bare names and the actual versions are present in a separate section (.gnu.version_d),
which LLDB ignores. This resulted in two definitions of memcpy in the symbol table.
This patch adds support for storing annotated names to the Symbol class. If
Symbol.m_contains_linker_annotations is true then this symbol is annotated. Unannotated name can
be obtained by calling StripLinkerAnnotations on the corresponding ObjectFile. ObjectFileELF
implements this to strip @VERSION suffixes when requested. Symtab uses this function to add the
bare name as well as the annotated name to the name lookup table.
To preserve the size of the Symbol class, I had to steal one bit from the m_type field.
Test Plan:
This fixes TestExprHelpExamples.py when run with a glibc with debug symbols. Writing
an environment agnostic test case would require building a custom shared library with symbol
versions and testing symbol resolution against that, which is somewhat challenging.
Reviewers: clayborg, jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8036
llvm-svn: 231228
This is implemented by making a new FileSystem function:
bool
FileSystem::IsLocal(const FileSpec &spec)
Then using this in a new function:
DataBufferSP
FileSpec::MemoryMapFileContentsIfLocal(off_t file_offset, size_t file_size) const;
This function only mmaps data if the file is a local file since that means we can reliably page in data. We were experiencing crashes where people would use debug info files on network mounted file systems and that mount would go away and cause the next access to a page that wasn't paged in to crash LLDB.
We now avoid this by just copying the data into a heap buffer and keeping a permanent copy to avoid the crash. Updated all previous users of FileSpec::MemoryMapFileContentsIfLocal() in ObjectFile subclasses over to use the new FileSpec::MemoryMapFileContentsIfLocal() function.
<rdar://problem/19470249>
llvm-svn: 230283
Background: dyld binaries often have extra symbols in their symbol table like "malloc" and "free" for the early bringup of dyld and we often don't want to set breakpoints in dynamic linker binaries. We also don't want to call the "malloc" or "free" function in dyld when a user writes an expression like "(void *)malloc(123)" so we need to avoid doing name lookups in dyld. We mark Modules as being dynamic link editors and this helps do correct lookups for breakpoints by name and function lookups.
<rdar://problem/19716267>
llvm-svn: 228261
When you create a target, it tries to look for the platform's list
of supported architectures for a match. The match it finds can
contain specific triples, like i386-pc-windows-msvc. Later, we
overwrite this value with the most generic triple that can apply
to any platform with COFF support, causing some of the fields of
the triple to get overwritten.
This patch changes the behavior to only merge in values from the COFF
triple if the fields of the matching triple were unknown/unspecified
to begin with.
This fixes load address resolution on Windows, since it enables the
DynamicLoaderWindows to be used instead of DynamicLoaderStatic.
Reviewed by: Greg Clayton
Differential Revision: http://reviews.llvm.org/D7120
llvm-svn: 226849
section for x86_64 and i386 targets on Darwin systems. Currently only the
compact unwind encoding for normal frame-using functions is supported but it
will be easy handle frameless functions when I have a bit more free time to
test it. The LSDA and personality routines for functions are also retrieved
correctly for functions from the compact unwind section.
This new code is very fresh -- it passes the lldb testsuite and I've done
by-hand inspection of many functions and am getting correct behavior for all
of them. There may need to be some bug fixing over the next couple weeks as
I exercise and test it further. But I think it's fine right now so I'm
committing it.
<rdar://problem/13220837>
llvm-svn: 223625
ObjectFileMachO. It's close but we seem to be missing some
of the memory region segments - not exactly sure how that's
happening. The register context writing into the LC_THREAD
load commands is working correctly though.
Slightly reordered the arm64 definitions in ArchSpec.cpp so
when we look for an arm64 core file definiton we're getting
a cpu subtype of CPU_ANY which we can't put in the mach
header of a core file. Make the first definition we find by
linear search have the currently correct '1' cpu subtype.
llvm-svn: 221743
Summary:
This adds preliminary support for PowerPC/PowerPC64, for FreeBSD. There are
some issues still:
* Breakpoints don't work well on powerpc64.
* Shared libraries don't yet get loaded for a 32-bit process on powerpc64 host.
* Backtraces don't work. This is due to PowerPC ABI using a backchain pointer
in memory, instead of a dedicated frame pointer register for the backchain.
* Breakpoints on functions without debug info may not work correctly for 32-bit
powerpc.
Reviewers: emaste, tfiala, jingham, clayborg
Reviewed By: clayborg
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D5988
llvm-svn: 220944
Recognise the SHT_NOBITS property in kalimba ELF, and determine this to be
of type zerofilled. Subsequently recognise this type to represent bytes
on the target's DATA address space, and therefore be sized accordingly.
llvm-svn: 219782
works, as do breakpoints, run and pause, display zeroth frame.
See
http://reviews.llvm.org/D5503
for a fuller description of the changes in this commit.
llvm-svn: 218596
This allows us to fixup the address of the symbol as soon as we parse it
so that lldb is not confused thinking there are two different symbols in
the binary (one with the thumb bit, one without). Also, differentiating
between THUMB and ARM symbols allows the debugger to place the right
type of breakpoint.
Change by Stephane Sezer.
llvm-svn: 217841
ELF objects contain marker symbols to differentiate between ARM and
THUMB functions. Instead of storing them internally and having garbage
show up when symbols are searched for by the user, we can just skip them
and not store them at all, as we never actually need them.
Change by Stephane Sezer.
Tested:
Ubuntu 14.04 x86_64
MacOSX 10.9.4 x86_64
llvm-svn: 217782
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
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
This patch creates a HostInfo class, a static class used to answer
basic queries about the host platform. As part of this change,
some functionality is moved from Host to HostInfo, and relevant
fixups are performed in the rest of the codebase.
This is part of a larger effort to isolate more code in the Host
layer into platform-specific groups, to make it easier to make
platform specific changes for a particular Host without breaking
other hosts.
Reviewed by: Greg Clayton
Differential Revision: http://reviews.llvm.org/D4963
llvm-svn: 215992
i386, i486, i486sx, and i686 are all indistinguishable as far as
PE/COFF files are concerned. This patch adds support for all of
these architectures to PlatformWindows.
Differential Revision: http://reviews.llvm.org/D4658
llvm-svn: 214092
File::SeekFromStart returns an off_t representing the position of the
file after seeking. This return value is always going to be one of two
values: the input or -1 in the case of failure.
ObjectFileMachO compares an expression of type off_t from the return of
File::SeekFromStart(segment.fileoff) and compares it for equality with
segment.fileoff.
The type of segment_command_64::fileoff is unsigned while off_t is
signed, comparing them emits a diagnostic under GCC.
Instead, we can just compare SeekFromSTart with -1 to see if we
successfully seeked.
Differential Revision: http://reviews.llvm.org/D4634
llvm-svn: 213822
GCC emits a warning:
warning: enumeral and non-enumeral type in conditional expression [enabled by default]
which does not seem to have a flag to control it. Simply add an explicit cast
for the boolean value.
llvm-svn: 213715
This fixes all of the hidden ivar test cases and any case where we try to find the full definition of an objective C class.
This also means hidden ivars show up again.
<rdar://problem/15458957>
llvm.org/pr20270
llvm.org/pr20269
llvm.org/pr20272
llvm-svn: 213328
This change comprises of additions and some minor changes in order that
"kalimba" is listed as a supported platform and that debugging any
kalimbas results in PlatformKalimba being associated with the target.
The changes are as follows:
* The PlatformKalimba implementation itself
* A tweak to ArchSpec
* .note parsing for Kalimba in ObjectFileELF.cpp
* Plugin registration
* Makefile additions
Change by Matthew Gardiner
Minor tweak for cmake and Xcode by Todd Fiala
Tested:
Ubuntu 14.04 x86_64, clang 3.5-built lldb, all tests pass.
MacOSX 10.9.4, Xcode 6.0 Beta 1-built lldb, all tests pass.
llvm-svn: 213158
If we have any section headers in the collection, we already parsed them.
Therefore, don't reparse the section headers when the section_headers collection
is not empty.
See this thread for more details:
http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140707/011721.html
Change by Matthew Gardiner
llvm-svn: 212822
off_t is a type which is used for file offsets. Even more
specifically, it is only used by a limited number of C APIs that
deal with files. Any usage of off_t where the variable is not
intended to be used with one of these APIs is a bug, by definition.
This patch corrects some easy mis-uses of off_t, generally by
converting them to lldb::offset_t, but sometimes by using other
types such as size_t, when appropriate.
The use of off_t to represent these offsets has worked fine in
practice on linux-y platforms, since we used _FILE_OFFSET_64 to
guarantee that off_t was a uint64. On Windows, however,
_FILE_OFFSET_64 is unrecognized, and off_t will always be 32-bit.
So the usage of off_t on Windows actually leads to legitimate bugs.
Reviewed by: Greg Clayton
Differential Revision: http://reviews.llvm.org/D4358
llvm-svn: 212192
Previously ObjectFileELF was simplifying and assuming the object file it was
looking at was the same as the host architecture/triple. This would break
attempts to run, say, lldb on MacOSX against lldb-gdbserver on Linux since
the MacOSX lldb would say that the linux elf file was really an Apple MacOSX
architecture. Chaos would ensue.
This change allows the elf file to parse ELF notes for Linux, FreeBSD and
NetBSD, and determine the OS appropriately from them. It also initializes
the OS type from the ELF header OSABI if it is set (which it is for FreeBSD
but not for Linux).
Added a test with freebsd and linux images that verify that
'(lldb) image list -t -A' prints out the expected architecture for each.
llvm-svn: 211907
Not all supported compilers have GCC intrinsics, so this patch
uses the correct portable alternative.
Additionally, this patch fixes an off-by-one error. __builtin_ffs
returns the 1-based index of the least-significant 1-bit, but the
function expects the base 2 logarithm of the number, which is
equivalent to the 0-based index of the least-significant 1-bit.
Reviewed by: Keno Fischer
Differential Revision: http://reviews.llvm.org/D4284
llvm-svn: 211669
The patch is as is with the functionality left disabled for apple vendors because of performance regressions. If this is enabled it ends up searching for symbols in all shared libraries that are loadeded.
llvm-svn: 211638
Address the 'variable set but not used' warning from GCC. In some cases a few
additional calls were removed where there should be no visible side effects of
the calls (i.e. should not effect any cached state).
llvm-svn: 210879
(lldb) file /bin/ls
(lldb) b malloc
(lldb) run
(lldb) process save-core /tmp/ls.core
Each ObjectFile plug-in now has the option to save core files by registering a new static callback.
llvm-svn: 210864
Changes include:
- ObjectFileMachO can now determine if a binary is "*-apple-ios" or "*-apple-macosx" by checking the min OS and SDK load commands
- ArchSpec now says "<arch>-apple-macosx" is equivalent to "<arch>-apple-ios" since the simulator mixes and matches binaries (some from the system and most from the iOS SDK).
- Getting process inforamtion on MacOSX now correctly classifies iOS simulator processes so they have "*-apple-ios" architectures in the ProcessInstanceInfo
- PlatformiOSSimulator can now list iOS simulator processes correctly instead of showing nothing by using:
(lldb) platform select ios-simulator
(lldb) platform process list
- debugserver can now properly return "*-apple-ios" for the triple in the process info packets for iOS simulator executables
- GDBRemoteCommunicationClient now correctly passes along the triples it gets for process info by setting the OS in the llvm::Triple correctly
<rdar://problem/17060217>
llvm-svn: 209852
This is a purely mechanical change explicitly casting any parameters for printf
style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux.
llvm-svn: 205607
This is a mechanical change addressing the various sign comparison warnings that
are identified by both clang and gcc. This helps cleanup some of the warning
spew that occurs during builds.
llvm-svn: 205390
These changes were written by Greg Clayton, Jim Ingham, Jason Molenda.
It builds cleanly against TOT llvm with xcodebuild. I updated the
cmake files by visual inspection but did not try a build. I haven't
built these sources on any non-Mac platforms - I don't think this
patch adds any code that requires darwin, but please let me know if
I missed something.
In debugserver, MachProcess.cpp and MachTask.cpp were renamed to
MachProcess.mm and MachTask.mm as they picked up some new Objective-C
code needed to launch processes when running on iOS.
llvm-svn: 205113
Add a GetFoundationVersion() to AppleObjCRuntime
This API is used to return and cache the major version of Foundation.framework, which is potentially a useful piece of data to key off of to enable or disable certain ObjC related behaviors (especially in data formatters)
llvm-svn: 204756
This change makes significant improvements in the performance of
calculating a UUID within ObjectFileELF, and handles both running
processes and core files correctly. This does lazy evaluation of
UUID generation and caches the result when calculated.
Change by Piotr Rak.
llvm-svn: 204749
(lldb) b puts
(lldb) expr -g -i0 -- (int)puts("hello")
First we will stop at the entry point of the expression before it runs, then we can step over a few times and hit the breakpoint in "puts", then we can continue and finishing stepping and fininsh the expression.
Main features:
- New ObjectFileJIT class that can be easily created for JIT functions
- debug info can now be enabled when parsing expressions
- source for any function that is run throught the JIT is now saved in LLDB process specific temp directory and cleaned up on exit
- "expr -g --" allows you to single step through your expression function with source code
<rdar://problem/16382881>
llvm-svn: 204682
ObjectFile::SetLoadAddress (Target &target,
lldb::addr_t value,
bool value_is_offset);
Now "value" is a slide if "value_is_offset" is true, and "value" is an image base address otherwise. All previous usage of this API was using slides.
Updated the ObjectFileELF and ObjectFileMachO SetLoadAddress methods to do the right thing.
Also updated the ObjectFileMachO::SetLoadAddress() function to not load __LINKEDIT when it isn't needed and to only load sections that belong to the executable object file.
llvm-svn: 201003
Move some code that was in DynamicLoaderPOSIXDLYD into the
base class DynamicLoader. In the case of UpdateLoadedSections(),
the test to see whether a file is loadable (its address is zero)
is not generally applicable so that test is changed to a more
universally applicable check for the SHF_ALLOC flag on the section.
Also make it explicit that the reading of the module_id in
DynamicLoaderPOSIXDYLD::GetThreadLocalData() is using a hardcoded
size (of module_id) of 4, which might not be appropriate on
big-endian 64-bit systems, leaving a FIXME comment in place.
llvm-svn: 200939
Separate ELF note implementations were introduced for core files and
GNU build-id. Move the more general one from elf-core to ObjectFileELF
and use it for build-id as well.
Review: http://llvm-reviews.chandlerc.com/D1902
llvm-svn: 196125
0 as CPU subtype never matches anything (at least, it doesn't match x86_64 windows binaries, of which there are correct arch definitions for). It should be created with LLDB_INVALID_CPUTYPE.
llvm-svn: 195435
Fixed an issue with reexported symbols on MacOSX by adding support for symbols re-exporting symbols. There is now a new symbol type eSymbolTypeReExported which contains a new name for the re-exported symbol and the new shared library. These symbols are only used when a symbol is re-exported as a symbol under a different name.
Modified the expression parser to be able to deal with finding the re-exported symbols and track down the actual symbol it refers to.
llvm-svn: 193101
Fixed Module::ResolveSymbolContextForAddress() to be able to also look in the SymbolVendor's SymbolFile's ObjectFile for a more meaningful symbol when a symbol lookup finds a synthetic symbol from the main object file. This will help lookups on MacOSX as the main executable might be stripped, but the dSYM file always has a full symbol table.
llvm-svn: 192510
Just pass a Target* into ObjectFileELF::GetImageInfoAddress so that
it can do the extra dereference necessary on MIPS, instead of passing
a flag back to the caller.
Review: http://llvm-reviews.chandlerc.com/D1899
llvm-svn: 192469
MIPS's .dyanamic section is read-only. Instead of using DT_DEBUG for
the pointer to dyld information it uses a separate tag DT_MIPS_RLD_MAP
which points to storage in the read-write .rld_map section, which in
turn points to the dyld information.
Review: http://llvm-reviews.chandlerc.com/D1890
llvm-svn: 192408
to build out the symbol table as addresses are used, and implements
the mechanism for ELF to add stripped symbols from eh_frame.
Uses this mechanism to allow disassembly for addresses corresponding
to stripped symbols for ELF, and provide hooks to implement this for
PE COFF.
Also removes eSymbolContextTailCall in favor of an option for
ResolveSymbolContextForAddress for consistency with the documentation
for eSymbolContextEverything. Essentially, this is just an option for
interpreting the so_addr.
llvm-svn: 191307
and a mach kernel in all the pages of the core file. If it finds
a user-process dyld binary, assume this is a user process that had
a copy of the mach kernel in memory when it crashed (e.g. lldb doing
kernel debugging) even though we found the kernel binary first.
Also, change the error messages about sections extending past the end
of the file to be warnings and make the messages sound less severe.
Most user process core files have one section that isn't included in
the file and there's no reason to worry people about that.
<rdar://problem/14473235>
llvm-svn: 190741
Since I renamed most of the LLVM Mach-O enums in r189314, I had to go fix
LLDB to use the new names. While I was here, I decided that a COFF
plugin really shouldn't be using Mach-O enums.
llvm-svn: 189316
out of a binary, if the Mach-O binary is MH_PRELOAD ("standalone"), don't
let the OS be set to "ios" or "macosx" - there will be no dynamic loader
used when debugging this process.
<rdar://problem/9956443>
llvm-svn: 189305
Bruce Mitchener