[DebugInfo] Remove unused includes (NFC) (#116551)

Identified with misc-include-cleaner.

[Analysis, CodeGen, DebugInfo] Use StringRef::operator== instead of StringRef::equals (NFC) (#91304)

I'm planning to remove StringRef::equals in favor of
StringRef::operator==.

- StringRef::oper

[Analysis, CodeGen, DebugInfo] Use StringRef::operator== instead of StringRef::equals (NFC) (#91304)

I'm planning to remove StringRef::equals in favor of
StringRef::operator==.

- StringRef::operator==/!= outnumber StringRef::equals by a factor of
53 under llvm/ in terms of their usage.

- The elimination of StringRef::equals brings StringRef closer to
std::string_view, which has operator== but not equals.

- S == "foo" is more readable than S.equals("foo"), especially for
!Long.Expression.equals("str") vs Long.Expression != "str".

show more ...

[DebugInfo] Use StringRef::consume_front (NFC)

[symbolizer] Support symbol+offset lookup (#75067)

GNU addr2line supports lookup by symbol name in addition to the existing
address lookup. llvm-symbolizer starting from
e144ae54dcb96838a6176fd9ee

[symbolizer] Support symbol+offset lookup (#75067)

GNU addr2line supports lookup by symbol name in addition to the existing
address lookup. llvm-symbolizer starting from
e144ae54dcb96838a6176fd9eef21028935ccd4f supports lookup by symbol name.
This change extends this lookup with possibility to specify optional
offset.

Now the address for which source information is searched for can be
specified with offset:

llvm-symbolize --obj=abc.so "SYMBOL func_22+0x12"

It decreases the gap in features of llvm-symbolizer and GNU addr2line.
This lookup now is supported for code only.

Migrated from: https://reviews.llvm.org/D139859
Pull request: https://github.com/llvm/llvm-project/pull/75067

show more ...

[symbolizer] Support symbol lookup

Recent versions of GNU binutils starting from 2.39 support symbol+offset
lookup in addition to the usual numeric address lookup. This change adds
symbol lookup to

[symbolizer] Support symbol lookup

Recent versions of GNU binutils starting from 2.39 support symbol+offset
lookup in addition to the usual numeric address lookup. This change adds
symbol lookup to llvm-symbolize and llvm-addr2line.

Now llvm-symbolize behaves closer to GNU addr2line, - if the value specified
as address in command line or input stream is not a number, it is treated as
a symbol name. For example:

llvm-symbolize --obj=abc.so func_22
llvm-symbolize --obj=abc.so "CODE func_22"

This lookup is now supported only for functions. Specification with
offset is not supported yet.

This is a recommit of 2b27948783e4bbc1132d3220d8517ef62607b558, reverted
in 39fec5457c0925bd39f67f63fe17391584e08258 because the test
llvm/test/Support/interrupts.test started failing on Windows. The test was
changed in 18f036d0105589c3175bb51a518c5d272dae61e2 and is also updated in
this commit.

Differential Revision: https://reviews.llvm.org/D149759

show more ...

Revert "[symbolizer] Support symbol lookup"

This reverts commit 2b27948783e4bbc1132d3220d8517ef62607b558.
On some buildbots the test LLVM::interrupts.test start failing.

[symbolizer] Support symbol lookup

Recent versions of GNU binutils starting from 2.39 support symbol+offset
lookup in addition to the usual numeric address lookup. This change adds
symbol lookup to

[symbolizer] Support symbol lookup

Recent versions of GNU binutils starting from 2.39 support symbol+offset
lookup in addition to the usual numeric address lookup. This change adds
symbol lookup to llvm-symbolize and llvm-addr2line.

Now llvm-symbolize behaves closer to GNU addr2line, - if the value specified
as address in command line or input stream is not a number, it is treated as
a symbol name. For example:

llvm-symbolize --obj=abc.so func_22
llvm-symbolize --obj=abc.so "CODE func_22"

This lookup is now supported only for functions. Specification with
offset is not supported yet.

Differential Revision: https://reviews.llvm.org/D149759

show more ...

[NFC][TargetParser] Remove llvm/ADT/Triple.h

I also ran `git clang-format` to get the headers in the right order for
the new location, which has changed the order of other headers in two
files.

Don't populate the symbol table with symbols that don't belong to a section with the flag SHF_ALLOC

When populating the symbol table for an ELF object file, don't insert any symbols that come from E

Don't populate the symbol table with symbols that don't belong to a section with the flag SHF_ALLOC

When populating the symbol table for an ELF object file, don't insert any symbols that come from ELF sections which don't have runtime allocated memory (typically debugging symbols).

Reviewed By: dblaikie

Differential Revision: https://reviews.llvm.org/D133795

show more ...

[symbolizer] Parse DW_TAG_variable DIs to show line info for globals

Currently, llvm-symbolizer doesn't like to parse .debug_info in order to
show the line info for global variables. addr2line does

[symbolizer] Parse DW_TAG_variable DIs to show line info for globals

Currently, llvm-symbolizer doesn't like to parse .debug_info in order to
show the line info for global variables. addr2line does this. In the
future, I'm looking to migrate AddressSanitizer off of internal metadata
over to using debuginfo, and this is predicated on being able to get the
line info for global variables.

This patch adds the requisite support for getting the line info from the
.debug_info section for symbolizing global variables. This only happens
when you ask for a global variable to be symbolized as data.

Reviewed By: dblaikie

Differential Revision: https://reviews.llvm.org/D123538

show more ...

[DebugInfo] Move the SymbolizableObjectFile header to include/llvm.

This change moves the SymbolizableObjectFile header to
include/llvm/DebugInfo/Symbolize. Making this header available to other
llv

[DebugInfo] Move the SymbolizableObjectFile header to include/llvm.

This change moves the SymbolizableObjectFile header to
include/llvm/DebugInfo/Symbolize. Making this header available to other
llvm libraries simplifies use cases where implicit caching, multiple
platform support and other features of the Symbolizer class are not
required. This also makes the dependent libraries easier to unit test
by having mocks which derive from SymbolizableModule.

Differential Revision: https://reviews.llvm.org/D116781

show more ...

[symbolizer] Added StartAddress for the resolved function.

In many cases it is helpful to know at what address the resolved function starts.
This patch adds a new StartAddress member to the DILineIn

[symbolizer] Added StartAddress for the resolved function.

In many cases it is helpful to know at what address the resolved function starts.
This patch adds a new StartAddress member to the DILineInfo structure.

Reviewed By: jhenderson, dblaikie

Differential Revision: https://reviews.llvm.org/D102316

show more ...

DebugInfo/Symbolize: Exclude ARM mapping symbols for .symtab symbolization after D95916

Their names don't convey much information, so they should be excluded.
The behavior matches addr2line.

Differ

DebugInfo/Symbolize: Exclude ARM mapping symbols for .symtab symbolization after D95916

Their names don't convey much information, so they should be excluded.
The behavior matches addr2line.

Differential Revision: https://reviews.llvm.org/D96617

show more ...

DebugInfo/Symbolize: Use stable_sort

This fixes coff-dwarf.test on some build bots.
The test relies on the sort order and prefers main (StorageClass: External) to .text (StorageClass: Static).

DebugInfo/Symbolize: Don't differentiate function/data symbolization

Before d08bd13ac8a560c4645e17e192ca07e1bdcd2895, only `SymbolRef::ST_Function`
symbols were used for .symtab symbolization. That

DebugInfo/Symbolize: Don't differentiate function/data symbolization

Before d08bd13ac8a560c4645e17e192ca07e1bdcd2895, only `SymbolRef::ST_Function`
symbols were used for .symtab symbolization. That commit added a `"DATA"` mode
to llvm-symbolizer which used `SymbolRef::ST_Data` symbols for symbolization.

Since function and data symbols have different addresses, we don't need to
differentiate the two modes. This patches unifies the two modes to simplify
code.

`"DATA"` is used by `compiler-rt/lib/sanitizer_common/sanitizer_symbolizer_libcdep.cpp`.
`check-hwasan` and `check-tsan` have runtime tests.

Differential Revision: https://reviews.llvm.org/D96322

show more ...

DebugInfo/Symbolize: Retrieve filename from the preceding STT_FILE for .symtab symbolization

The ELF spec says:

> STT_FILE: Conventionally, the symbol's name gives the name of the source file assoc

DebugInfo/Symbolize: Retrieve filename from the preceding STT_FILE for .symtab symbolization

The ELF spec says:

> STT_FILE: Conventionally, the symbol's name gives the name of the source file associated with the object file. A file symbol has STB_LOCAL binding, its section index is SHN_ABS, and it precedes the other STB_LOCAL symbols for the file, if it is present.

For a local symbol, the preceding STT_FILE symbol is almost always in the same
file[1]. GNU addr2line uses this heuristic to retrieve the filename associated
with a local symbol (e.g. internal linkage functions in C/C++).

GNU addr2line can assign STT_FILE filename to a non-local symbol, too, but the trick
only works if no regular symbol precede STT_FILE. This patch does not implement this corner case
(not useful for most executables which have more than one files).

In case of filename mismatch between .debug_line & .symtab, arbitrarily make .debug_line win.

[1]: LLD does not synthesize STT_FILE symbols
(https://bugs.llvm.org/show_bug.cgi?id=48023 see also
https://sourceware.org/bugzilla/show_bug.cgi?id=26822). An assembly file
without `.file` directives can cause mis-attribution. This is an edge case.

Differential Revision: https://reviews.llvm.org/D95927

show more ...

DebugInfo/Symbolize: Allow STT_NOTYPE/STT_GNU_IFUNC symbols for .symtab symbolization

In assembly files, omitting `.type foo,@function` is common. Such functions have
type `STT_NOTYPE` and llvm-symb

DebugInfo/Symbolize: Allow STT_NOTYPE/STT_GNU_IFUNC symbols for .symtab symbolization

In assembly files, omitting `.type foo,@function` is common. Such functions have
type `STT_NOTYPE` and llvm-symbolizer reports `??` for them.

An ifunc symbol usually has an associated resolver symbol which is defined at
the same address. Returning either one is fine for symbolization. The resolver
symbol may not end up in the symbol table if (object file) `.L` is used (linked
image) .symtab is stripped while .dynsym is retained.

This patch allows ELF STT_NOTYPE/STT_GNU_IFUNC symbols for .symtab symbolization.

I have left TODO in the test files for an unimplemented STT_FILE heuristic.

Differential Revision: https://reviews.llvm.org/D95916

show more ...

SymbolizableObjectFile.h - remove unnecessary includes. NFCI.

Use forward declarations where possible, move includes down to SymbolizableObjectFile.cpp and avoid duplicate includes.

Re-land "Migrate the rest of COFFObjectFile to Error"

This reverts commit 101fbc01382edd89ea7b671104c68b30b2446cc0.

Remove leftover debugging attribute.

Update LLDB as well, which was missed befor

Re-land "Migrate the rest of COFFObjectFile to Error"

This reverts commit 101fbc01382edd89ea7b671104c68b30b2446cc0.

Remove leftover debugging attribute.

Update LLDB as well, which was missed before.

show more ...

Revert "Migrate the rest of COFFObjectFile to Error"

This reverts commit b5289656b865d2a73cf90819e20a96fb8414ab0b.
__attribute__((optnone)) doesn't build with msvc, see
http://lab.llvm.org:8011/buil

Revert "Migrate the rest of COFFObjectFile to Error"

This reverts commit b5289656b865d2a73cf90819e20a96fb8414ab0b.
__attribute__((optnone)) doesn't build with msvc, see
http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/16326

show more ...

Migrate the rest of COFFObjectFile to Error

Cleanup the plumbing for DILineInfoSpecifier. [NFC - Try 2]

Revert "Cleanup the plumbing for DILineInfoSpecifier. [NFC]"

This broke lldb. Will fix and resubmit.

This reverts commit 98ff6eb679cd5a2556d990d3d629e6c03c1da6a0.

Cleanup the plumbing for DILineInfoSpecifier. [NFC]

Summary:
1. FileLineInfoSpecifier::Default isn't the default for anything.
Rename to RawValue, which accurately reflects its role.
2. Most functio

Cleanup the plumbing for DILineInfoSpecifier. [NFC]

Summary:
1. FileLineInfoSpecifier::Default isn't the default for anything.
Rename to RawValue, which accurately reflects its role.
2. Most functions that take a part of a FileLineInfoSpecifier end up
constructing a full one later or plumb two values through. Make them
all just take a complete FileLineInfoSpecifier.
3. Printing basenames only was handled differently from all other
variants, make it parallel to all the other variants.

Reviewers: jhenderson

Subscribers: hiraditya, MaskRay, rupprecht, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D76394

show more ...

Revert "Remove redundant "std::move"s in return statements"

The build failed with

error: call to deleted constructor of 'llvm::Error'

errors.

This reverts commit 1c2241a7936bf85aa68aef94bd40c3b

Revert "Remove redundant "std::move"s in return statements"

The build failed with

error: call to deleted constructor of 'llvm::Error'

errors.

This reverts commit 1c2241a7936bf85aa68aef94bd40c3ba77d8ddf2.

show more ...