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
Greg Clayton