Fix unwind failures when PC points beyond the end of a function

RegisterContextLLDB::InitializeNonZerothFrame already has code to attempt
to detect and handle the case where the PC points beyond the

Fix unwind failures when PC points beyond the end of a function

RegisterContextLLDB::InitializeNonZerothFrame already has code to attempt
to detect and handle the case where the PC points beyond the end of a
function, but there are certain cases where this doesn't work correctly.

In fact, there are *two* different places where this detection is attempted,
and the failure is in fact a result of an unfortunate interaction between
those two separate attempts.

First, the ResolveSymbolContextForAddress routine is called with the
resolve_tail_call_address flag set to true. This causes the routine
to internally accept a PC pointing beyond the end of a function, and
still resolving the PC to that function symbol.

Second, the InitializeNonZerothFrame routine itself maintains a
"decr_pc_and_recompute_addr_range" flag and, if that turns out to
be true, itself decrements the PC by one and searches again for
a symbol at that new PC value.

Both approaches correctly identify the symbol associated with the PC.
However, the problem is now that later on, we also need to find the
DWARF CFI record associated with the PC. This is done in the
RegisterContextLLDB::GetFullUnwindPlanForFrame routine, and uses
the "m_current_offset_backed_up_one" member variable.

However, that variable only actually contains the PC "backed up by
one" if the *second* approach above was taken. If the function was
already identified via the first approach above, that member variable
is *not* backed up by one but simply points to the original PC.
This in turn causes GetEHFrameUnwindPlan to not correctly identify
the DWARF CFI record associated with the PC.

Now, in many cases, if the first method had to back up the PC by one,
we *still* use the second method too, because of this piece of code:

// Or if we're in the middle of the stack (and not "above" an asynchronous event like sigtramp),
// and our "current" pc is the start of a function...
if (m_sym_ctx_valid
&& GetNextFrame()->m_frame_type != eTrapHandlerFrame
&& GetNextFrame()->m_frame_type != eDebuggerFrame
&& addr_range.GetBaseAddress().IsValid()
&& addr_range.GetBaseAddress().GetSection() == m_current_pc.GetSection()
&& addr_range.GetBaseAddress().GetOffset() == m_current_pc.GetOffset())
{
decr_pc_and_recompute_addr_range = true;
}

In many cases, when the PC is one beyond the end of the current function,
it will indeed then be exactly at the start of the next function. But this
is not always the case, e.g. if there happens to be alignment padding
between the end of one function and the start of the next.

In those cases, we may sucessfully look up the function symbol via
ResolveSymbolContextForAddress, but *not* set decr_pc_and_recompute_addr_range,
and therefore fail to find the correct DWARF CFI record.

A very simple fix for this problem is to just never use the first method.
Call ResolveSymbolContextForAddress with resolve_tail_call_address set
to false, which will cause it to fail if the PC is beyond the end of
the current function; or else, identify the next function if the PC
is also at the start of the next function. In either case, we will
then set the decr_pc_and_recompute_addr_range variable and back up the
PC anyway, but this time also find the correct DWARF CFI.

A related problem is that the ResolveSymbolContextForAddress sometimes
returns a "symbol" with empty name. This turns out to be an ELF section
symbol. Now, usually those get type eSymbolTypeInvalid. However, there
is code in ObjectFileELF::ParseSymbols that tries to change the type of
invalid symbols to eSymbolTypeCode or eSymbolTypeData if the symbol
lies within the code or data section.

Unfortunately, this check also hits the symbol for the code section
itself, which is then marked as eSymbolTypeCode. While the size of
the section symbol is 0 according to the ELF file, LLDB considers
this size invalid and attempts to figure out the "correct" size.
Depending on how this goes, we may end up with a symbol that overlays
part of the code section, even outside areas covered by real function
symbols.

Therefore, if we call ResolveSymbolContextForAddress with PC pointing
beyond the end of a function, we may get this bogus section symbol.
This again means InitializeNonZerothFrame thinks we have a valid PC,
but then we don't find any unwind info for it.

The fix for this problem is me to simply always leave ELF section
symbols as type eSymbolTypeInvalid.

Differential Revision: http://reviews.llvm.org/D18975

llvm-svn: 267363

show more ...

ObjectFile: parse EABI Attributes

This adds basic parsing of the EABI attributes section. This section contains
additional information about the target for which the file was built. Attempt
to inf

ObjectFile: parse EABI Attributes

This adds basic parsing of the EABI attributes section. This section contains
additional information about the target for which the file was built. Attempt
to infer additional architecture information from that section.

llvm-svn: 267291

show more ...

Find .plt section in object files generated by recent ld

Code in ObjectFileELF::ParseTrampolineSymbols assumes that the sh_info
field of the .rel(a).plt section identifies the .plt section.

However

Find .plt section in object files generated by recent ld

