summaryrefslogtreecommitdiff
path: root/llvm/lib/DebugInfo/DWARF/DWARFExpression.cpp
AgeCommit message (Collapse)Author
2025-06-27Reapply "[NFC][DebugInfo][DWARF] Create new low-level dwarf library (#… ↵Sterling-Augustine
(#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-Augustine
(#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-Augustine
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-09[NFC] Separate high-level-dependent portions of DWARFExpression (revised) ↵Sterling-Augustine
(#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-08[llvm] Compare std::optional<T> to values directly (NFC) (#143340)Kazu Hirata
This patch transforms: X && *X == Y to: X == Y where X is of std::optional<T>, and Y is of T or similar.
2025-06-06[llvm][DebugInfo] Add support for DW_OP_GNU_implicit_pointer (#142913)Thrrreeee
This patch introduces support for the DWARF operation `DW_OP_GNU_implicit_pointer `(value 0xf3) within LLVM's DWARF parsing and expression evaluation infrastructure. This GNU extension is used to describe the location of a variable that is itself a pointer, where the value of this pointer is stored at an address derived from another DWARF location expression plus a constant offset. Motivation: Compilers like GCC use `DW_OP_GNU_implicit_pointer `to represent the location of certain variables.Without support for this opcode, debuggers like LLDB (and other tools relying on LLVM's DWARF libraries) cannot correctly resolve the location of such variables, leading to an inability to inspect their values or an incorrect debugging experience.
2024-08-13[DebugInfo] Add expression decoding for `DW_OP_implicit_pointer` (#102923)J. Ryan Stinnett
This allows `llvm-dwarfdump` to decode the DWARF 5 opcode `DW_OP_implicit_pointer` (0xa0). GCC makes use of this opcode in recent versions. LLVM contains some (unfinished) support as well. With existing usage in the ecosystem, adding decoding support here seems reasonable.
2024-08-12[DebugInfo][NFC] Sort DWARF op descriptions, fix versions (#102773)J. Ryan Stinnett
This sorts DWARF op descriptions in `DWARFExpression.cpp` by opcode and version, packing the standardised ops together. A few ops also had the wrong version listed, so this fixes those versions as well. (The version does not appear to actually be used currently.)
2024-06-07[llvm-dwarfdump] Add a null-check in `prettyPrintBaseTypeRef`. (#93156)mgschossmann
Fixes #93104 Prevent a crash by only printing DWARFUnit-unaware information in cases in which `DWARFUnit* U` is `nullptr`.
2023-06-25[llvm] Add missing StringExtras.h includesElliot Goodrich
In preparation for removing the `#include "llvm/ADT/StringExtras.h"` from the header to source file of `llvm/Support/Error.h`, first add in all the missing includes that were previously included transitively through this header.
2023-06-19[DebugInfo] Add DW_OP_LLVM_user extension pointScott Linder
The extension codespace for DWARF expressions (DW_OP_LLVM_{lo,hi}_user) has shrunk over time, as no extension is ever "retired" in practice. To facilitate future extensions, this patch reserves one open opcode as an extension point (0xfe), which is followed by a ULEB128-encoded SubOperation, and then by the subop's operands. There is some prior-art, namely DW_OP_AARCH64_operation (see https://github.com/ARM-software/abi-aa/blob/edd7460d87493fff124b8b5713acf71ffc06ee91/aadwarf64/aadwarf64.rst#45dwarf-expression-operations). This version makes some different tradeoffs, opting to use a ULEB128 for the subop encoding for future-proofing. Reviewed By: #debug-info, dblaikie Differential Revision: https://reviews.llvm.org/D147271
2023-06-19[DebugInfo] Support more than 2 operands in DWARF operationsScott Linder
Update DWARFExpression::Operation and LVOperation to support more than 2 operands. Take the opportunity to use a SmallVector, which will handle at least 2 operands without allocation anyway, and removes the static limit completely. As there is no longer the concept of an "unused operand", remove Operation::Encoding::SizeNA. Any use of it is now replaced with explicit checks for how many operands an operation has. There are still places where the limit remains 2, namely in the DWARFLinker and in DIExpressions, but these can be updated in later patches as-needed. There are no explicit tests as this is nearly NFC: no new operation is added which makes use of the additional operand capacity yet. A future patch adding a new DWARF extension point will include operations which require the support. Reviewed By: Orlando, CarlosAlbertoEnciso Differential Revision: https://reviews.llvm.org/D147270
2023-05-16[DWARFLinker][DWARFv5] Add handling of DW_OP_addrx and DW_OP_constx ↵Alexey Lapshin
expression operands. This patch adds handling of DW_OP_addrx and DW_OP_constx expression operands. In --update case these operands are preserved as is. Otherwise they are converted into the DW_OP_addr and DW_OP_const[*]u correspondingly. Differential Revision: https://reviews.llvm.org/D147066
2023-04-19[DebugInfo] printCompactDWARFExpr: don't assert on stack sizeScott Linder
Gracefully handle non-1 stack sizes in printCompactDWARFExpr rather than assert. Add support for DW_OP_nop and test the zero-sized stack case. This is intended to be nearly NFC. Differential Revision: https://reviews.llvm.org/D147269
2022-12-15Remove the dependency between lib/DebugInfoDWARF and MC.Shubham Sandeep Rastogi
Differential Revision: https://reviews.llvm.org/D134817
2022-12-14Revert "Remove the dependency between lib/DebugInfoDWARF and MC."Shubham Sandeep Rastogi
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 Rastogi
Differential Revision: https://reviews.llvm.org/D134817
2022-12-05[DebugInfo] llvm::Optional => std::optionalFangrui Song
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-12-04[MC] llvm::Optional => std::optionalFangrui Song
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-10-27[llvm-debuginfo-analyzer] (08/09) - ELF ReaderCarlos Alberto Enciso
llvm-debuginfo-analyzer is a command line tool that processes debug info contained in a binary file and produces a debug information format agnostic “Logical View”, which is a high-level semantic representation of the debug info, independent of the low-level format. The code has been divided into the following patches: 1) Interval tree 2) Driver and documentation 3) Logical elements 4) Locations and ranges 5) Select elements 6) Warning and internal options 7) Compare elements 8) ELF Reader 9) CodeView Reader Full details: https://discourse.llvm.org/t/llvm-dev-rfc-llvm-dva-debug-information-visual-analyzer/62570 This patch: This is a high level summary of the changes in this patch. ELF Reader - Support for ELF/DWARF. LVBinaryReader, LVELFReader Reviewed By: psamolysov, probinson Differential Revision: https://reviews.llvm.org/D125783
2022-10-06Revert "Remove the dependency between lib/DebugInfoDWARF and MC."Shubham Sandeep Rastogi
This reverts commit d96ade00c3c96bd451c60e34a17e613cdd5fdc38.
2022-10-06Remove the dependency between lib/DebugInfoDWARF and MC.Shubham Sandeep Rastogi
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 Rastogi
This reverts commit 0008990479a2daf587c2a4f274384b2fb87247fb.
2022-10-06Remove the dependency between lib/DebugInfoDWARF and MC.Shubham Sandeep Rastogi
Differential Revision: https://reviews.llvm.org/D134817
2021-12-14DebugInfo: Migrate callers from getAsCString to dwarf::toStringDavid Blaikie
This makes a bunch of these call sites independent of a follow-up change I'm making to have getAsCString return Expected<const char*> for more descriptive error messages so that the failures there can be communicated up to DWARFVerifier (or other callers who want to provide more verbose diagnostics) so DWARFVerifier doesn't have to re-implement the string lookup logic and error checking.
2021-11-16DebugInfo: Make DWARFExpression::iterator a const iteratorDuncan P. N. Exon Smith
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
2021-11-16DebugInfo: Stop modifying Operation::Error inside of verify()Duncan P. N. Exon Smith
The only caller of Operation::verify() is DWARFExpression::verify(), which iterates past the (ephemeral) Operation immediately after. - Stop setting Operation::Error because the mutation will never be observed. - Change verify() to a static function to be sure all callers are updated. Differential Revision: https://reviews.llvm.org/D113957
2021-11-15DebugInfo: const-qualify accessors of DWARFExpression::OperationDuncan P. N. Exon Smith
Add `const` to DWARFExpression::Operation's accessors and make Operation::extract() private, since it's only used by the friend class DWARFExpression::iterator.
2021-06-29[DebugInfo] Bug 41152 - Improve dumping of empty location expressionsSoham Dixit
Fixes PR41152 (https://bugs.llvm.org/show_bug.cgi?id=41152). Reviewed by: jhenderson, dblaikie, SouraVX Differential Revision: https://reviews.llvm.org/D103502
2021-02-11llvm-dwarfdump: fix the counting when printing DW_OP_entry_valueAdrian Prantl
The block size is in bytes, and not number of operands. Differential Revision: https://reviews.llvm.org/D96472
2021-02-05[WebAssembly] locals can now be indirect in DWARFWouter van Oortmerssen
This for example to indicate that byval args are represented by a pointer to a struct. Followup to https://reviews.llvm.org/D94140 Differential Revision: https://reviews.llvm.org/D94347
2021-01-28Add the ability to extract the unwind rows from DWARF Call Frame Information.Greg Clayton
This patch adds the ability to evaluate the state machine for CIE and FDE unwind objects and produce a UnwindTable with all UnwindRow objects needed to unwind registers. It will also dump the UnwindTable for each CIE and FDE when dumping DWARF .debug_frame or .eh_frame sections in llvm-dwarfdump or llvm-objdump. This allows users to see what the unwind rows actually look like for a given CIE or FDE instead of just seeing a list of opcodes. This patch adds new classes: UnwindLocation, RegisterLocations, UnwindRow, and UnwindTable. UnwindLocation is a class that describes how to unwind a register or Call Frame Address (CFA). RegisterLocations is a class that tracks registers and their UnwindLocations. It gets populated when parsing the DWARF call frame instruction opcodes for a unwind row. The registers are mapped from their register numbers to the UnwindLocation in a map. UnwindRow contains the result of evaluating a row of DWARF call frame instructions for the CIE, or a row from a FDE. The CIE can produce a set of initial instructions that each FDE that points to that CIE will use as the seed for the state machine when parsing FDE opcodes. A UnwindRow for a CIE will not have a valid address, whille a UnwindRow for a FDE will have a valid address. The UnwindTable is a class that contains a sorted (by address) vector of UnwindRow objects and is the result of parsing all opcodes in a CIE, or FDE. Parsing a CIE should produce a UnwindTable with a single row. Parsing a FDE will produce a UnwindTable with one or more UnwindRow objects where all UnwindRow objects have valid addresses. The rows in the UnwindTable will be sorted from lowest Address to highest after parsing the state machine, or an error will be returned if the table isn't sorted. To parse a UnwindTable clients can use the following methods: static Expected<UnwindTable> UnwindTable::create(const CIE *Cie); static Expected<UnwindTable> UnwindTable::create(const FDE *Fde); A valid table will be returned if the DWARF call frame instruction opcodes have no encoding errors. There are a few things that can go wrong during the evaluation of the state machine and these create functions will catch and return them. Differential Revision: https://reviews.llvm.org/D89845
2020-10-23llvm-dwarfdump: Support verbose printing DW_OP_convert to print the CU local ↵David Blaikie
offset before the resolved absolute offset
2020-07-14[llvm-objdump] Add entry_value and stack_value opcodesOliver Stannard
Add the DW_OP_entry_value and DW_OP_stack_value opcodes to the DWARF expression printer. Differential revision: https://reviews.llvm.org/D74843
2020-07-14[llvm-objdump] Add simple memory expressions to variable displayOliver Stannard
Add the DW_OP_breg0..DW_OP_breg31 and DW_OP_bregx opcodes to the DWARF expression printer. Differential revision: https://reviews.llvm.org/D74841
2020-07-09[llvm-objdump] Display locations of variables alongside disassemblyOliver Stannard
This adds the --debug-vars option to llvm-objdump, which prints locations (registers/memory) of source-level variables alongside the disassembly based on DWARF info. A vertical line is printed for each live-range, with a label at the top giving the variable name and location, and the position and length of the line indicating the program counter range in which it is valid. Differential revision: https://reviews.llvm.org/D70720
2020-05-09[DebugInfo] Dump raw data in a case of decoding error of an expression.Igor Kudrin
It looks like that was an initial intention, but some code paths in `DWARFExpression::Operation::extract()` did not initialize `EndOffset` properly. Differential Revision: https://reviews.llvm.org/D79622
2020-05-08Reland D79501 "[DebugInfo] Fix handling DW_OP_call_ref in DWARF64 units."Fangrui Song
With a fix to uninitialized EndOffset. DW_OP_call_ref is the only operation that has an operand which depends on the DWARF format. The patch fixes handling that operation in DWARF64 units. Differential Revision: https://reviews.llvm.org/D79501
2020-05-08Revert "[DebugInfo] Fix handling DW_OP_call_ref in DWARF64 units."Krasimir Georgiev
This reverts commit 989ae9e848a079715c2d23e5d3622cac9b48e08e. Newly added test fails: FAIL: LLVM::DW_OP_call_ref_unexpected.s http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/28298
2020-05-08[DebugInfo] Fix handling DW_OP_call_ref in DWARF64 units.Igor Kudrin
DW_OP_call_ref is the only operation that has an operand which depends on the DWARF format. The patch fixes handling that operation in DWARF64 units. Differential Revision: https://reviews.llvm.org/D79501
2020-04-16[WebAssembly] Add int32 DW_OP_WASM_location variantWouter van Oortmerssen
This to allow us to add reloctable global indices as a symbol. Also adds R_WASM_GLOBAL_INDEX_I32 relocation type to support it. See discussion in https://github.com/WebAssembly/debugging/issues/12
2020-03-16Revert "[llvm-objdump] Display locations of variables alongside disassembly"Nico Weber
Makes tests fail on Windows, see https://reviews.llvm.org/D70720#1924542 This reverts commit 3a5ddedadb671e485ce5c638142817879ac14a8c, and follow-ups: f4cb9c919e28276222873453cf85de9e5a3c7be5 042eb0482aa758057c4f77616a4696cdb21b4fcc c0cf5f5da9a7bf1bdf43ed53287b0f634fc53045 18649f48139932377c2a2909f1fb600bf5cf6e57 f62b898c1f5dd77e68b53570dc2679877bcbe4c2
2020-03-16[llvm-objdump] Add entry_value and stack_value opcodesOliver Stannard
Add the DW_OP_entry_value and DW_OP_stack_value opcodes to the DWARF expression printer. Differential revision: https://reviews.llvm.org/D74843
2020-03-16[llvm-objdump] Add simple memory expressions to variable displayOliver Stannard
Add the DW_OP_breg0..DW_OP_breg31 and DW_OP_bregx opcodes to the DWARF expression printer. Differential revision: https://reviews.llvm.org/D74841
2020-03-16[llvm-objdump] Display locations of variables alongside disassemblyOliver Stannard
This adds the --debug-vars option to llvm-objdump, which prints locations (registers/memory) of source-level variables alongside the disassembly based on DWARF info. A vertical line is printed for each live-range, with a label at the top giving the variable name and location, and the position and length of the line indicating the program counter range in which it is valid. Currently, this only works for object files, not executables or shared libraries. Differential revision: https://reviews.llvm.org/D70720
2020-03-16[DebugInfo] Handle generic type DW_OP_convert ops in llvm-dwarfdumpDavid Stenberg
Summary: This is a preparatory change for allowing LLVM to emit DW_OP_convert operations converting to the generic type. If DW_OP_convert's operand is 0, it converts the top of stack to the generic type, as specified by DWARFv5 section 2.5.1.6: "[...] takes one operand, which is an unsigned LEB128 integer that represents the offset of a debugging information entry in the current compilation unit, or value 0 which represents the generic type." This adds support for such operations to llvm-dwarfdump. Reviewers: aprantl, markus, jdoerfert, jhenderson Reviewed By: aprantl Subscribers: hiraditya, llvm-commits Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D76141
2020-01-29Add dwarfdump support for DW_OP_regval_type.Adrian Prantl
Differential Revision: https://reviews.llvm.org/D73598
2020-01-27[DWARF] Do not pass Version to DWARFExpression. NFCI.Igor Kudrin
The Version was used only to determine the size of an operand of DW_OP_call_ref. The size was 4 for all versions apart from 2, but the DW_OP_call_ref operation was introduced only in DWARF3. Thus, the code may be simplified and using of Version may be eliminated. Differential Revision: https://reviews.llvm.org/D73264
2020-01-27[DWARF] Simplify DWARFExpression. NFC.Igor Kudrin
As DataExtractor already has a method to extract an unsigned value of a specified size, there is no need to duplicate that. Differential Revision: https://reviews.llvm.org/D73263
2019-12-20[WebAssembly] Use TargetIndex operands in DbgValue to track WebAssembly ↵Yury Delendik
operands locations Extends DWARF expression language to express locals/globals locations. (via target-index operands atm) (possible variants are: non-virtual registers or address spaces) The WebAssemblyExplicitLocals can replace virtual registers to targertindex operand type at the time when WebAssembly backend introduces {get,set,tee}_local instead of corresponding virtual registers. Reviewed By: aprantl, dschuff Tags: #debug-info, #llvm Differential Revision: https://reviews.llvm.org/D52634