aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/DebugInfo/Symbolize/SymbolizableObjectFile.cpp
AgeCommit message (Collapse)AuthorFilesLines
2025-03-25[Symbolize] Always use filename:line from debug info when debug info for the ↵Zequan Wu1-6/+13
given address is available. (#128619) To reland https://github.com/llvm/llvm-project/pull/124846, we need to make symbolizer consistent with the case when line number is 0. Always using filename and line from debug info even if the line number is 0 sounds like the reasonable path to go.
2025-03-17[NFC][DebugInfo] Wrap DILineInfo return type with std::optional to handle ↵Zequan Wu1-6/+10
missing debug info. (#129792) Currently, `DIContext::getLineInfoForAddress` and `DIContext::getLineInfoForDataAddress` returns empty DILineInfo when the debug info is missing for the given address. This is not differentiable with the case when debug info is found for the given address but the debug info is default value (filename:linenum is <invalid>:0). This change wraps the return types of `DIContext::getLineInfoForAddress` and `DIContext::getLineInfoForDataAddress` with `std::optional`.
2024-11-17[DebugInfo] Remove unused includes (NFC) (#116551)Kazu Hirata1-1/+0
Identified with misc-include-cleaner.
2024-05-07[Analysis, CodeGen, DebugInfo] Use StringRef::operator== instead of ↵Kazu Hirata1-1/+1
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".
2024-01-17[DebugInfo] Use StringRef::consume_front (NFC)Kazu Hirata1-2/+2
2023-12-15[symbolizer] Support symbol+offset lookup (#75067)Serge Pavlov1-3/+5
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
2023-11-01[symbolizer] Support symbol lookupSerge Pavlov1-0/+13
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
2023-10-02Revert "[symbolizer] Support symbol lookup"Serge Pavlov1-13/+0
This reverts commit 2b27948783e4bbc1132d3220d8517ef62607b558. On some buildbots the test LLVM::interrupts.test start failing.
2023-10-02[symbolizer] Support symbol lookupSerge Pavlov1-0/+13
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
2023-02-07[NFC][TargetParser] Remove llvm/ADT/Triple.hArchibald Elliott1-1/+1
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.
2022-09-13Don't populate the symbol table with symbols that don't belong to a section ↵George Wright1-0/+5
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
2022-05-23[symbolizer] Parse DW_TAG_variable DIs to show line info for globalsMitch Phillips1-0/+8
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
2022-02-03[DebugInfo] Move the SymbolizableObjectFile header to include/llvm.Snehasish Kumar1-1/+1
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
2021-05-19[symbolizer] Added StartAddress for the resolved function.Alex Orlov1-0/+2
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
2021-02-12DebugInfo/Symbolize: Exclude ARM mapping symbols for .symtab symbolization ↵Fangrui Song1-0/+5
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-11DebugInfo/Symbolize: Use stable_sortFangrui Song1-1/+1
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).
2021-02-11DebugInfo/Symbolize: Don't differentiate function/data symbolizationFangrui Song1-35/+22
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-10DebugInfo/Symbolize: Retrieve filename from the preceding STT_FILE for ↵Fangrui Song1-33/+59
.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-08DebugInfo/Symbolize: Allow STT_NOTYPE/STT_GNU_IFUNC symbols for .symtab ↵Fangrui Song1-8/+25
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
2020-09-17SymbolizableObjectFile.h - remove unnecessary includes. NFCI.Simon Pilgrim1-9/+0
Use forward declarations where possible, move includes down to SymbolizableObjectFile.cpp and avoid duplicate includes.
2020-06-11Re-land "Migrate the rest of COFFObjectFile to Error"Reid Kleckner1-19/+21
This reverts commit 101fbc01382edd89ea7b671104c68b30b2446cc0. Remove leftover debugging attribute. Update LLDB as well, which was missed before.
2020-06-05Revert "Migrate the rest of COFFObjectFile to Error"Nico Weber1-21/+19
This reverts commit b5289656b865d2a73cf90819e20a96fb8414ab0b. __attribute__((optnone)) doesn't build with msvc, see http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/16326
2020-06-05Migrate the rest of COFFObjectFile to ErrorReid Kleckner1-19/+21
2020-03-20Cleanup the plumbing for DILineInfoSpecifier. [NFC - Try 2]Sterling Augustine1-14/+8
2020-03-19Revert "Cleanup the plumbing for DILineInfoSpecifier. [NFC]"Sterling Augustine1-8/+14
This broke lldb. Will fix and resubmit. This reverts commit 98ff6eb679cd5a2556d990d3d629e6c03c1da6a0.
2020-03-19Cleanup the plumbing for DILineInfoSpecifier. [NFC]Sterling Augustine1-14/+8
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
2020-02-10Revert "Remove redundant "std::move"s in return statements"Bill Wendling1-1/+1
The build failed with error: call to deleted constructor of 'llvm::Error' errors. This reverts commit 1c2241a7936bf85aa68aef94bd40c3ba77d8ddf2.
2020-02-10Remove redundant "std::move"s in return statementsBill Wendling1-1/+1
2019-08-14Recommit r368812 "[llvm/Object] - Convert SectionRef::getName() to return ↵George Rimar1-4/+5
Expected<>" Changes: no changes. A fix for the clang code will be landed right on top. Original commit message: SectionRef::getName() returns std::error_code now. Returning Expected<> instead has multiple benefits. For example, it forces user to check the error returned. Also Expected<> may keep a valuable string error message, what is more useful than having a error code. (Object\invalid.test was updated to show the new messages printed.) This patch makes a change for all users to switch to Expected<> version. Note: in a few places the error returned was ignored before my changes. In such places I left them ignored. My intention was to convert the interface used, and not to improve and/or the existent users in this patch. (Though I think this is good idea for a follow-ups to revisit such places and either remove consumeError calls or comment each of them to clarify why it is OK to have them). Differential revision: https://reviews.llvm.org/D66089 llvm-svn: 368826
2019-08-14Revert r368812 "[llvm/Object] - Convert SectionRef::getName() to return ↵George Rimar1-5/+4
Expected<>" It broke clang BB: http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/16455 llvm-svn: 368813
2019-08-14[llvm/Object] - Convert SectionRef::getName() to return Expected<>George Rimar1-4/+5
SectionRef::getName() returns std::error_code now. Returning Expected<> instead has multiple benefits. For example, it forces user to check the error returned. Also Expected<> may keep a valuable string error message, what is more useful than having a error code. (Object\invalid.test was updated to show the new messages printed.) This patch makes a change for all users to switch to Expected<> version. Note: in a few places the error returned was ignored before my changes. In such places I left them ignored. My intention was to convert the interface used, and not to improve and/or the existent users in this patch. (Though I think this is good idea for a follow-ups to revisit such places and either remove consumeError calls or comment each of them to clarify why it is OK to have them). Differential revision: https://reviews.llvm.org/D66089 llvm-svn: 368812
2019-08-06Switch LLVM to use 64-bit offsets (2/5)Igor Kudrin1-4/+2
This updates all libraries and tools in LLVM Core to use 64-bit offsets which directly or indirectly come to DataExtractor. Differential Revision: https://reviews.llvm.org/D65638 llvm-svn: 368014
2019-08-06Silence ubsan after r367926.Peter Collingbourne1-0/+1
Fixes e.g. http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap-ubsan/builds/14273 We can't left shift here because left shifting of a negative number is UB. The same doesn't apply to unsigned arithmetic, but switching to unsigned doesn't appear to stop ubsan from complaining, so we need to mask out the high bits. llvm-svn: 367959
2019-08-05llvm-symbolizer: Untag addresses in object files by default.Peter Collingbourne1-4/+12
Any addresses that we pass to llvm-symbolizer are going to be untagged, while any HWASAN instrumented globals are going to be tagged in the symbol table. Therefore we need to untag the addresses before using them. Differential Revision: https://reviews.llvm.org/D65769 llvm-svn: 367926
2019-07-08Teach the symbolizer lib symbolize objects directly.Yuanfang Chen1-2/+2
Currently, the symbolizer lib can only symbolize a file on disk. This patch teaches the symbolizer lib to symbolize objects. llvm-objdump needs this to support archive disassembly with source info. https://bugs.llvm.org/show_bug.cgi?id=41871 Reviewed by: jhenderson, grimar, MaskRay Differential Revision: https://reviews.llvm.org/D63521 llvm-svn: 365376
2019-06-24llvm-symbolizer: Add a FRAME command.Peter Collingbourne1-0/+8
This command prints a description of the referenced function's stack frame. For each formal parameter and local variable, the tool prints: - function name - variable name - file/line of declaration - FP-relative variable location (if available) - size in bytes - HWASAN tag offset This information will be used by the HWASAN runtime to identify local variables in UAR reports. Differential Revision: https://reviews.llvm.org/D63468 llvm-svn: 364225
2019-06-13Symbolize: Remove dead code. NFCI.Peter Collingbourne1-11/+5
The only caller of SymbolizableObjectFile::create passes a non-null DebugInfoContext and asserts that they do so. Move the assert into SymbolizableObjectFile::create and remove null checks. Differential Revision: https://reviews.llvm.org/D63298 llvm-svn: 363334
2019-05-16Recommit [Object] Change object::SectionRef::getContents() to return ↵Fangrui Song1-4/+4
Expected<StringRef> r360876 didn't fix 2 call sites in clang. Expected<ArrayRef<uint8_t>> may be better but use Expected<StringRef> for now. Follow-up of D61781. llvm-svn: 360892
2019-05-16Revert r360876 "[Object] Change object::SectionRef::getContents() to return ↵Hans Wennborg1-4/+4
Expected<StringRef>" It broke the Clang build, see llvm-commits thread. > Expected<ArrayRef<uint8_t>> may be better but use Expected<StringRef> for now. > > Follow-up of D61781. llvm-svn: 360878
2019-05-16[Object] Change object::SectionRef::getContents() to return Expected<StringRef>Fangrui Song1-4/+4
Expected<ArrayRef<uint8_t>> may be better but use Expected<StringRef> for now. Follow-up of D61781. llvm-svn: 360876
2019-04-20[llvm-symbolizer] Fix section index at the end of a sectionFangrui Song1-2/+1
This is very minor issue. The returned section index is only used by DWARFDebugLine as an llvm::upper_bound input and the use case shouldn't cause any behavioral change. llvm-svn: 358814
2019-04-06[Symbolize] Uniquify sorted vector<pair<SymbolDesc, StringRef>>Fangrui Song1-7/+16
llvm-svn: 357833
2019-04-05[Symbolize] Replace map<SymbolDesc, StringRef> with sorted vectorFangrui Song1-8/+14
llvm-svn: 357758
2019-04-04[Symbolize] Keep SymbolDescs with the same address and improve ↵Fangrui Song1-1/+4
getNameFromSymbolTable heuristic I'll follow up with better heuristics or tests. llvm-svn: 357683
2019-03-23 [DebugInfo] follow up for "add SectionedAddress to DebugInfo interfaces"Alexey Lapshin1-0/+26
[Symbolizer] Add getModuleSectionIndexForAddress() helper routine The https://reviews.llvm.org/D58194 patch changed symbolizer interface. Particularily it requires not only Address but SectionIndex also. Note object::SectionedAddress parameter: Expected<DILineInfo> symbolizeCode(const std::string &ModuleName, object::SectionedAddress ModuleOffset, StringRef DWPName = ""); There are callers of symbolizer which do not know particular section index. That patch creates getModuleSectionIndexForAddress() routine which will detect section index for the specified address. Thus if caller set ModuleOffset.SectionIndex into object::SectionedAddress::UndefSection state then symbolizer would detect section index using getModuleSectionIndexForAddress routine. Differential Revision: https://reviews.llvm.org/D58848 llvm-svn: 356829
2019-02-27[DebugInfo] add SectionedAddress to DebugInfo interfaces.Alexey Lapshin1-9/+12
That patch is the fix for https://bugs.llvm.org/show_bug.cgi?id=40703 "wrong line number info for obj file compiled with -ffunction-sections" bug. The problem happened with only .o files. If object file contains several .text sections then line number information showed incorrectly. The reason for this is that DwarfLineTable could not detect section which corresponds to specified address(because address is the local to the section). And as the result it could not select proper sequence in the line table. The fix is to pass SectionIndex with the address. So that it would be possible to differentiate addresses from various sections. With this fix llvm-objdump shows correct line numbers for disassembled code. Differential review: https://reviews.llvm.org/D58194 llvm-svn: 354972
2019-02-14[symbolizer] Avoid collecting symbols belonging to invalid sections.Matt Davis1-0/+5
Summary: llvm-symbolizer would originally report symbols that belonged to an invalid object file section. Specifically the case where: `*Symbol.getSection() == ObjFile.section_end()` This patch prevents the Symbolizer from collecting symbols that belong to invalid sections. The test (from PR40591) introduces a case where two symbols have address 0, one symbol is defined, 'foo', and the other is not defined, 'bar'. This patch will cause the Symbolizer to keep 'foo' and ignore 'bar'. As a side note, the logic for adding symbols to the Symbolizer's store (`SymbolizableObjectFile::addSymbol`) replaces symbols with the same <address, size> pair. At some point that logic should be revisited as in the aforementioned case, 'bar' was overwriting 'foo' in the Symbolizer's store, and 'foo' was forgotten. This fixes PR40591 Reviewers: jhenderson, rupprecht Reviewed By: rupprecht Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58146 llvm-svn: 354083
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-4/+3
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2018-07-30Remove trailing spaceFangrui Song1-1/+1
sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338293
2017-06-07Move Object format code to lib/BinaryFormat.Zachary Turner1-1/+1
This creates a new library called BinaryFormat that has all of the headers from llvm/Support containing structure and layout definitions for various types of binary formats like dwarf, coff, elf, etc as well as the code for identifying a file from its magic. Differential Revision: https://reviews.llvm.org/D33843 llvm-svn: 304864
generated by cgit v1.1 at 2025-09-29 16:40:58 +0000