Code in ObjectFileELF::ParseTrampolineSymbols assumes that the sh_info
field of the .rel(a).plt section identifies the .plt section.

However, with recent GNU ld this is no longer true. As a result of this:
https://sourceware.org/bugzilla/show_bug.cgi?id=18169
in object files generated with current linkers the sh_info field of
.rel(a).plt now points to the .got.plt section (or .got on some targets).

This causes LLDB to fail to identify any PLT stubs, causing a number of
test case failures.

This patch changes LLDB to simply always look for the .plt section by
name. This should be safe across all linkers and targets.

Differential Revision: http://reviews.llvm.org/D18973

llvm-svn: 266316

show more ...

Implement `target modules dump objfile`

Differential Revision: http://reviews.llvm.org/D18464

llvm-svn: 265349

Allow any build-id length between 4 and 20 bytes inclusive

Build-id support is being added to lld and by default it may produce a
64-bit build-id.

Prior to this change lldb would reject such a buil

Allow any build-id length between 4 and 20 bytes inclusive

Build-id support is being added to lld and by default it may produce a
64-bit build-id.

Prior to this change lldb would reject such a build-id. However, it then
falls back to a 4-byte crc32, which is a poorer quality identifier.

Differential Revision: http://reviews.llvm.org/D18096

llvm-svn: 263432

show more ...

Add support for handling absolute symbols in ELF

Most address represented in lldb as section plus offset and handling of
absolute addresses is problematic in several location because of lack
of nece

Add support for handling absolute symbols in ELF

Most address represented in lldb as section plus offset and handling of
absolute addresses is problematic in several location because of lack
of necessary information (e.g. Target) or because of performance issues.

This CL change the way ObjectFileELF handle the absolute symbols with
creating a pseudo section for each symbol. With this change all existing
code designed to work with addresses in the form of section plus offset
will work with absolute symbols as well.

Differential revision: http://reviews.llvm.org/D17450

llvm-svn: 261859

show more ...

Improve the handling of missing elf symtab and missing symbol sizes

* Generate artificial symbol names from eh_fame during symbol parsing
so these symbols are already present when we calcualte the

Improve the handling of missing elf symtab and missing symbol sizes

* Generate artificial symbol names from eh_fame during symbol parsing
so these symbols are already present when we calcualte the size of
the symbols where 0 is specified.
* Fix symbol size calculation for the last symbol in the file where
it have to last until the end of the parent section.

This is the re-commit of the original change after fixing some test
failures on OSX.

Differential revision: http://reviews.llvm.org/D16996

llvm-svn: 261205

show more ...

Revert "Improve the handling of missing elf symtab and missing symbol sizes"

This reverts commit 252dda67782f2cbf838e375bce21ed4191f6d9ce.

The commit caused several test failure on the OSX build bo

Revert "Improve the handling of missing elf symtab and missing symbol sizes"

This reverts commit 252dda67782f2cbf838e375bce21ed4191f6d9ce.

The commit caused several test failure on the OSX build bot.

llvm-svn: 260377

show more ...

Improve the handling of missing elf symtab and missing symbol sizes

* Generate artificial symbol names from eh_fame during symbol parsing
so these symbols are already present when we calcualte the

Improve the handling of missing elf symtab and missing symbol sizes

* Generate artificial symbol names from eh_fame during symbol parsing
so these symbols are already present when we calcualte the size of
the symbols where 0 is specified.
* Fix symbol size calculation for the last symbol in the file where
it have to last until the end of the parent section.

Differential revision: http://reviews.llvm.org/D16996

llvm-svn: 260369

show more ...

Add support to detect arm hard float ABI based binaries for ABISysV_arm

This patch adds logic to detect if underlying binary is using arm hard float abi and use that information while handling retur

Add support to detect arm hard float ABI based binaries for ABISysV_arm

This patch adds logic to detect if underlying binary is using arm hard float abi and use that information while handling return values in ABISysV_arm.

Differential revision: http://reviews.llvm.org/D16627

llvm-svn: 259885

show more ...

Fix for Bug 25338

Summary:
The issue arises because LLDB is not
able to read the vdso library correctly.
The fix adds memory allocation callbacks
to allocate sufficient memory in case the
requested

Fix for Bug 25338

Summary:
The issue arises because LLDB is not
able to read the vdso library correctly.
The fix adds memory allocation callbacks
to allocate sufficient memory in case the
requested offsets don't fit in the memory
buffer allocated for the ELF.

Reviewers: lldb-commits, clayborg, deepak2427, ovyalov, labath, tberghammer

Differential Revision: http://reviews.llvm.org/D16107

llvm-svn: 258122

show more ...

Unconditionally accept symbol sizes from elf

