[DebugInfo] Clean up LLVMSymbolizer::DemangleName API: const string& -> StringRef (#118056)

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

Identified with misc-include-cleaner.

[Symbolizer, DebugInfo] Clean up LLVMSymbolizer API: const string& -> StringRef (#104541)

Nothing in the affected code depends on the `ModuleName` being
null-terminated,
so take it by `StringRef`

[Symbolizer, DebugInfo] Clean up LLVMSymbolizer API: const string& -> StringRef (#104541)

Nothing in the affected code depends on the `ModuleName` being
null-terminated,
so take it by `StringRef` instead of `const std::string &`.

This change simplifies API consumption, since one doesn't always have a
`std::string` at the call site (might have `std::string_view` instead),
and also gives some minor performance improvements by removing
string-copies in the cache-hit path of `getOrCreateModuleInfo`.

show more ...

[Symbolizer] Support for Missing Line Numbers. (#82240)

LLVM Symbolizer attempt to symbolize addresses of optimized binaries
reports missing line numbers for some cases. It maybe due to compiler
w

[Symbolizer] Support for Missing Line Numbers. (#82240)

LLVM Symbolizer attempt to symbolize addresses of optimized binaries
reports missing line numbers for some cases. It maybe due to compiler
which sometimes cannot map an instruction to line number due to
optimizations. Symbolizer should handle those cases gracefully.

Adding an option '--skip-line-zero' to symbolizer so as to report the
nearest non-zero line number.

---------

Co-authored-by: Amit Pandey <amit.pandey@amd.com>

show more ...

[llvm-profgen] Support COFF binary (#83972)

Intel Vtune/SEP has supported collecting LBR on Windows and generating
perf-script file which is same format as Linux perf script. This patch
teaches ll

[llvm-profgen] Support COFF binary (#83972)

Intel Vtune/SEP has supported collecting LBR on Windows and generating
perf-script file which is same format as Linux perf script. This patch
teaches llvm-profgen to disassemble COFF binary so that we can do
Sampling based PGO on Windows.

show more ...

[llvm] Use SmallString::operator std::string (NFC)

[llvm] Use SmallString::operator std::string() (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 ...

[DebugInfo] Use StringRef::starts_with/ends_with instead of startswith/endswith. NFC.

startswith/endswith wrap starts_with/ends_with and will eventually go away (to more closely match string_view)

[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 ...

[BPF][DebugInfo] Use .BPF.ext for line info when DWARF is not available

"BTF" is a debug information format used by LLVM's BPF backend.
The format is much smaller in scope than DWARF, the following

[BPF][DebugInfo] Use .BPF.ext for line info when DWARF is not available

"BTF" is a debug information format used by LLVM's BPF backend.
The format is much smaller in scope than DWARF, the following info is
available:
- full set of C types used in the binary file;
- types for global values;
- line number / line source code information .

BTF information is embedded in ELF as .BTF and .BTF.ext sections.
Detailed format description could be found as a part of Linux Source
tree, e.g. here: [1].

This commit modifies `llvm-objdump` utility to use line number
information provided by BTF if DWARF information is not available.
E.g., the goal is to make the following to print source code lines,
interleaved with disassembly:

$ clang --target=bpf -g test.c -o test.o
$ llvm-strip --strip-debug test.o
$ llvm-objdump -Sd test.o

test.o: file format elf64-bpf

Disassembly of section .text:

<foo>:
; void foo(void) {
r1 = 0x1
; consume(1);
call -0x1
r1 = 0x2
; consume(2);
call -0x1
; }
exit

A common production use case for BPF programs is to:
- compile separate object files using clang with `-g -c` flags;
- link these files as a final "static" binary using bpftool linker ([2]).
The bpftool linker discards most of the DWARF sections
(line information sections as well) but merges .BTF and .BTF.ext sections.
Hence, having `llvm-objdump` capable to print source code using .BTF.ext
is valuable.

The commit consists of the following modifications:

- llvm/lib/DebugInfo/BTF aka `DebugInfoBTF` component is added to host
the code needed to process BTF (with assumption that BTF support
would be added to some other tools as well, e.g. `llvm-readelf`):
- `DebugInfoBTF` provides `llvm::BTFParser` class, that loads information
from `.BTF` and `.BTF.ext` sections of a given `object::ObjectFile`
instance and allows to query this information.
Currently only line number information is loaded.

- `DebugInfoBTF` also provides `llvm::BTFContext` class, which is an
implementation of `DIContext` interface, used by `llvm-objdump` to
query information about line numbers corresponding to specific
instructions.

- Structure `DILineInfo` is modified with field `LineSource`.

`DIContext` interface uses `DILineInfo` structure to communicate
line number and source code information.
Specifically, `DILineInfo::Source` field encodes full file source code,
if available. BTF only stores source code for selected lines of the
file, not a complete source file. Moreover, stored lines are not
guaranteed to be sorted in a specific order.

To avoid reconstruction of a file source code from a set of
available lines, this commit adds `LineSource` field instead.

- `Symbolize` class is modified to use `BTFContext` instead of
`DWARFContext` when DWARF sections are not available but BTF
sections are present in the object file.
(`Symbolize` is instantiated by `llvm-objdump`).

- Integration and unit tests.

Note, that DWARF has a notion of "instruction sequence".
DWARF implementation of `DIContext::getLineInfoForAddress()` provides
inexact responses if exact address information is not available but
address falls within "instruction sequence" with some known line
information (see `DWARFDebugLine::LineTable::findRowInSeq()`).

BTF does not provide instruction sequence groupings, thus
`getLineInfoForAddress()` queries only return exact matches.
This does not seem to be a big issue in practice, but output
of the `llvm-objdump -Sd` might differ slightly when BTF
is used instead of DWARF.

[1] https://www.kernel.org/doc/html/latest/bpf/btf.html
[2] https://github.com/libbpf/bpftool

Depends on https://reviews.llvm.org/D149501

Reviewed By: MaskRay, yonghong-song, nickdesaulniers, #debug-info

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

show more ...

[llvm-addr2line] Replace checkFileExists with getOrCreateModuleInfo

GNU addr2line exits immediately if -e (default to a.out) specifies a file that
cannot be open or a directory. llvm-addr2line used

[llvm-addr2line] Replace checkFileExists with getOrCreateModuleInfo

GNU addr2line exits immediately if -e (default to a.out) specifies a file that
cannot be open or a directory. llvm-addr2line used to wait for input on if the
input file cannot be open and addresses are not specified in command line.
Replace the D147652 checkFileExists with getOrCreateModuleInfo to avoid
a separate `sys::fs::status` operation.

Reviewed By: sepavloff

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

show more ...

[symbolizer] Check existence of input file in GNU mode

GNU addr2line exits immediately if it cannot open the file specified as
executable/relocatable. In contrast llvm-addr2line does not exit and, i

[symbolizer] Check existence of input file in GNU mode

GNU addr2line exits immediately if it cannot open the file specified as
executable/relocatable. In contrast llvm-addr2line does not exit and, if
addresses are not specified in command line, waits for input on stdin. This
causes the test compiler-rt/test/asan/TestCases/Posix/asan-symbolize-bad-path.cc to block
forever on Gentoo (see https://reviews.llvm.org/rG27c4777f41d2ab204c1cf84ff1cccd5ba41354da#1190273).
To fix this issue the behavior llvm-addr2line now exits if
executable/relocatable file cannot be found.

It fixes https://github.com/llvm/llvm-project/issues/42099 (llvm-addr2line
does not exit when passed a non-existent file).

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

show more ...

[Demangle] convert microsoftDemangle to take a std::string_view

This should be last of the "bottom-up conversions" of various demanglers
to accept std::string_view. After this, D149104 may be revis

[Demangle] convert microsoftDemangle to take a std::string_view

This should be last of the "bottom-up conversions" of various demanglers
to accept std::string_view. After this, D149104 may be revisited.

Reviewed By: MaskRay

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

show more ...

[Demangle] convert itaniumDemangle and nonMicrosoftDemangle to use std::string_view

D149104 converted llvm::demangle to use std::string_view. Enabling
"expensive checks" (via -DLLVM_ENABLE_EXPENSIVE

[Demangle] convert itaniumDemangle and nonMicrosoftDemangle to use std::string_view

D149104 converted llvm::demangle to use std::string_view. Enabling
"expensive checks" (via -DLLVM_ENABLE_EXPENSIVE_CHECKS=ON) causes
lld/test/wasm/why-extract.s to fail. The reason for this is obscure:

Reason #10007 why std::string_view is dangerous:
Consider the following pattern:

std::string_view s = ...;
const char *c = s.data();
std::strlen(c);

Is c a NUL-terminated C style string? It depends; but if it's not then
it's not safe to call std::strlen on the std::string_view::data().
std::string_view::length() should be used instead.

Fixing this fixes the one lone test that caught this.

microsoftDemangle, rustDemangle, and dlangDemangle should get this same
treatment, too. I will do that next.

Reviewed By: MaskRay, efriedma

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

show more ...

[symbolizer] Change error message if module not found (recommit)

This is a recommit of 75f1f158812d, reverted in 7a443b1c493d, because
it caused compilation error in
compiler-rt/lib/sanitizer_common

[symbolizer] Change error message if module not found (recommit)

This is a recommit of 75f1f158812d, reverted in 7a443b1c493d, because
it caused compilation error in
compiler-rt/lib/sanitizer_common/symbolizer/sanitizer_symbolize.cpp.
The error was fixed by Kasimir Georgiev in de4c038c7ba2, but this
commit was reverted in de088dd3a0aa, because the initial commit was
reverted.

This commit reverts both the reverting commits, 7a443b1c493d and
de088dd3a0aa.

Original commit message is below.

If llvm-symbolize did not find module, the error looked like:

LLVMSymbolizer: error reading file: No such file or directory

This message does not follow common practice: LLVMSymbolizer is not an
utility name. Also the message did not not contain the name of missed file.

With this change the error message looks differently:

llvm-symbolizer: error: 'abc': No such file or directory

This format is closer to messages produced by other utilities and allow
proper coloring.

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

show more ...

[Demangle] remove unused params of microsoftDemangle

No call sites use these parameters, so drop them.

Reviewed By: MaskRay

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

Revert "[symbolizer] Change error message if module not found"

This reverts commit 75f1f158812dabc03e70697b6b9c272230bce63d.
It caused fail on https://lab.llvm.org/buildbot#builders/37/builds/21461

[symbolizer] Change error message if module not found

If llvm-symbolize did not find module, the error looked like:

LLVMSymbolizer: error reading file: No such file or directory

This message d

[symbolizer] Change error message if module not found

If llvm-symbolize did not find module, the error looked like:

LLVMSymbolizer: error reading file: No such file or directory

This message does not follow common practice: LLVMSymbolizer is not an
utility name. Also the message did not not contain the name of missed file.

With this change the error message looks differently:

llvm-symbolizer: error: 'abc': No such file or directory

This format is closer to messages produced by other utilities and allow
proper coloring.

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

show more ...

[Object] Refactor build ID parsing into Object lib.

This makes parsing for build IDs in the markup filter slightly more
permissive, in line with fromHex.

It also removes the distinction between mis

[Object] Refactor build ID parsing into Object lib.

This makes parsing for build IDs in the markup filter slightly more
permissive, in line with fromHex.

It also removes the distinction between missing build ID and empty build
ID; empty build IDs aren't a useful concept, since their purpose is to
uniquely identify a binary. This removes a layer of indirection wherever
build IDs are obtained.

Reviewed By: jhenderson

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

show more ...

[Symbolize][MinGW] Support demangling i386 call-conv-decorated C++ names

On i386 Windows, after C++ names have been Itanium-mangled, the C name
mangling specific to its call convention may also be a

[Symbolize][MinGW] Support demangling i386 call-conv-decorated C++ names

On i386 Windows, after C++ names have been Itanium-mangled, the C name
mangling specific to its call convention may also be applied on top.
This change teaches symbolizer to be able to demangle this type of
mangled names.

As part of this change, `demanglePE32ExternCFunc` has also been modified
to fix unwanted stripping for vectorcall names when the demangled name
is supposed to contain a leading `_`. Notice that the vectorcall
mangling does not add either an `_` or `@` prefix. The old code always
tries to strip the prefix first, which for Itanium mangled names in
vectorcall, the leading underscore of the Itanium name gets stripped
instead and breaks the Itanium demangler.

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

show more ...

[Object] llvm::Optional => std::optional

[llvm] Remove unused forward declarations (NFC)