aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/DebugInfo/DWARF/DWARFContext.cpp
AgeCommit message (Collapse)AuthorFilesLines
35 hours[llvm] Use llvm::iterator_range::empty (NFC) (#151905)Kazu Hirata1-1/+1
2025-06-04Revert gsymutil changes due to concurrency problems (#142829)peremyach1-9/+0
We saw occasional segfaults while processing some binaries. The reason probably is that we may clear the DIE while we are reading it's data from another thread which happens due to cross-unit references. --------- Co-authored-by: Arslan Khabutdinov <akhabutdinov@fb.com>
2025-05-21Reduce llvm-gsymutil memory usage (#140740)peremyach1-0/+9
Same as https://github.com/llvm/llvm-project/pull/139907/ except there is now a special dovoidwork helper function. Previous approach with assert(f();return success;) failed tests for release builds, so I created a separate helper. Open to suggestions how to solve this more elegantly. Co-authored-by: Arslan Khabutdinov <akhabutdinov@fb.com>
2025-05-20[DebugInfo] Use std::map::try_emplace (NFC) (#140839)Kazu Hirata1-3/+3
This patch provides default member initialization for SymInfo, which in turns allows us to call std::map::try_emplace without the value.
2025-05-20Revert "Reduce llvm-gsymutil memory usage" (#140696)peremyach1-9/+0
Reverts llvm/llvm-project#139907 as per discussion in https://github.com/llvm/llvm-project/issues/140545 due to tests becoming flaky
2025-05-16Reduce llvm-gsymutil memory usage (#139907)peremyach1-1/+8
For large binaries gsymutil ends up using too much memory. This diff adds DIE tree cleanup per compile unit to reduce memory usage. P. S. Not sure about formatting. Maybe it hasn't been run in a while, or I have misconfigured something. `$ git clang-format HEAD~1 clang-format did not modify any files $ clang-format --version clang-format version 21.0.0git (git@github.com:peremyach/llvm-project.git 8d945c8357e1bd9872a34f92620d4916bfd27482) ` Co-authored-by: Arslan Khabutdinov <akhabutdinov@fb.com>
2025-04-09Revert "Reland "Symbolize line zero as if no source info is available ↵Zequan Wu1-1/+1
(#124846)" (#133798)" This reverts commit 348374028970c956f2e49ab7553b495d7408ccd9 because #128619 doesn't handle the case when we have an empty frame from `getInliningInfoForAddress` because line num is 0 which makes it non-differentiable from missing debug info. So, we end up using the base filename from symtab again. Reverting for now until that issus is solved.
2025-03-31Reland "Symbolize line zero as if no source info is available (#124846)" ↵Zequan Wu1-1/+1
(#133798) This land commits 23aca2f88dd5d2447e69496c89c3ed42a56f9c31 and 1b15a89a23c631a8e2d096dad4afe456970572c0. https://github.com/llvm/llvm-project/pull/128619 makes symbolizer to always use debug info when available so we can reland this chagnge.
2025-03-25[Symbolize] Always use filename:line from debug info when debug info for the ↵Zequan Wu1-2/+2
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-3/+4
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`.
2025-02-24Revert "Symbolize line zero as if no source info is available (#124846)"Zequan Wu1-1/+1
This commit creates an inconsistency on `__sanitizer_symbolize_pc` API. Before this change, this API always uses the filename from debug info when the line number is 0. After this change, the filename becomes invalid when line number is 0. The sanitizer might fall back to use base filename from symbol table. So, this API may return either `??:0` or `{filename from symbol table}:0` depending on if the symbol table has the filename for it. Make sure this inconsistency is resolved before relanding the commit.
2025-02-06Symbolize line zero as if no source info is available (#124846)David Blaikie1-1/+1
Since line zero means "no line information", when symbolizing a location (an address or an inline frame associated with the address) that has a line zero location, we shouldn't include other irrelevant data (like filename) in the result.
2024-11-17[DebugInfo] Remove unused includes (NFC) (#116551)Kazu Hirata1-2/+0
Identified with misc-include-cleaner.
2024-10-22Add verification support for .debug_names with foreign type units. (#109011)Greg Clayton1-2/+3
This commit enables 'llvm-dwarfdump --veriy' to verify the DWARF in foreign type units when using split DWARF for the .debug_names section.
2024-08-13Add support for verifying .debug_names in split DWARF for CUs and TUs. (#101775)Greg Clayton1-2/+5
This patch fixes .debug_names verification for split DWARF with no type units. It will print out an error for any name entries where we can't locate the .dwo file. It finds the non skeleton unit and correctly figures out the DIE offset in the .dwo file. If the non skeleton unit is found and yet the skeleton unit has a DWO ID, an error will be emitted showing we couldn't access the non-skeleton compile unit.
2024-08-05[Symbolizer] Support for Missing Line Numbers. (#82240)Amit Kumar Pandey1-7/+8
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>
2024-07-10[DWARF] Hide state in an anonymous namespace. NFC.Benjamin Kramer1-2/+2
2024-06-14[llvm] Use llvm::unique (NFC) (#95628)Kazu Hirata1-7/+8
2024-02-01Aggregate errors from llvm-dwarfdump --verify (#79648)Kevin Frei1-0/+1
The amount and format of output from `llvm-dwarfdump --verify` makes it quite difficult to know if a change to a tool that produces or modifies DWARF is causing new problems, or is fixing existing problems. This diff adds a categorized summary of issues found by the DWARF verifier, on by default, at the bottom of the error output. The change includes a new `--error-display` option with 4 settings: * `--error-display=quiet`: Only display if errors occurred, but no details or summary are printed. * `--error-display=summary`: Only display the aggregated summary of errors with no error detail. * `--error-display=details`: Only display the detailed error messages with no summary (previous behavior) * `--error-display=full`: Display both the detailed error messages and the aggregated summary of errors (the default) I changed a handful of tests that were failing due to new output, adding the flag to use the old behavior for all but a couple. For those two I added the new aggregated output to the expected output of the test. The `OutputCategoryAggregator` is a pretty simple little class that @clayborg suggested to allow code to only be run to dump detail if it's enabled, while still collating counts of the category. Knowing that the lambda passed in is only conditionally executed is pretty important (handling errors has to be done *outside* the lambda). I'm happy to move this somewhere else (and change/improve it) to be more broadly useful if folks would like. --------- Co-authored-by: Kevin Frei <freik@meta.com>
2024-01-22[DebugInfo] Use DenseMap::lookup (NFC)Kazu Hirata1-5/+1
2024-01-12Allow the dumping of .dwo files contents to show up when dumping an ↵Greg Clayton1-4/+35
executable with split DWARF. (#66726) Allow the dumping of .dwo files contents to show up when dumping an executable with split DWARF. Currently if you run llvm-dwarfdump on a binary that has skeleton compile units, you only see the skeleton compile units. Since the main binary has the linked addresses it would be nice to be able to dump DWARF from the .dwo files and how the resolved addresses instead of showing the address index and "<unresolved>" in the output. This patch adds an option that can be specified to dump the non skeleton DIEs named --dwo. Added the ability to use the following options with split dwarf as well: --name <name> --lookup <addr> --debug-info <die-offset>
2023-11-08Make DWARFUnitVector threadsafe. (#71487)Greg Clayton1-1/+4
The DWARFUnitVector class lives inside of the DWARFContextState. Prior to this fix a non const reference was being handed out to clients. When fetching the DWO units, there used to be a "bool Lazy" parameter that could be passed that would allow the DWARFUnitVector to parse individual units on the fly. There were two major issues with this approach: - not thread safe and causes crashes - the accessor would check if DWARFUnitVector was empty and if not empty it would return a partially filled in DWARFUnitVector if it was constructed with "Lazy = true" This patch fixes the issues by always fully parsing the DWARFUnitVector when it is requested and only hands out a "const DWARFUnitVector &". This allows the thread safety mechanism built into the DWARFContext class to work corrrectly, and avoids the issue where if someone construct DWARFUnitVector with "Lazy = true", and then calls an API that partially fills in the DWARFUnitVector with individual entries, and then someone accesses the DWARFUnitVector, they would get a partial and incomplete listing of the DWARF units for the DWOs.
2023-11-06[DebugInfo] Use StringRef::starts_with/ends_with instead of ↵Simon Pilgrim1-1/+1
startswith/endswith. NFC. startswith/endswith wrap starts_with/ends_with and will eventually go away (to more closely match string_view)
2023-10-19[DebugInfo] Correctly report header parsing errors from ↵Alex Langford1-6/+4
DWARFContext::fixupIndex (#69505) In ef762e5e7292, I shifted around where errors were reported when failing to parse and/or validate DWARFUnitHeaders. When we are doing so in DWARFContext::fixupIndex, the actual error message isn't prefixed with `warning:` like it would be elsewhere (because of the way `logAllUnhandledErrors` is implemented).
2023-10-18[DebugInfo] Separate error generation from reporting in ↵Alex Langford1-4/+10
DWARFHeaderUnit::extract (#68242) Instead of reporting the error directly through the DWARFContext passed in as an argument, it would be more flexible to have extract return the error and allow the caller to react appropriately. This will be useful for using llvm's DWARFHeaderUnit from lldb which may report header extraction errors through a different mechanism.
2023-10-10[LLVM][DWARF] Create thread safe context for DWO/DWP DWARFContext (#68262)Alexander Yermolovich1-2/+12
Right now DWARFContext for DWO/DWP that is created is not thread safe. Changed it so that thread safety is inherited from the main binary DWARFContext.
2023-10-04DWARFContext: use std::make_unique rather than reset+newDavid Blaikie1-4/+4
2023-10-04use std::make_unique rather than reset+newDavid Blaikie1-2/+2
2023-09-19Addressed review comments to use ThreadSafe instead of !ThreadSafekstoimenov1-2/+2
2023-09-01Make DWARFContext more thread safe.Greg Clayton1-421/+706
llvm-gsymutil uses a DWARFContext from multiple threads as it parses each compile unit. As it finds issues it might end up dumping a DIE to an output stream which can cause accesses to the DWARFContext from multiple threads. In llvm-gsymutil it can end up dumping a DIE from multiple threads into thread specific stream which was causing DWARFContext::getTUIndex() to be called and can crash the process. This fix puts a recursive mutex into the DWARFContext class and makes most APIs threadsafe for access. Many of the methods in DWARFContext will check if a member variable has been filled in yet, and parse what is needed and populate a member variagle with the results. Now a mutex protects these functions. Differential Revision: https://reviews.llvm.org/D157459
2023-08-30[NFC] Remove unused variables declared in conditionsTakuya Shimizu1-1/+1
D152495 makes clang warn on unused variables that are declared in conditions like `if (int var = init) {}` This patch is an NFC fix to suppress the new warning in llvm,clang,lld builds to pass CI in the above patch. Differential Revision: https://reviews.llvm.org/D158016
2023-06-24[DWARF] Remove remnant .zdebug section recognitionFangrui Song1-8/+2
There is a minor behavior difference that is not worth testing for the obsoleted format. Previously, llvm-dwarfdump considers .zdebug_info as a debug section but does not decompress it, leading to a warning when the content cannot be parsed. Now llvm-dwarfdump just ignores the section without a warning.
2023-06-24[DWARF] Adjust warning condition for .dwo sections with relocationsFangrui Song1-4/+6
D106624 added a .dwo warning (when there are relocations) that may fire for non-debug sections, e.g. `.rodata.dwo` when there is a data symbol foo in -fdata-sections mode. Adjust it to only warn for .debug sections. While here, change the diagnostic to be more conventional https://llvm.org/docs/CodingStandards.html#error-and-warning-messages and use the relocated section name instead of the relocation section name. This change does not handle `.zdebug` (support was mostly removed from LLVM) or `__debug` (Mach-O, no DWO support). Reviewed By: ayermolo, HaohaiWen Differential Revision: https://reviews.llvm.org/D153602
2023-06-16[DebugInfo][NFCI] Follow-up to 0356ceedf2e9Alex Langford1-2/+2
2023-06-16[DebugInfo] Change DWARFDebugAbbrev initializationAlex Langford1-5/+2
I plan on adding better error handling to DWARFDebugAbbrev, but first I want us to be able to better reason about a state of a DWARFDebugAbbrev. I want us to be able to initialize a DWARFDebugAbbrev in its complete state instead of creating it and then calling an `extract` method manually. If its Data field is populated, then parsing is not complete. If Data is `std::nullopt`, then parsing is done and this section is "finalized" in some sense. Additionally, I have removed the `clear()` method. This makes sense for other classes like DWARFAbbreviationDeclaration where we may want to re-use an object repeatedly to avoid repeated initializations and allocations, but for DWARFDebugAbbrev we pretty much create one and stick with it. Differential Revision: https://reviews.llvm.org/D152947
2023-06-05llvm-dwarfdump --verify: Add support for .debug_str_offsets[.dwo]David Blaikie1-0/+2
Had a couple of issues lately causing corrupted strings due to problematic str_offsets (overflow due to >4GB .debug_str.dwo section in a dwp and the dwp tool silently overflowing the 32 bit offsets updated in the .debug_str_offsets.dwo section, and then more recently two CUs in a dwo caused the dwp tool to reapply the offset adjustment twice corrupting str_offsets.dwo as well) - so let's check that the offsets are valid. This assumes no suffix merging - if anyone implements that, then this checking should just be removed for the most part (we could still check the offsets are within the bounds of .debug_str[.dwo], but nothing more - any offset in the range would be valid, the offsets wouldn't have to land at the start of a string)
2023-04-20[dwarfdump][dwarf] Fix parsing of tu-indexAlexander Yermolovich1-0/+2
Fixed issue where {tu,cu}-index fixup code for DWARF5 that would report an error when fixup map is empty. Which is the case when seciton(s) are not over 4GB or --manaully-generate-unit-index is not specified Differential Revision: https://reviews.llvm.org/D148578
2023-04-16[llvm] Apply fixes from readability-redundant-control-flow (NFC)Kazu Hirata1-2/+0
2023-03-28DebugInfo: Rebuild dwp debug_info index column from v5 indexes more robustlyDavid Blaikie1-4/+53
the v4 rebuilding is a best-effort because it's not possible to reliably parse the DWO ID as it requires the abbrev section (& if the index isn't trustworthy then there's no way to find the associated abbrev section contribution for a given info section contribution) But in v5 the DWO ID/type signature is in the header and can be rebuilt losslessly (only at the cost of performance of rescanning/parsing the headers of all the units), so let's implement that. the testing isn't /ideal/ - I think the testing should've been implemented as a hardcoded dwp file with a corrupted/incorrect index, then the test could've demonstrated that reparsing the index produces the right answer - but this is a quick port of the existing v5 test back to v4 so that we don't lose coverage on the v4 codepath now that it's separated from the v5 codepath. Differential Revision: https://reviews.llvm.org/D146662
2023-03-07Split getCompileUnitFor{Data,Code}Address.Mitch Phillips1-10/+13
Getting compile units for data addresses is much slower, as it often requires a slow fallback path to walk every DWARF entry, as data addresses don't fall into the compilation unit ranges. Most lookups are code addresses, and don't need this logic. Split the functionality out so that we restore the fast-path behaviour for the code lookups. More context at: https://discourse.llvm.org/t/llvm-symbolizer-has-gotten-extremely-slow/67262 Reviewed By: dblaikie Differential Revision: https://reviews.llvm.org/D145009
2023-01-12[DWARFLibrary] Add support to re-construct cu-indexAlexander Yermolovich1-3/+74
According to DWARF5 specification and gnu specification for DWARF4 the offset entry in the CU/TU Index is 32 bits. This presents a problem when .debug_info.dwo in DWP file grows beyond 4GB. The CU Index becomes partially corrupted. This diff adds manual parsing of .debug_info.dwo/.debug_abbrev.dwo to reconstruct CU index in general, and TU index for DWARF5. This is a work around until DWARF6 spec is finalized. Next patch will change internal CU/TU struct to 64 bit, and change uses as necessary. The plan is to land all the patches in one go after all are approved. This patch originates from the discussion in: https://discourse.llvm.org/t/dwarf-dwp-4gb-limit/63902 Reviewed By: dblaikie Differential Revision: https://reviews.llvm.org/D137882
2023-01-11Revert "[DWARFLibrary] Add support to re-construct cu-index"Dmitri Gribenko1-73/+2
This reverts commit 73712c8790a93c29e513f5e201f92ac5b2370cf9. It causes a MemorySanitizer error in LLVM testsuite. See the discussion on https://reviews.llvm.org/D137882 for details.
2023-01-10[DWARFLibrary] Add support to re-construct cu-indexAlexander Yermolovich1-2/+73
According to DWARF5 specification and gnu specification for DWARF4 the offset entry in the CU/TU Index is 32 bits. This presents a problem when .debug_info.dwo in DWP file grows beyond 4GB. The CU Index becomes partially corrupted. This diff adds manual parsing of .debug_info.dwo/.debug_abbrev.dwo to reconstruct CU index in general, and TU index for DWARF5. This is a work around until DWARF6 spec is finalized. Next patch will change internal CU/TU struct to 64 bit, and change uses as necessary. The plan is to land all the patches in one go after all are approved. This patch originates from the discussion in: https://discourse.llvm.org/t/dwarf-dwp-4gb-limit/63902 Reviewed By: dblaikie Differential Revision: https://reviews.llvm.org/D137882
2022-12-16std::optional::value => operator*/operator->Fangrui Song1-3/+2
value() has undesired exception checking semantics and calls __throw_bad_optional_access in libc++. Moreover, the API is unavailable without _LIBCPP_NO_EXCEPTIONS on older Mach-O platforms (see _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS). This commit fixes LLVMAnalysis and its dependencies.
2022-12-15Remove the dependency between lib/DebugInfoDWARF and MC.Shubham Sandeep Rastogi1-32/+12
Differential Revision: https://reviews.llvm.org/D134817
2022-12-14Revert "Remove the dependency between lib/DebugInfoDWARF and MC."Shubham Sandeep Rastogi1-12/+32
This reverts commit 7dde94251e1c9e4634f5d51d41f2d4a191258fb3. Because of test failures: lldb-shell :: SymbolFile/DWARF/x86/DW_AT_loclists_base.s lldb-shell :: SymbolFile/DWARF/x86/debug_loc.s lldb-shell :: SymbolFile/DWARF/x86/debug_loc_and_loclists.s lldb-shell :: SymbolFile/DWARF/x86/debug_loclists-dwo.s lldb-shell :: SymbolFile/DWARF/x86/debug_loclists-dwp.s lldb-shell :: SymbolFile/DWARF/x86/dwp.s lldb-shell :: SymbolFile/DWARF/x86/unused-inlined-params.test lldb-shell :: SymbolFile/NativePDB/inline_sites.test lldb-shell :: SymbolFile/NativePDB/local-variables-registers.s lldb-shell :: SymbolFile/NativePDB/nested-blocks-same-address.s
2022-12-14Remove the dependency between lib/DebugInfoDWARF and MC.Shubham Sandeep Rastogi1-32/+12
Differential Revision: https://reviews.llvm.org/D134817
2022-12-07Revert "[DWARFLibrary] Add support to re-construct cu-index"Alexander Yermolovich1-73/+2
This reverts commit a5bd76a6e3119af9dd9c1d8af89e2b89f5267deb.
2022-12-07[DWARFLibrary] Add support to re-construct cu-indexAlexander Yermolovich1-2/+73
Summary: According to DWARF5 specification and gnu specification for DWARF4 the offset entry in the CU/TU Index is 32 bits. This presents a problem when .debug_info.dwo in DWP file grows beyond 4GB. The CU Index becomes partially corrupted. This diff adds manual parsing of .debug_info.dwo/.debug_abbrev.dwo to reconstruct CU index in general, and TU index for DWARF5. This is a work around until DWARF6 spec is finalized. Next patch will change internal CU/TU struct to 64 bit, and change uses as necessary. The plan is to land all the patches in one go after all are approved. This patch originates from the discussion in: https://discourse.llvm.org/t/dwarf-dwp-4gb-limit/63902 Differential Revision: https://reviews.llvm.org/D137882
2022-12-05[DebugInfo] llvm::Optional => std::optionalFangrui Song1-27/+28
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
generated by cgit v1.1 at 2025-08-06 01:28:15 +0000