aboutsummaryrefslogtreecommitdiff
path: root/llvm/unittests/DebugInfo
AgeCommit message (Collapse)AuthorFilesLines
4 days[llvm-debuginfo-analyzer] Remove `LVScope::Children` container (#144750)Javier Lopez-Gomez1-5/+4
Remove the `LVScope::Children` container and use `llvm::concat()` instead to return a view over the types, symbols, and sub-scopes contained in a given `LVScope`. Fixes #69160.
2025-09-15[Dwarf] Support heterogeneous DW_{OP,AT}s needed for AMDGPU CFI (#153883)Scott Linder1-0/+6
These are defined in the user range until standard versions of them get adopted into dwarf, which is expected in DWARF6. Some of these amount to reservations currently as no code to use them is included. It would be very helpful to get them committed to avoid conflicts necessitating encoding changes while we are in the process of upstreaming. --------- Co-authored-by: Juan Martinez Fernandez <juamarti@amd.com> Co-authored-by: Emma Pilkington <Emma.Pilkington@amd.com>
2025-09-10[PDB] Add public symbol lookup by address (#157361)nerix2-0/+227
This adds a method on the `PublicsStream` to look up symbols using their address (segment + offset). It's largely a reimplementation of [`NearestSym`](https://github.com/microsoft/microsoft-pdb/blob/805655a28bd8198004be2ac27e6e0290121a5e89/PDB/dbi/gsi.cpp#L1492-L1581) from the reference. However, we don't return the nearest symbol, but the exact symbol. Still, in case of ICF, we return the symbol that's first in the address map. Users can then use the returned offset to read the next records to check if multiple symbols overlap, if desired. From #149701.
2025-09-09MC: Use Triple form of lookupTarget in more places (#157591)Matt Arsenault2-5/+4
2025-09-08MC: Add Triple overloads for more MC constructors (#157321)Matt Arsenault3-9/+11
Avoids more Triple->string->Triple round trip. This is a continuation of f137c3d592e96330e450a8fd63ef7e8877fc1908
2025-08-27[llvm-debuginfo-analyzer] Fixed some DWARF related bugs (#153318)Adam Yang1-15/+5
This PR fixes two bugs in LogicalView: - `DW_AT_ranges` are not being read correctly - `DW_AT_high_pc` for scopes are treated as inclusive The test changes for llvm-debug-analyzer are mostly to address the DW_AT_high_pc change. There is a new test that further verifies the fixes.
2025-07-08[NFC] Separate UnwindTable from DebugFrame into a different type (#142521)AmirHossein PashaeeHir1-0/+1
By separating the Unwind table into a different file, this functionality can be a part of the DWARF library with no dependency on MC, which makes it usable in the MC layer. This is a continuation of [PR#14520](https://github.com/llvm/llvm-project/pull/142520).
2025-06-27Reapply "[NFC][DebugInfo][DWARF] Create new low-level dwarf library (#… ↵Sterling-Augustine3-3/+5
(#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-Augustine3-5/+3
(#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-Augustine3-3/+5
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-06-23[NFC] Remove UnwindTable dependency on CIE, and FDE (#142520)AmirHossein PashaeeHir1-28/+28
This PR is in the direction of separating Unwind table from FDE, and CIE that depends on llvm/Object. To separate, first the runtime dependencies have to be removed, which this commit does that. This is similar to [1](https://github.com/llvm/llvm-project/pull/140096), [2](https://github.com/llvm/llvm-project/pull/139175), and [3](https://github.com/llvm/llvm-project/pull/139326).
2025-06-09[NFC] Separate high-level-dependent portions of DWARFExpression (revised) ↵Sterling-Augustine1-1/+1
(#143170) (Revised version of a previous, unreviewed, PR.) Move all expression verification into its only client: DWARFVerifier. Move all printing code (which was a mix of static and member functions) into a separate class. This is one in a series of refactoring PRs to separate dwarf functionality into lower-level pieces usable without object files and sections at build time. The code is already written this way via various "if (section == nullptr)" and similar conditionals. So the functionality itself is needed and exists, but only as a runtime feature. The goal of these refactors is to remove the build-time dependencies, which will allow the existing functionality to be used from lower-level parts of the compiler. Particularly from lib/MC/.... More information at: https://discourse.llvm.org/t/rfc-debuginfo-dwarf-refactor-into-to-lower-and-higher-level-libraries/86665
2025-06-06[llvm-debuginfo-analyzer] Add support for parsing DWARF / CodeView ↵Javier Lopez-Gomez2-0/+10
SourceLanguage (#137223) This pull request adds support for parsing the source language in both DWARF and CodeView. Specifically, - The `LVSourceLanguage` class is introduced to represent any supported language by any of the debug info representations. - Update `LVDWARFReader.cpp` and `LVCodeViewVisitor.cpp` to parse the source language where it applies. Added a new `=Language` attribute; `getAttributeLanguage()` is internally used to control whether this information is being printed.
2025-05-26[DebugInfo] Use llvm::find_if (NFC) (#141521)Kazu Hirata2-24/+12
2025-05-26[llvm] Use llvm::any_of (NFC) (#141444)Kazu Hirata1-7/+4
2025-05-22[llvm-debuginfo-analyzer] Add support for DWARF `DW_AT_byte_size` (#139110)Javier Lopez-Gomez3-0/+64
This PR was split from https://github.com/llvm/llvm-project/pull/137228 (which introduced support for `DW_TAG_module` and `DW_AT_byte_size`). This PR improves `LVDWARFReader` by introducing handling of `DW_AT_byte_size`. Most DWARF emitters include this attribute for types to specify the size of an entity of the given type.
2025-05-21[llvm-debuginfo-analyzer] Support DW_TAG_module (#137228)Javier Lopez-Gomez2-0/+20
- Adds support for `DW_TAG_module` DIEs and recurse over their children. Prior to this patch, entities hanging below `DW_TAG_module` were just not visible. This DIE kind is commonly generated by Objective-C modules. This patch will represent such entities, which will print as ``` [001] {CompileUnit} '/llvm/tools/clang/test/modules/<stdin>' [002] {Producer} 'LLVM version 3.7.0' {Directory} '/llvm/tools/clang/test/modules' {File} '<stdin>' [002] {Module} 'DebugModule' ``` The minimal test case included is just the result of ``` $ llc llvm/test/DebugInfo/X86/DIModule.ll -accel-tables=Dwarf -o llvm/unittests/DebugInfo/LogicalView/Inputs/test-dwarf-clang-module.o -filetype=obj ```
2025-05-21[llvm-debuginfo-analyzer] Fix a couple of unhandled DWARF situations leading ↵Javier Lopez-Gomez2-1/+38
to a crash (#137221) This pull request fixes a couple of unhandled situations in DWARF input leading to a crash. Specifically, - If the DWARF input contains a declaration of a C variadic function (where `...` translates to `DW_TAG_unspecified_parameters`), which is then followed by a definition, `llvm_unreachable()` is hit in `LVScope::addMissingElements()`. This is only visible in Debug builds. - Parsing of instructions in `LVBinaryReader::createInstructions()` does not check whether `Offset` lies within the `Bytes` ArrayRef. A specially crafted DWARF input can lead to this condition.
2025-05-20[llvm] Use llvm::is_contained (NFC) (#140742)Kazu Hirata1-2/+1
2025-05-04[llvm] Remove unused local variables (NFC) (#138467)Kazu Hirata1-1/+0
2025-04-16[llvm] Use llvm::append_range (NFC) (#135931)Kazu Hirata2-3/+3
2025-03-19[LLVM][PDB][Test] Fix the build (#131984)Aleksandr Korepanov1-1/+1
Hello! Sorry, it seems I broke the build in https://github.com/llvm/llvm-project/pull/131598 Build: https://lab.llvm.org/buildbot/#/builders/145/builds/5745 This is a compilation fix, please take a look.
2025-03-18[LLVM][PDB] Use IsUnsigned flag for APInt correctly (#131598)Aleksandr Korepanov2-0/+61
This patch fixes an assertion that occurs in `APInt`. The assertion can be reproduced with LLDB test `python_api/thread/TestThreadAPI.py` (it fails).
2025-03-17[NFC][DebugInfo] Wrap DILineInfo return type with std::optional to handle ↵Zequan Wu1-11/+9
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-12[TargetRegistry] Accept Triple in createTargetMachine() (NFC) (#130940)Nikita Popov1-1/+1
This avoids doing a Triple -> std::string -> Triple round trip in lots of places, now that the Module stores a Triple.
2025-03-06[IR] Store Triple in Module (NFC) (#129868)Nikita Popov3-3/+3
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-06[DebugInfo][DWARF] Utilize DW_AT_LLVM_stmt_sequence attr in line table ↵alx321-1/+114
lookups (#123391) **Summary** Add support for filtering line table entries based on `DW_AT_LLVM_stmt_sequence` attribute when looking up address ranges. This ensures that line entries are correctly attributed to their corresponding functions, even when multiple functions share the same address range due to optimizations. **Background** In https://github.com/llvm/llvm-project/pull/110192 we added support to clang to generate the `DW_AT_LLVM_stmt_sequence` attribute for `DW_TAG_subprogram`'s. Corresponding RFC: [New DWARF Attribute for Symbolication of Merged Functions](https://discourse.llvm.org/t/rfc-new-dwarf-attribute-for-symbolication-of-merged-functions/79434) The `DW_AT_LLVM_stmt_sequence` attribute allows accurate attribution of line number information to their corresponding functions, even in scenarios where functions are merged or share the same address space due to optimizations like Identical Code Folding (ICF) in the linker. **Implementation Details** The patch modifies `DWARFDebugLine::lookupAddressRange` to accept an optional DWARFDie parameter. When provided, the function checks if the `DIE` has a `DW_AT_LLVM_stmt_sequence` attribute. This attribute contains an offset into the line table that marks where the line entries for this DIE's function begin. If the attribute is present, the function filters the results to only include line entries from the sequence that starts at the specified offset. This ensures that even when multiple functions share the same address range, we return only the line entries that actually belong to the function represented by the DIE. The implementation: - Adds an optional DWARFDie parameter to lookupAddressRange - Extracts the `DW_AT_LLVM_stmt_sequence` offset if present - Modifies the address range lookup logic to filter sequences based on their offset - Returns only line entries from the matching sequence
2024-12-17Fix crash due to un-checked error in LVReaderHandler::handleArchive method ↵aurelien353-0/+121
(#118951) [llvm-debuginfo-analyzer] Fix crash due to un-checked error in LVReaderHandler::handleArchive method. - Added README describing how to generated the binary files used for the test. - A follow up patch to add extra ASSERT_NE Committed on behalf of @aurelien35
2024-11-29[llvm-debuginfo-analyzer] Remove superfluous link components. (#118052)Carlos Alberto Enciso1-3/+0
As 'LLVM_TARGETS_TO_BUILD' control which targets are enabled, the lines: AllTargetsDescs AllTargetsDisassemblers AllTargetsInfos are redundant.
2024-11-28[llvm-debuginfo-analyzer] Fix compile/link errors on specific builders. ↵Carlos Alberto Enciso2-36/+38
(#117971) Link errors on builders: - llvm-nvptx-nvidia-ubuntu - llvm-nvptx64-nvidia-ubuntu Add explicitly references to DebugInfoDWARF and Object. Compile errors on builders: - ppc64le-lld-multistage-test - clang-ppc64le-linux-multistage - clang-ppc64le-rhel error: comparison of integers of different signs: Add to the constants used in the 'EXPECT_EQ' the 'u' postfix.
2024-11-28[llvm-debuginfo-analyzer] Common handling of unsigned attribute values. ↵Carlos Alberto Enciso2-0/+367
(#116027) - In the DWARF reader, for those attributes that can have an unsigned value, allow for the following cases: * Is an implicit constant * Is an optional value - The testing is done by creating a file with generated DWARF, using `DwarfGenerator` (generate DWARF debug info for unit tests).
2024-11-26[GSYM] Callsites: Add data format support and loading from YAML (#109781)alx321-2/+2
This PR adds support in the gSYM format for call site information and adds support for loading call sites from a YAML file. The support for YAML input is mostly for testing purposes - so we have a way to test the functionality. Note that this data is not currently used in the gSYM tooling - the logic to use call sites will be added in a later PR. The reason why we need call site information in gSYM files is so that we can support better call stack function disambiguation in the case where multiple functions have been merged due to optimization (linker ICF). When resolving a merged function on the callstack, we can use the call site information of the calling function to narrow down the actual function that is being called, from the set of all merged functions. See [this RFC](https://discourse.llvm.org/t/rfc-extending-gsym-format-with-call-site-information-for-merged-function-disambiguation/80682) for more details on this change.
2024-11-25[DWARF] Fix DWARTTypePrinter unable to print qualified name for ↵Zequan Wu1-0/+135
DW_TAG_typedef DIE (#117239) Fix a bug introduced in https://github.com/llvm/llvm-project/pull/117071. Ideally the DWARTTypePrinter test should go to `llvm/unittests/DebugInfo/DWARF/DWARTTypePrinterTest.cpp`.
2024-10-28[AArch64][Libunwind] Add Support for FEAT_PAuthLR DWARF Instruction (#112171)Jack Styles1-0/+1
As part of FEAT_PAuthLR, a new DWARF Frame Instruction was introduced, `DW_CFA_AARCH64_negate_ra_state_with_pc`. This instructs Libunwind that the PC has been used with the signing instruction. This change includes three commits - Libunwind support for the newly introduced DWARF Instruction - CodeGen Support for the DWARF Instructions - Reversing the changes made in #96377. Due to `DW_CFA_AARCH64_negate_ra_state_with_pc`'s requirements to be placed immediately after the signing instruction, this would mean the CFI Instruction location was not consistent with the generated location when not using FEAT_PAuthLR. The commit reverses the changes and makes the location consistent across the different branch protection options. While this does have a code size effect, this is a negligible one. For the ABI information, see here: https://github.com/ARM-software/abi-aa/blob/853286c7ab66048e4b819682ce17f567b77a0291/aadwarf64/aadwarf64.rst#id23
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][unittests] Don't call raw_string_ostream::flush() (NFC)JOE19944-13/+0
raw_string_ostream::flush() is essentially a no-op (also specified in docs). Don't call it in tests that aren't meant to test 'raw_string_ostream' itself. p.s. remove a few redundant calls to raw_string_ostream::str()
2024-09-04Reapply "[llvm/DWARF] Recursively resolve DW_AT_signature references"… ↵Pavel Labath1-0/+61
(#99495) … (#99444) The previous version introduced a bug (caught by cross-project tests). Explicit signature resolution is still necessary when one wants to access the children (not attributes) of a given DIE. The new version keeps just the findRecursively extension, and reverts all the DWARFTypePrinter modifications.
2024-07-20[MC] Remove unused bool arguments from createMCObjectStreamer callersFangrui Song2-6/+2
2024-07-16Split DWARFFormValue::getReference into four functions (#98905)Pavel Labath1-49/+138
The result of the function cannot be correctly interpreted without knowing the precise form type (a type signature needs to be looked up very differently from a supplementary debug info reference). The function sort of worked because the two reference types (unit-relative and section-relative) that can be handled uniformly are also the most common types of references, but this setup made it easy to write code which does not support other kinds of reference (and if one tried to support them, the result didn't look pretty -- https://github.com/llvm/llvm-project/pull/97423/files#r1676217081). The split is based on the reference type classification from DWARFv5 (Section 7.5.5 Classes and Forms), and it should enable uniform (if slightly more verbose) hadling. Note that this only affects users which want more control of how (or if) the references are resolved. Users which just want to access the referenced DIE can use the higher level API (DWARFDie::GetAttributeValueAsReferencedDie) which returns (or will return after #97423 is merged) the correct die for all reference types (except for supplementary references, which we don't support right now).
2024-07-07[llvm] Remove redundant calls to std::unique_ptr<T>::get (NFC) (#97914)Kazu Hirata2-3/+3
2024-05-30[LLVM] Remove executable permission from some non-executable files (#93803)Jay Foad1-0/+0
2024-05-25[llvm] Revise IDE folder structure (#89741)Michael Kruse6-12/+0
Update the folder titles for targets in the monorepository that have not seen taken care of for some time. These are the folders that targets are organized in Visual Studio and XCode (`set_property(TARGET <target> PROPERTY FOLDER "<title>")`) when using the respective CMake's IDE generator. * Ensure that every target is in a folder * Use a folder hierarchy with each LLVM subproject as a top-level folder * Use consistent folder names between subprojects * When using target-creating functions from AddLLVM.cmake, automatically deduce the folder. This reduces the number of `set_property`/`set_target_property`, but are still necessary when `add_custom_target`, `add_executable`, `add_library`, etc. are used. A LLVM_SUBPROJECT_TITLE definition is used for that in each subproject's root CMakeLists.txt.
2024-03-20[DwarfGenerator] Calculate relative offset according to Dwarf Version (#84847)Will Hawkins1-3/+11
The relative offset for a CU in Dwarf v5 (and later) is different than the relative offset for a CU in Dwarf v4 (and before). Signed-off-by: Will Hawkins <hawkinsw@obs.cr>
2024-03-18[llvm-debuginfo-analyzer][NFC] Rename LVElfReader.cpp[h] (#85530)Carlos Alberto Enciso2-3/+3
As part of the WebAssembly support work review https://github.com/llvm/llvm-project/pull/82588 It was decided to rename: Files: LVElfReader.cpp[h] -> LVDWARFReader.cpp[h] ELFReaderTest.cpp -> DWARFReaderTest.cpp Class: LVELFReader -> LVDWARFReader The name LVDWARFReader would match the another reader LVCodeViewReader as they will reflect the type of debug information format that they are parsing.
2024-02-22[lldb][llvm] Return an error instead of crashing when parsing a line table ↵Greg Clayton1-1/+3
prologue. (#80769) We recently ran into some bad DWARF where the `DW_AT_stmt_list` of many compile units was randomly set to invalid values and was causing LLDB to crash due to an assertion about address sizes not matching. Instead of asserting, we should return an appropriate recoverable `llvm::Error`.
2024-02-12Gsymutil aggregation similar to DwarfDump --verify (#81154)Kevin Frei1-46/+73
GsymUtil, like DwarfDump --verify, spews a *lot* of data necessary to understand/diagnose issues with DWARF data. The trouble is that the kind of information necessary to make the messages useful also makes them nearly impossible to easily categorize. I put together a similar output categorizer (https://github.com/llvm/llvm-project/pull/79648) that will emit a summary of issues identified at the bottom of the (very verbose) output, enabling easier tracking of issues as they arise or are addressed. There's a single output change, where a message "warning: Unable to retrieve DWO .debug_info section for some object files. (Remove the --quiet flag for full output)" was being dumped the first time it was encountered (in what looks like an attempt to make something easily grep-able), but rather than keep the output in the same order, that message is now a 'category' so gets emitted at the end of the output. The test 'tools/llvm-gsymutil/X86/elf-dwo.yaml' was changed to reflect this difference. --------- Co-authored-by: Kevin Frei <freik@meta.com>
2024-02-12[DWARFYAML] Implement debug_names support (#79666)Felipe de Azevedo Piovezan1-0/+253
This commit brings support for debug_names in DWARFYAML. It parses YAML and generates emits a DWARF5 Accelerator table with the following limitations: 1. All forms must have a fixed length (zero length is also ok). 2. Hard-coded support for DWARF 5 and DWARF32. 3. The generated table does not contain a hash index All of these limitations can be lifted in the future, but for now this is good enough to enable testing.
2023-12-13[llvm] Use StringRef::{starts,ends}_with (NFC)Kazu Hirata2-4/+4
This patch replaces uses of StringRef::{starts,ends}with with StringRef::{starts,ends}_with for consistency with std::{string,string_view}::{starts,ends}_with in C++20. I'm planning to deprecate and eventually remove StringRef::{starts,ends}with.
2023-12-07[libDebugInfo] Prevent infinite recursion in DWARFDie::getTypeSize() (#74681)Adrian Prantl1-0/+36
when run on invalid input.
2023-12-03[llvm] Stop including tuple (NFC)Kazu Hirata1-1/+0
Identified with clangd.