aboutsummaryrefslogtreecommitdiff
path: root/llvm/tools/llvm-dwarfdump
AgeCommit message (Collapse)AuthorFilesLines
2025-07-11[llvm-dwarfdump] Remove an unnecessary cast (NFC) (#148117)Kazu Hirata1-1/+1
&DICtx is already of DWARFContext *.
2025-06-27Reapply "[NFC][DebugInfo][DWARF] Create new low-level dwarf library (#… ↵Sterling-Augustine2-1/+2
(#145959) (#146112) Reapply "[NFC][DebugInfo][DWARF] Create new low-level dwarf library (#… (#145959) This reapplies cbf781f0bdf2f680abbe784faedeefd6f84c246e, with fixes for the shared-library build and the unconventional sanitizer-runtime build. Original Description: This is the culmination of a series of changes described in [1]. Although somewhat large by line count, it is almost entirely mechanical, creating a new library in DebugInfo/DWARF/LowLevel. This new library has very minimal dependencies, allowing it to be used from more places than the normal DebugInfo/DWARF library--in particular from MC. 1. https://discourse.llvm.org/t/rfc-debuginfo-dwarf-refactor-into-to-lower-and-higher-level-libraries/86665/2
2025-06-26Revert "[NFC][DebugInfo][DWARF] Create new low-level dwarf library (#… ↵Sterling-Augustine2-2/+1
(#145959) …145081)" This reverts commit cbf781f0bdf2f680abbe784faedeefd6f84c246e. Breaks a couple of buildbots.
2025-06-26[NFC][DebugInfo][DWARF] Create new low-level dwarf library (#145081)Sterling-Augustine2-1/+2
This is the culmination of a series of changes described in [1]. Although somewhat large by line count, it is almost entirely mechanical, creating a new library in DebugInfo/DWARF/LowLevel. This new library has very minimal dependencies, allowing it to be used from more places than the normal DebugInfo/DWARF library--in particular from MC. I am happy to put it in another location, or to structure it differently if that makes sense. Some have suggested in BinaryFormat, but it is not a great fit there. But if that makes more sense to the reviewers, I can do that. Another possibility would be to use pass-through headers to allow clients who don't care to depend only on DebugInfo/DWARF. This would be a much less invasive change, and perhaps easier for clients. But also a system that hides details. Either way, I'm open. 1. https://discourse.llvm.org/t/rfc-debuginfo-dwarf-refactor-into-to-lower-and-higher-level-libraries/86665/2
2025-04-03[llvm-dwarfdump] Make --verify for .debug_names multithreaded. (#127281)Alexander Yermolovich1-1/+17
This PR makes verification of .debug_names acceleration table multithreaded. In local testing it improves verification of clang .debug_names from four minutes to under a minute. This PR relies on a current mechanism of extracting DIEs into a vector. Future improvements can include creating API to extract one DIE at a time, or grouping Entires into buckets by CUs and extracting before parallel step. Single Thread 4:12.37 real, 246.88 user, 3.54 sys, 0 amem,10232004 mmem Multi Thread 0:49.40 real, 612.84 user, 515.73 sys, 0 amem, 11226292 mmem
2025-03-17[NFC][DebugInfo] Wrap DILineInfo return type with std::optional to handle ↵Zequan Wu1-2/+6
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-03-06[llvm-dwarfdump] Avoid repeated hash lookups (NFC) (#129991)Kazu Hirata1-4/+6
2025-03-06[IR] Store Triple in Module (NFC) (#129868)Nikita Popov1-2/+1
The module currently stores the target triple as a string. This means that any code that wants to actually use the triple first has to instantiate a Triple, which is somewhat expensive. The change in #121652 caused a moderate compile-time regression due to this. While it would be easy enough to work around, I think that architecturally, it makes more sense to store the parsed Triple in the module, so that it can always be directly queried. For this change, I've opted not to add any magic conversions between std::string and Triple for backwards-compatibilty purses, and instead write out needed Triple()s or str()s explicitly. This is because I think a decent number of them should be changed to work on Triple as well, to avoid unnecessary conversions back and forth. The only interesting part in this patch is that the default triple is Triple("") instead of Triple() to preserve existing behavior. The former defaults to using the ELF object format instead of unknown object format. We should fix that as well.
2025-02-19[llvm-dwarfdump] Print number of out-of-line functions described by DWARF ↵Javier Lopez-Gomez1-0/+3
(#127233) Some of the functions in `#functions` may have several inlined instances, but also an out-of-line definition. Therefore, for complex enough DWARF input, `#functions` - `#inlined functions` would not give us the number of out-of-line function definitions. `llvm-dwarfdump`, however, already keeps track of those; print it as part of the statistics, as this number is useful in certain scenarios.
2024-09-13[MC] Use std::optional<MCRegisters> for values returned by ↵Craig Topper1-1/+1
MCRegisterInfo::getLLVMRegNum. NFC I missed a few places when I changed the function return type in f2b71491d11355c0df0c92ef7cce7d610c894660.
2024-09-13[llvm][tools] Strip unneeded uses of raw_string_ostream::str() (NFC)JOE19941-2/+2
Remove excess layer of indirection.
2024-09-12[llvm-dwarfdump] Rename manaully-generate-unit-index. (#108399)rjmansfield1-1/+1
-manaully-generate-unit-index was misspelled.
2024-06-14[llvm] Use llvm::unique (NFC) (#95628)Kazu Hirata1-2/+2
2024-06-13[DwarfDump] Add new set of line-table-related statistics to llvm-dwarfdump ↵Stephen Tozer1-0/+80
(#93289) This patch adds a new set of statistics to llvm-dwarfdump that provide additional information about .debug_line regarding the number of bytes covered by the line table (and how many of those are covered by line 0 entries), and the number of entries within the table and how many of those are is_stmt, unique, or unique and non-line-0 (where "uniqueness" is based on file, line, and column only). Collectively these give a little more insight into the state of debug line information, rather than variables (as most of the dwarfdump statistics are currently oriented towards). I've added all of the stats that were useful to some degree, but I think the most generally useful stat is "unique line entries", since it gives the most straightforward indication of regressions, i.e. when the number goes down it means that fewer source lines are reachable in the program.
2024-05-08[llvm] Use StringRef::operator== instead of StringRef::equals (NFC) (#91441)Kazu Hirata1-1/+1
I'm planning to remove StringRef::equals in favor of StringRef::operator==. - StringRef::operator==/!= outnumber StringRef::equals by a factor of 70 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-02-28llvm-dwarfdump --verify aggregated output to JSON file (#81762)Kevin Frei1-2/+12
In order to make tooling around dwarf health easier, I've added an `--verify-json` option to `llvm-dwarfdump --verify` that will spit out error summary data with counts to a JSON file. I've added the same capability to `llvm-gsymutil` in a [different PR.](https://github.com/llvm/llvm-project/pull/81763) The format of the json is: ``` json { "error-categories": { "<first category description>": {"count": 1234}, "<next category description>": {"count":4321} }, "error-count": 5555 } ``` for a clean run: ``` json { "error-categories": {}, "error-count": 0 } ``` --------- Co-authored-by: Kevin Frei <freik@meta.com>
2024-02-13[DWARFDump] Make --verify handle all sections by default (#81559)Felipe de Azevedo Piovezan1-1/+1
The current behavior of --verify is that it only verifies debug_info, debug_abbrev and debug_names. This seems fairly arbitrary and might have been unintentional, as originally the absence of any section flags implied "all". This patch changes the behavior so that the verifier now verifies everything by default. It revealed two tests that had potentially invalid DWARF: 1. dwarfdump-str-offsets.s is adding padding between two debug_str_offset contributions. The standard does not explicitly allow this behavior. See issue https://github.com/llvm/llvm-project/issues/81558 2. dwarf5-macro.test uses a checked-in binary that has invalid debug_str_offsets. One of its entries points to the _middle_ of the string section: error: .debug_str_offsets: contribution 0x0: index 0x4: invalid string offset *0x18 == 0x455D, is neither zero nor immediately following a null character If we look at the closest offset to 0x455D in debug_str: ``` 0x0000454e: "__SLONG32_TYPE int" ``` 0x455D points to "int".
2024-02-09[DWARFDump][nfc] Fix incorrect comment (#81276)Felipe de Azevedo Piovezan1-2/+3
It claimed to dump all sections by default, but this hasn't been true since 2017: https://reviews.llvm.org/D37717
2024-02-01Aggregate errors from llvm-dwarfdump --verify (#79648)Kevin Frei1-1/+25
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-12Allow the dumping of .dwo files contents to show up when dumping an ↵Greg Clayton1-4/+24
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-12-28[llvm-dwarfdump-fuzzer] fix out of bounds potential (#76408)DavidKorczynski1-2/+2
The fuzzer relies on MemoryBuffer to hold fuzz data, and MemoryBuffer guarantees that "In addition to basic access to the characters in the file, this interface guarantees you can read one character past the end of the file, and that this character will read as '\0'." [Ref](https://llvm.org/doxygen/classllvm_1_1MemoryBuffer.html#details). The current fuzzing set up does not support this, which causes potential false positives. This PR fixes it. Fixes: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=65114 Signed-off-by: David Korczynski <david@adalogics.com>
2023-10-24[ADT] Rename llvm::erase_value to llvm::erase (NFC) (#70156)Kazu Hirata1-3/+3
C++20 comes with std::erase to erase a value from std::vector. This patch renames llvm::erase_value to llvm::erase for consistency with C++20. We could make llvm::erase more similar to std::erase by having it return the number of elements removed, but I'm not doing that for now because nobody seems to care about that in our code base. Since there are only 50 occurrences of erase_value in our code base, this patch replaces all of them with llvm::erase and deprecates llvm::erase_value.
2023-09-27llvm/tools: Fix some performance-for-range-copy issues. NFCFangrui Song1-9/+9
Inspired by https://reviews.llvm.org/D139487 , but I apply manual fixes when clang-tidy does not provide the best fix.
2023-07-19AppleAcceleratorTable: Use MapVector to stabilize iteration order after D153066Fangrui Song1-1/+2
Use a MapVector to stabilize the order and simplify future changes like D142862 that change the StringMap hash function.
2023-06-21[AppleTables] Implement iterator over all entries in tableFelipe de Azevedo Piovezan1-1/+44
This commit adds functionality to the Apple Accelerator table allowing iteration over all elements in the table. Our iterators look like streaming iterators: when we increment the iterator we check if there is still enough data in the "stream" (in our case, the blob of data of the accelerator table) and extract the next entry. If any failures occur, we immediately set the iterator to be the end iterator. Since the ultimate user of this functionality is LLDB, there are roughly two iteration methods we want support: one that also loads the name of each entry, and one which does not. Loading names is measurably slower (one order the magnitude) than only loading DIEs, so we used some template metaprograming to implement both iteration methods. Depends on D153066 Differential Revision: https://reviews.llvm.org/D153066
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.
2023-01-12[DWARFLibrary] Add support to re-construct cu-indexAlexander Yermolovich1-0/+8
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-8/+0
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-0/+8
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-20[Support] Move TargetParsers to new componentArchibald Elliott1-0/+1
This is a fairly large changeset, but it can be broken into a few pieces: - `llvm/Support/*TargetParser*` are all moved from the LLVM Support component into a new LLVM Component called "TargetParser". This potentially enables using tablegen to maintain this information, as is shown in https://reviews.llvm.org/D137517. This cannot currently be done, as llvm-tblgen relies on LLVM's Support component. - This also moves two files from Support which use and depend on information in the TargetParser: - `llvm/Support/Host.{h,cpp}` which contains functions for inspecting the current Host machine for info about it, primarily to support getting the host triple, but also for `-mcpu=native` support in e.g. Clang. This is fairly tightly intertwined with the information in `X86TargetParser.h`, so keeping them in the same component makes sense. - `llvm/ADT/Triple.h` and `llvm/Support/Triple.cpp`, which contains the target triple parser and representation. This is very intertwined with the Arm target parser, because the arm architecture version appears in canonical triples on arm platforms. - I moved the relevant unittests to their own directory. And so, we end up with a single component that has all the information about the following, which to me seems like a unified component: - Triples that LLVM Knows about - Architecture names and CPUs that LLVM knows about - CPU detection logic for LLVM Given this, I have also moved `RISCVISAInfo.h` into this component, as it seems to me to be part of that same set of functionality. If you get link errors in your components after this patch, you likely need to add TargetParser into LLVM_LINK_COMPONENTS in CMake. Differential Revision: https://reviews.llvm.org/D137838
2022-12-15Remove the dependency between lib/DebugInfoDWARF and MC.Shubham Sandeep Rastogi1-15/+55
Differential Revision: https://reviews.llvm.org/D134817
2022-12-14Revert "Remove the dependency between lib/DebugInfoDWARF and MC."Shubham Sandeep Rastogi1-55/+15
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-15/+55
Differential Revision: https://reviews.llvm.org/D134817
2022-12-07Revert "[DWARFLibrary] Add support to re-construct cu-index"Alexander Yermolovich1-8/+0
This reverts commit a5bd76a6e3119af9dd9c1d8af89e2b89f5267deb.
2022-12-07[DWARFLibrary] Add support to re-construct cu-indexAlexander Yermolovich1-0/+8
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-7/+6
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-12-02[tools] Use std::nullopt instead of None (NFC)Kazu Hirata1-1/+2
This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the amount of manual work required in migrating from Optional to std::optional. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-10-06Revert "Remove the dependency between lib/DebugInfoDWARF and MC."Shubham Sandeep Rastogi1-55/+15
This reverts commit d96ade00c3c96bd451c60e34a17e613cdd5fdc38.
2022-10-06Remove the dependency between lib/DebugInfoDWARF and MC.Shubham Sandeep Rastogi1-15/+55
This patch had to be reverted because on gcc 7.5.0 we see an error converting from std::unique_ptr<MCRegisterInfo> to Expected<std::unique_ptr<MCRegisterInfo>> as the return type for the function createRegInfo. This has now been fixed.
2022-10-06Revert "Remove the dependency between lib/DebugInfoDWARF and MC."Shubham Sandeep Rastogi1-54/+15
This reverts commit 0008990479a2daf587c2a4f274384b2fb87247fb.
2022-10-06Remove the dependency between lib/DebugInfoDWARF and MC.Shubham Sandeep Rastogi1-15/+54
Differential Revision: https://reviews.llvm.org/D134817
2022-07-23Use the range-based overload of llvm::sort where possibleDmitri Gribenko1-1/+1
Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D130403
2022-06-30[llvm-dwarfdump] --show-sources option to show all sourcesDaniel Thornburgh1-0/+89
This option allows printing all sources used by an object file. Reviewed By: dblaikie, jhenderson Differential Revision: https://reviews.llvm.org/D87656
2022-06-05Remove unneeded cl::ZeroOrMore for cl::opt/cl::list optionsFangrui Song1-1/+1
2022-03-09[llvm-dwarfdump] Avoid possible div-by-zero in debug outputDmitry Vassiliev1-6/+11
2022-02-15Cleanup LLVMDWARFDebugInfoserge-sans-paille2-0/+3
As usual with that header cleanup series, some implicit dependencies now need to be explicit: llvm/DebugInfo/DWARF/DWARFContext.h no longer includes: - "llvm/DebugInfo/DWARF/DWARFAcceleratorTable.h" - "llvm/DebugInfo/DWARF/DWARFCompileUnit.h" - "llvm/DebugInfo/DWARF/DWARFDebugAbbrev.h" - "llvm/DebugInfo/DWARF/DWARFDebugAranges.h" - "llvm/DebugInfo/DWARF/DWARFDebugFrame.h" - "llvm/DebugInfo/DWARF/DWARFDebugLoc.h" - "llvm/DebugInfo/DWARF/DWARFDebugMacro.h" - "llvm/DebugInfo/DWARF/DWARFGdbIndex.h" - "llvm/DebugInfo/DWARF/DWARFSection.h" - "llvm/DebugInfo/DWARF/DWARFTypeUnit.h" - "llvm/DebugInfo/DWARF/DWARFUnitIndex.h" Plus llvm/Support/Errc.h not included by a bunch of llvm/DebugInfo/DWARF/DWARF*.h files Preprocessed lines to build llvm on my setup: after: 1065629059 before: 1066621848 Which is a great diff! Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup Differential Revision: https://reviews.llvm.org/D119723
2021-12-15[dwarf][NFC] Move expandBundle() to MachO.hEllis Hoag1-38/+15
The function `expandBundle()` is defined both in `llvm-dwarfdump.cpp` and `llvm-gsymutil.cpp` in the exact same way. Reduce code duplication by moving this function to the `MachOObjectFile` class. Reviewed By: jhenderson, clayborg Differential Revision: https://reviews.llvm.org/D115418
2021-12-13DWARFVerifier: Verbosely dump DIEs in verifier reportsDavid Blaikie1-1/+3
Seems helpful when you're dealing with invalid/problematic DWARF. Some diagnostic messages are probably redundant with the verbose dumping and could be simplified with this.
2021-11-24[llvm-dwarfdump][Statistics] Handle LTO cases with cross CU referencingDjordje Todorovic1-26/+113
With link-time optimizations enabled, resulting DWARF mayend up containing cross CU references (through the DW_AT_abstract_origin attribute). Consider the following example: // sum.c __attribute__((always_inline)) int sum(int a, int b) { return a + b; } // main.c extern int sum(int, int); int main() { int a = 5, b = 10, c = sum(a, b); return 0; } Compiled as follows: $ clang -g -flto -fuse-ld=lld main.c sum.c -o main Results in the following DWARF: -- sum.c CU: abstract instance tree ... 0x000000b0: DW_TAG_subprogram DW_AT_name ("sum") DW_AT_decl_file ("sum.c") DW_AT_decl_line (1) DW_AT_prototyped (true) DW_AT_type (0x000000d3 "int") DW_AT_external (true) DW_AT_inline (DW_INL_inlined) 0x000000bc: DW_TAG_formal_parameter DW_AT_name ("a") DW_AT_decl_file ("sum.c") DW_AT_decl_line (1) DW_AT_type (0x000000d3 "int") 0x000000c7: DW_TAG_formal_parameter DW_AT_name ("b") DW_AT_decl_file ("sum.c") DW_AT_decl_line (1) DW_AT_type (0x000000d3 "int") ... -- main.c CU: concrete inlined instance tree ... 0x0000006d: DW_TAG_inlined_subroutine DW_AT_abstract_origin (0x00000000000000b0 "sum") DW_AT_low_pc (0x00000000002016ef) DW_AT_high_pc (0x00000000002016f1) DW_AT_call_file ("main.c") DW_AT_call_line (5) DW_AT_call_column (0x19) 0x00000081: DW_TAG_formal_parameter DW_AT_location (DW_OP_reg0 RAX) DW_AT_abstract_origin (0x00000000000000bc "a") 0x00000088: DW_TAG_formal_parameter DW_AT_location (DW_OP_reg2 RCX) DW_AT_abstract_origin (0x00000000000000c7 "b") ... Note that each entry within the concrete inlined instance tree in the main.c CU has a DW_AT_abstract_origin attribute which refers to a corresponding entry within the abstract instance tree in the sum.c CU. llvm-dwarfdump --statistics did not properly report DW_TAG_formal_parameters/DW_TAG_variables from concrete inlined instance trees which had 0% location coverage and which referred to a different CU, mainly because information about abstract instance trees and their parameters/variables was stored locally - just for the currently processed CU, rather than globally - for all CUs. In particular, if the concrete inlined instance tree from the example above was to look like this (i.e. parameter b has 0% location coverage, hence why it's missing): 0x0000006d: DW_TAG_inlined_subroutine DW_AT_abstract_origin (0x00000000000000b0 "sum") DW_AT_low_pc (0x00000000002016ef) DW_AT_high_pc (0x00000000002016f1) DW_AT_call_file ("main.c") DW_AT_call_line (5) DW_AT_call_column (0x19) 0x00000081: DW_TAG_formal_parameter DW_AT_location (DW_OP_reg0 RAX) DW_AT_abstract_origin (0x00000000000000bc "a") llvm-dwarfdump --statistics would have not reported b as such. Patch by Dimitrije Milosevic. Differential revision: https://reviews.llvm.org/D113465
2021-11-16DebugInfo: Make DWARFExpression::iterator a const iteratorDuncan P. N. Exon Smith1-1/+1
3d1d8c767be5537eb5510ee0522e2f3475fe7c04 made DWARFExpression::iterator's Operation member `mutable`. After a few prep commits, the iterator can instead be made a `const` iterator since no caller can change the Operation. Differential Revision: https://reviews.llvm.org/D113958