The ELF symbol table always contain the size of the symbols so we
don't have to try to guess them based on the address of the next
symbol (it is needed f

Unconditionally accept symbol sizes from elf

The ELF symbol table always contain the size of the symbols so we
don't have to try to guess them based on the address of the next
symbol (it is needed for mach-o).

The change fixes an issue when a symbol is removed after a 0 size
symbol (e.g. because the second one is not public) what previously
caused the symbol lookup algorithm to end up with showing the 0 size
symbol even for the later addresses (what are not part of any symbol).
That symbol lookup error can confuse the user and also confuses the
current stack unwinder.

Re-commit this CL after fixing the issue with gcc-4.9.2 on i386 Linux.

Differential revision: http://reviews.llvm.org/D16186

llvm-svn: 258113

show more ...

Update for llvm change. NFC.

llvm-svn: 258080

Revert "Unconditionally accept symbol sizes from elf"

It causes issues for i386 when compiling with gcc-4.9.2

This reverts commit e248214a3eab8e244095f97d1996c991cb988cc4.

llvm-svn: 258043

Unconditionally accept symbol sizes from elf

The ELF symbol table always contain the size of the symbols so we
don't have to try to guess them based on the address of the next
symbol (it is needed f

Unconditionally accept symbol sizes from elf

The ELF symbol table always contain the size of the symbols so we
don't have to try to guess them based on the address of the next
symbol (it is needed for mach-o).

The change fixes an issue when a symbol is removed after a 0 size
symbol (e.g. because the second one is not public) what previously
caused the symbol lookup algorithm to end up with showing the 0 size
symbol even for the later addresses (what are not part of any symbol).
That symbol lookup error can confuse the user and also confuses the
current stack unwinder.

Differential revision: http://reviews.llvm.org/D16186

llvm-svn: 258040

show more ...

[LLDB][MIPS] Fix rL255619: mips 3, 4 and 5 are 64 bit archs

llvm-svn: 257448

Get rid of ARM_ELF_SYM_IS_THUMB flag.

Summary:
This was used with the old ARM vs. Thumb detection code but is not
required anymore.

Reviewers: tberghammer, clayborg

Subscribers: fjricci, aemerson,

Get rid of ARM_ELF_SYM_IS_THUMB flag.

Summary:
This was used with the old ARM vs. Thumb detection code but is not
required anymore.

Reviewers: tberghammer, clayborg

Subscribers: fjricci, aemerson, lldb-commits, rengolin

Differential Revision: http://reviews.llvm.org/D16099

llvm-svn: 257429

show more ...

Strip trailing whitespace

(There are changes in the copies of these four files in the FreeBSD base
system, and I've changed these ones to reduce gratuitous diffs in future
imports.)

llvm-svn: 256723

Read macro info from .debug_macro section and use it for expression evaluation.

Summary:
DWARF 5 proposes a reinvented .debug_macro section. This change follows
that spec.

Currently, only GCC produ

Read macro info from .debug_macro section and use it for expression evaluation.

Summary:
DWARF 5 proposes a reinvented .debug_macro section. This change follows
that spec.

Currently, only GCC produces the .debug_macro section and hence
the added test is annottated with expectedFailureClang.

Reviewers: spyffe, clayborg, tberghammer

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D15437

llvm-svn: 255729

show more ...

[LLDB][MIPS] Added support for MIPS1, MIPS2, MIPS3, MIPS4 and MIPS5 instruction sets

Patch by Nitesh Jain.

Summary: This Patch will allowed LLDB to debug respective instruction sets binaries.

Revi

[LLDB][MIPS] Added support for MIPS1, MIPS2, MIPS3, MIPS4 and MIPS5 instruction sets

Patch by Nitesh Jain.

Summary: This Patch will allowed LLDB to debug respective instruction sets binaries.

Reviewers: jaydeep, clayborg
Subscribers: lldb-commits, mohit.bhakkad, sagar, bhushan
Differential: http://reviews.llvm.org/D15487
llvm-svn: 255619

show more ...

Make core files not crash when you load a core file into LLDB with just "lldb -c core".

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

Make core files not crash when you load a core file into LLDB with just "lldb -c core".

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

show more ...

Some minor improvements on the symtab parsing code

* Remove an unneccessary re-computaion on arch spec from the ELF file
* Use a local cache to optimize name based section lookups in symtab
parsin

Some minor improvements on the symtab parsing code

* 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

show more ...

ArchSpec: fix unintentional promotion of unspecified unknowns to specified unknowns

* ArchSpec::MergeFrom() would erroneously promote an unspecified
unknown to a specified unknown when both the Ar

ArchSpec: fix unintentional promotion of unspecified unknowns to specified unknowns

* 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

show more ...

Romove accidentially added statement in r249020

llvm-svn: 249021

[LLDB][MIPS] Fix gp register value for o32 applications on 64-bit target

GP registers for o32 applications were always giving zero value because SetType() on the RegisterValue was causing the access

[LLDB][MIPS] Fix gp register value for o32 applications on 64-bit target

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

show more ...