7 Commits

Author SHA1 Message Date
Fangrui Song
a7ceef9254 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
2021-02-12 11:04:20 -08:00
Fangrui Song
92ee3dd95d 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
2021-02-11 19:22:44 -08:00
Fangrui Song
04a2e12612 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
2021-02-10 09:47:10 -08:00
Fangrui Song
b799289911 [test] Drop redundant REQUIRES: x86-registered-target 2021-02-08 23:36:37 -08:00
Fangrui Song
b48aea43d0 [test] Add REQUIRES: x86-registered-target to DebugInfo/Symbolize/ELF llvm-mc tests 2021-02-08 23:34:41 -08:00
Douglas Yung
4c23e42fe5 Mark 4 tests added in 6d766c8bf9df as requiring an x86 backend as they fail when it is not present.
This should fix buildbot failures like http://lab.llvm.org:8011/#/builders/107/builds/4469
2021-02-08 22:47:14 -08:00
Fangrui Song
6d766c8bf9 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
2021-02-08 12:29:11 -08:00