summaryrefslogtreecommitdiff
path: root/lldb/source/Expression/DWARFExpression.cpp
AgeCommit message (Collapse)Author
2025-09-17Reland "Revert "[lldb] Fix OP_deref evaluation for large integer resu… ↵Felipe de Azevedo Piovezan
(#159482) …lts (#159460)"" The original had an issue on "AArch-less" bots. Fixed it with some ifdefs around the presence of the AArch ABI plugin. This reverts commit 1a4685df13282ae5c1d7dce055a71a7130bfab3c.
2025-09-17Revert "[lldb] Fix OP_deref evaluation for large integer results (#159460)"Felipe de Azevedo Piovezan
This reverts commit 1d2007ba6f7bacda8848e35298a1833e79f4abd5.
2025-09-17[lldb] Fix OP_deref evaluation for large integer results (#159460)Felipe de Azevedo Piovezan
When evaluating any DWARF expression that ended in OP_deref and whose previous value on the dwarf stack -- the pointer address for the deref -- was a load address, we were treating the result itself as a pointer, calling Process:FixCodeAddress(result). This is wrong: there's no guarantee that the result is a pointer itself.
2025-09-12[lldb] Track CFA pointer metadata in StackID (#157498)Felipe de Azevedo Piovezan
[lldb] Track CFA pointer metadata in StackID In this commit: 9c8e71644227 [lldb] Make StackID call Fix{Code,Data} pointers (#152796) We made StackID keep track of the CFA without any pointer metadata in it. This is necessary when comparing two StackIDs to determine which one is "younger". However, the CFA inside StackIDs is also used in other contexts through the method StackID::GetCallFrameAddress. One notable case is DWARFExpression: the computation of `DW_OP_call_frame_address` is done using StackID. This feeds into many other places, e.g. expression evaluation may require the address of a variable that is computed from the CFA; to access the variable without faulting, we may need to preserve the pointer metadata. As such, StackID must be able to provide both versions of the CFA. In the spirit of allowing consumers of pointers to decide what to do with pointer metadata, this patch changes StackID to store both versions of the cfa pointer. Two getter methods are provided, and all call sites except DWARFExpression preserve their existing behavior (stripped pointer). Other alternatives were considered: * Just store the raw pointer. This would require changing the comparisong operator `<` to also receive a Process, as the comparison requires stripped pointers. It wasn't clear if all call-sites had a non-null process, whereas we know we have a process when creating a StackID. * Store a weak pointer to the process inside the class, and then strip metadata as needed. This would require a `weak_ptr::lock` in many operations of LLDB, and it felt wasteful. It also prevents stripping of the pointer if the process has gone away. This patch also changes RegisterContextUnwind::ReadFrameAddress, which is the method computing the CFA fed into StackID, to also preserve the signature pointers.
2025-09-04[lldb] Correct style of error messages (#156774)Jonas Devlieghere
The LLVM Style Guide says the following about error and warning messages [1]: > [T]o match error message styles commonly produced by other tools, > start the first sentence with a lowercase letter, and finish the last > sentence without a period, if it would end in one otherwise. I often provide this feedback during code review, but we still have a bunch of places where we have inconsistent error message, which bothers me as a user. This PR identifies a handful of those places and updates the messages to be consistent. [1] https://llvm.org/docs/CodingStandards.html#error-and-warning-messages
2025-08-28Stateful variable-location annotations in Disassembler::PrintInstructions() ↵Abdullah Mohammad Amin
(follow-up to #147460) (#152887) **Context** Follow-up to [#147460](https://github.com/llvm/llvm-project/pull/147460), which added the ability to surface register-resident variable locations. This PR moves the annotation logic out of `Instruction::Dump()` and into `Disassembler::PrintInstructions()`, and adds lightweight state tracking so we only print changes at range starts and when variables go out of scope. --- ## What this does While iterating the instructions for a function, we maintain a “live variable map” keyed by `lldb::user_id_t` (the `Variable`’s ID) to remember each variable’s last emitted location string. For each instruction: - **New (or newly visible) variable** → print `name = <location>` once at the start of its DWARF location range, cache it. - **Location changed** (e.g., DWARF range switched to a different register/const) → print the updated mapping. - **Out of scope** (was tracked previously but not found for the current PC) → print `name = <undef>` and drop it. This produces **concise, stateful annotations** that highlight variable lifetime transitions without spamming every line. --- ## Why in `PrintInstructions()`? - Keeps `Instruction` stateless and avoids changing the `Instruction::Dump()` virtual API. - Makes it straightforward to diff state across instructions (`prev → current`) inside the single driver loop. --- ## How it works (high-level) 1. For the current PC, get in-scope variables via `StackFrame::GetInScopeVariableList(/*get_parent=*/true)`. 2. For each `Variable`, query `DWARFExpressionList::GetExpressionEntryAtAddress(func_load_addr, current_pc)` (added in #144238). 3. If the entry exists, call `DumpLocation(..., eDescriptionLevelBrief, abi)` to get a short, ABI-aware location string (e.g., `DW_OP_reg3 RBX → RBX`). 4. Compare against the last emitted location in the live map: - If not present → emit `name = <location>` and record it. - If different → emit updated mapping and record it. 5. After processing current in-scope variables, compute the set difference vs. the previous map and emit `name = <undef>` for any that disappeared. Internally: - We respect file↔load address translation already provided by `DWARFExpressionList`. - We reuse the ABI to map LLVM register numbers to arch register names. --- ## Example output (x86_64, simplified) ``` -> 0x55c6f5f6a140 <+0>: cmpl $0x2, %edi ; argc = RDI, argv = RSI 0x55c6f5f6a143 <+3>: jl 0x55c6f5f6a176 ; <+54> at d_original_example.c:6:3 0x55c6f5f6a145 <+5>: pushq %r15 0x55c6f5f6a147 <+7>: pushq %r14 0x55c6f5f6a149 <+9>: pushq %rbx 0x55c6f5f6a14a <+10>: movq %rsi, %rbx 0x55c6f5f6a14d <+13>: movl %edi, %r14d 0x55c6f5f6a150 <+16>: movl $0x1, %r15d ; argc = R14 0x55c6f5f6a156 <+22>: nopw %cs:(%rax,%rax) ; i = R15, argv = RBX 0x55c6f5f6a160 <+32>: movq (%rbx,%r15,8), %rdi 0x55c6f5f6a164 <+36>: callq 0x55c6f5f6a030 ; symbol stub for: puts 0x55c6f5f6a169 <+41>: incq %r15 0x55c6f5f6a16c <+44>: cmpq %r15, %r14 0x55c6f5f6a16f <+47>: jne 0x55c6f5f6a160 ; <+32> at d_original_example.c:5:10 0x55c6f5f6a171 <+49>: popq %rbx ; i = <undef> 0x55c6f5f6a172 <+50>: popq %r14 ; argv = RSI 0x55c6f5f6a174 <+52>: popq %r15 ; argc = RDI 0x55c6f5f6a176 <+54>: xorl %eax, %eax 0x55c6f5f6a178 <+56>: retq ``` Only transitions are shown: the start of a location, changes, and end-of-lifetime. --- ## Scope & limitations (by design) - Handles **simple locations** first (registers, const-in-register cases surfaced by `DumpLocation`). - **Memory/composite locations** are out of scope for this PR. - Annotations appear **only at range boundaries** (start/change/end) to minimize noise. - Output is **target-independent**; register names come from the target ABI. ## Implementation notes - All annotation printing now happens in `Disassembler::PrintInstructions()`. - Uses `std::unordered_map<lldb::user_id_t, std::string>` as the live map. - No persistent state across calls; the map is rebuilt while walking instruction by instruction. - **No changes** to the `Instruction` interface. --- ## Requested feedback - Placement and wording of the `<undef>` marker. - Whether we should optionally gate this behind a setting (currently always on when disassembling with an `ExecutionContext`). - Preference for immediate inclusion of tests vs. follow-up patch. --- Thanks for reviewing! Happy to adjust behavior/format based on feedback. --------- Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com> Co-authored-by: Adrian Prantl <adrian.prantl@gmail.com>
2025-08-04[lldb] Zero extend APInt when piece size is bigger than the bitwidth (#150149)satyanarayana reddy janga
### Summary We have internally seen cases like this `DW_OP_lit0, DW_OP_stack_value, DW_OP_piece 0x28` where we have longer op pieces than what Scalar supports (32, 64 or 128 bits). In these cases LLDB is currently hitting the assertion `assert(ap_int.getBitWidth() >= bit_size);` We are extending the generated APInt to the piece size by filling zeros. ### Test plan Added a unit to cover this case. ### Reviewers @clayborg , @jeffreytan81 , @Jlalond
2025-07-30[lldb] Support DW_OP_WASM_location in DWARFExpression (#151010)Jonas Devlieghere
Add support for DW_OP_WASM_location in DWARFExpression. This PR rebases #78977 and cleans up the unit test. The DWARF extensions are documented at https://yurydelendik.github.io/webassembly-dwarf/ and supported by LLVM-based toolchains such as Clang, Swift, Emscripten, and Rust.
2025-07-22[lldb] Eliminate namespace lldb_private::dwarf (NFC) (#150073)Jonas Devlieghere
Eliminate the `lldb_private::dwarf` namespace, in favor of using `llvm::dwarf` directly. The latter is shorter, and this avoids ambiguity in the ABI plugins that define a `dwarf` namespace inside an anonymous namespace.
2025-07-03[lldb] Extract DW_OP_deref evaluation code (NFC) (#146801)Jonas Devlieghere
The DWARF expression evaluator is essentially a large state machine implemented as a switch statement. For anything but trivial operations, having the evaluation logic implemented inline is difficult to follow, especially when there are nested switches. This commit moves evaluation of `DW_OP_deref` out-of-line, similar to `Evaluate_DW_OP_entry_value`.
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-06Fix forward for new DWARF DW_OP enum to address warning in lldbDavid Blaikie
2025-03-24[LLDB][NFC] Added the interface DWARFExpression::Delegate to break ↵Dmitry Vasilyev
dependencies and reduce lldb-server size (#131645) This patch addresses the issue #129543. After this patch DWARFExpression does not call DWARFUnit directly and does not depend on lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp and a lot of clang code. After this patch the size of lldb-server binary (Linux Aarch64) is reduced from 47MB to 17MB.
2025-01-23[lldb] Add missing operations to GetOpcodeDataSize (#120163)Jonas Devlieghere
The improved error reporting in #120162 revealed that we were missing opcodes in GetOpcodeDataSize. I changed the function to remove the default case and switch over the enum type which will cause the compiler to emit a warning if there are unhandled operations in the future. rdar://139705570
2024-12-17[lldb] Improve error reporting in GetLocation_DW_OP_addr (#120162)Jonas Devlieghere
Instead of simply raising an error flag, use an llvm::Expected to propagate a meaningful error to the caller, who can report it. rdar://139705570
2024-11-21Reapply "[lldb] Convert file address to load address when reading memory for ↵Ilia Kuklin
DW_OP_piece" (#117168) This commit fixes the test so that the breakpoint is triggered correctly after `array` usage on AArch64. Reapplies #116411 with a fix.
2024-11-19Revert "[lldb] Convert file address to load address when reading memory for ↵Ilia Kuklin
DW_OP_piece" (#116824) Reverts llvm/llvm-project#116411
2024-11-19[lldb] Convert file address to load address when reading memory for ↵Ilia Kuklin
DW_OP_piece (#116411) When parsing an optimized value and reading a piece from a file address, LLDB tries to read the data from memory using that address. This patch converts file address to load address before reading the memory. Fixes #111313 Fixes #97484
2024-10-17[APInt] Fix APInt constructions where value does not fit bitwidth (NFCI) ↵Nikita Popov
(#80309) This fixes all the places that hit the new assertion added in https://github.com/llvm/llvm-project/pull/106524 in tests. That is, cases where the value passed to the APInt constructor is not an N-bit signed/unsigned integer, where N is the bit width and signedness is determined by the isSigned flag. The fixes either set the correct value for isSigned, set the implicitTrunc flag, or perform more calculations inside APInt. Note that the assertion is currently still disabled by default, so this patch is mostly NFC.
2024-10-10[lldb] Return an llvm::Error from GetFrameBaseValue (#111882)Jonas Devlieghere
This fixes the following assertion: "Cannot create Expected<T> from Error success value." The problem was that GetFrameBaseValue return false without updating the Status argument. This patch eliminates the opportunity for mistakes by returning an llvm:Error.
2024-08-20[lldb][AIX] 1. Avoid namespace collision on other platforms (#104679)Dhruv Srivastava
This PR is in reference to porting LLDB on AIX. Link to discussions on llvm discourse and github: 1. https://discourse.llvm.org/t/port-lldb-to-ibm-aix/80640 2. #101657 The complete changes for porting are present in this draft PR: https://github.com/llvm/llvm-project/pull/102601 The changes on this PR are intended to avoid namespace collision for certain typedefs between lldb and other platforms: 1. tid_t --> lldb::tid_t 2. offset_t --> lldb::offset_t
2024-06-07[lldb] Encode operands and arity in Dwarf.def and use them in LLDB. (#94679)Jonas Devlieghere
This PR extends Dwarf.def to include the number of operands and the arity (the number of entries on the DWARF stack). - The arity is used in LLDB's DWARF expression evaluator. - The number of operands is unused, but is present in the table to avoid confusing the arity with the operands. Keeping the latter up to date should be straightforward as it maps directly to a table present in the DWARF standard.
2024-06-06[lldb] Refactor ResolveLoadAddress to return an llvm::Expected (NFC) (#94558)Jonas Devlieghere
2024-06-06[lldb] Refactor ReadRegisterValueAsScalar to return an llvm::Error (NFC) ↵Jonas Devlieghere
(#94556)
2024-06-05[lldb] Fix inconsistencies in DWARFExpression errors (#94554)Jonas Devlieghere
This patch make all errors start with a lowercase letter and removes trailing periods and newlines. This fixes inconsistencies between error messages and facilitate concatenating them.
2024-06-05[lldb] Return an llvm::Expected from DWARFExpression::Evaluate (NFCI) (#94420)Jonas Devlieghere
Change the signature of `DWARFExpression::Evaluate` and `DWARFExpressionList::Evaluate` to return an `llvm::Expected` instead of a boolean. This eliminates the `Status` output parameter and generally improves error handling.
2024-06-04[lldb] Support reading DW_OP_piece from file address (#94026)Jonas Devlieghere
We received a bug report where someone was trying to print a global variable without a process. This would succeed in a debug build but fail in a on optimized build. We traced the issue back to the location being described by a DW_OP_addr + DW_OP_piece. The issue is that the DWARF expression evaluator only support reading pieces from a load address. There's no reason it cannot do the same for a file address, and indeed, that solves the problem. I unsuccessfully tried to craft a test case to illustrate the original example, using a global struct and trying to trick the compiler into breaking it apart with SROA. Instead I wrote a unit test that uses a mock target to read memory from. rdar://127435923
2024-02-13Don't count all the frames just to skip the current inlined ones. (#80918)jimingham
The algorithm to find the DW_OP_entry_value requires you to find the nearest non-inlined frame. It did that by counting the number of stack frames so that it could use that as a loop stopper. That is unnecessary and inefficient. Unnecessary because GetFrameAtIndex will return a null frame when you step past the oldest frame, so you already have the "got to the end" signal without counting all the stack frames. And counting all the stack frames can be expensive.
2023-10-13[LLDB][NFC] Create a namespace for the DWARF plugin (#68150)Walter Erquinigo
As a followup of https://github.com/llvm/llvm-project/pull/67851, I'm defining a new namespace `lldb_plugin::dwarf` for the classes in this Plugins/SymbolFile/DWARF folder. This change is very NFC and helped me with exporting the necessary symbols for my out-of-tree language plugin. The only class that I didn't change is ClangDWARFASTParser, because that shouldn't be in the same namespace as the generic language-agnostic dwarf parser. It would be a good idea if other plugins follow the same namespace scheme.
2023-07-21[lldb] Consider OP_addrx in DWARFExpression::Update_DW_OP_addrFelipe de Azevedo Piovezan
This rewrites DW_OP_addrx inside DWARFExpression as an DW_OP_addr so that we can update addresses that are originally located in the debug_addr section. The full discussion behind this can be found in https://discourse.llvm.org/t/dwarfexpression-and-dw-op-addrx/71627/12, but a summary follows. When SymbolFileDWARF::ParseVariableDIE creates DWARFExpressions for variables whose location is an OP_addr, it knows how to remap addresses appropriately in the DebugMap case. It then calls DWARFExpression::Update_DW_OP_addr, which updates the value associated with OP_addr. However, when we have an OP_addrx, the update function does nothing. This makes sense, as the DWARFExpression does not have a mutable view of the debug_addr section. In non-DebugMap flows this is not an issue, as the debug_addr contains the correct addresses of variables. In DebugMap flows, this is problematic because the work done by RelinkOSOAddress is lost. By updating the OP to OP_addr, we can also update the address as required, We also explored the alternative of relinking the debug_addr section when we are initializing OSOs (InitOSO). However, this creates an inconsistent story for users of DWARFExpression::GetLocation_DW_OP_addr. This function returns an address without telling callers whether that address came from an OP_addr or an OP_addrx. If we preemptively relink OP_addrx results without doing the same for OP_addr results, then callers can’t know whether the address they got was an executable address or an object file address. In other words, they can’t know whether they need to call LinkOSOFileAddress on those results or not. This patch addresses the majority of test failures when enabling DWARF 5 for MachO (over 200 test failures). Differential Revision: https://reviews.llvm.org/D155198
2023-07-10[LLDB] Fix buffer overflow problem in DWARFExpression::EvaluateCaroline Tice
In two calls to ReadMemory in DWARFExpression.cpp, the buffer size passed to ReadMemory is not checked and can be bigger than the actual size of the buffer. This caused a buffer overflow bug, which we found through Address Sanitizer. This patch fixes the problem by checking the address size when it is first read out of the DWARF, and setting an error and returning immediatley if the size is invalid. This is the second attempt to fix this issue; I reverted the first one, as it was not quite correct. Differential Revision: https://reviews.llvm.org/D154907
2023-07-10Revert "[LLDB] Fix buffer overflow problem in DWARFExpression::Evaluate."Caroline Tice
This reverts commit ee476996bec7f170928505a4c5b7715183cfbada. That commit was not the right way to fix the issue (it could result in reading too many bytes). A better fix is in the works. Original review: https://reviews.llvm.org/D153840
2023-07-03[lldb][NFC] Simplify GetLocation_DW_OP_addr functionFelipe de Azevedo Piovezan
A very old commit (9422dd64f870dd33) changed the signature of this function in a number of ways. This patch aims to improve it: 1. Reword the documentation, which still mentions old parameters that no longer exist, and to elaborate upon the behavior of this function. 2. Remove the unnecessary parameter `op_addr_idx`. This parameter is odd in a couple of ways: we never use it with a value that is non-zero, and the matching `Update_DW_OP_addr` function doesn't use a similar parameter. We also document that this new behavior. If we ever decide to handle multiple "DW_OP_addr", we can introduce the complexity again. Differential Revision: https://reviews.llvm.org/D154265
2023-06-28[LLDB] Fix buffer overflow problem in DWARFExpression::Evaluate.Caroline Tice
In two calls to ReadMemory in DWARFExpression.cpp, the buffer size passed to ReadMemory is not actually the size of the buffer (I suspect a copy/paste error where the variable name was not properly updated). This caused a buffer overflow bug, which we found throuth Address Sanitizer. This patch fixes the problem by passing the correct buffer size to the calls to ReadMemory (and to the DataExtractor). Differential Revision: https://reviews.llvm.org/D153840
2023-05-05Reland "[lldb][DWARFExpression] Fix DW_OP_div to use signed division"LU Hongyi
This patch resolves an issue where a value is incorrectly displayed if it is represented by DW_OP_div. This issue is caused by lldb evaluating operands of DW_OP_div as unsigned and performed unintended unsigned division. This issue is resolved by creating two temporary signed scalar and performing signed division. (Addresses GH#61727) Differential Revision: https://reviews.llvm.org/D147370
2023-05-02Revert "[lldb][DWARFExpression] Fix DW_OP_div to use signed division"Michael Buch
This reverts commit e15d6b520e1e85d2cdf9ffc66f0c4698390eaa3d. Newly added test fails on Darwin platforms and arm. Differential Revision: https://reviews.llvm.org/D147370
2023-05-02[lldb][DWARFExpression] Fix DW_OP_div to use signed divisionLU Hongyi
This patch resolves an issue where a value is incorrectly displayed if it is represented by DW_OP_div. This issue is caused by lldb evaluating operands of DW_OP_div as unsigned and performed unintended unsigned division. This issue is resolved by creating two temporary signed scalar and performing signed division. (Addresses GH#61727) Differential Revision: https://reviews.llvm.org/D147370
2023-02-13[lldb] Fix image lookup crashAlex Langford
lldb may crash when performing `image lookup --verbose --address $ADDR`. The ExecutionContext that gets passed into DWARFExpression::Evaluate may be valid but unpopulated. However, in one specific case, we were assuming that it has a valid Target and using it without checking first. We reach this codepath when we attempt to get information about an address that doesn't map to a CompileUnit in the module containing the requested address. lldb then checks to see if it maps to a global variable, so lldb has to evaluate the location of each global variable in the module. If a location expression contains DW_OP_deref_size that uses a FileAddress, we hit this code path. The simplest test case is to take a module that has a global variable with DW_OP_deref_size in its location expression, attempt to read an address that doesn't map to a CompileUnit (e.g. 0x0) and ensure we don't crash. Differential Revision: https://reviews.llvm.org/D143792
2023-01-07[lldb] Remove remaining uses of llvm::Optional (NFC)Kazu Hirata
This patch removes the unused "using" declarations, updates comments, and removes #include "llvm/ADT/Optional.h". 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
2023-01-07[lldb] Use std::optional instead of llvm::Optional (NFC)Kazu Hirata
This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to clean up the "using" declarations, #include "llvm/ADT/Optional.h", etc. 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
2023-01-07[lldb] Add #include <optional> (NFC)Kazu Hirata
This patch adds #include <optional> to those files containing llvm::Optional<...> or Optional<...>. I'll post a separate patch to actually replace llvm::Optional with 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-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-02Leave DW_OP_addr addresses as load addresses in DWARFExpressionJason Molenda
DWARFExpression::Evaluate will convert DW_OP_addr addresses in a DWARF expression into load addresses on the expression stack when there is a StackFrame in the ExecutionContext, this from a change in 2018 in https://reviews.llvm.org/D46362. At the time this was handling a case that came up in swift programs, and is no longer necessary. I generalized this conversion to a load address when a Target is available in https://reviews.llvm.org/D137682 to make a test case possible; this change broke a use case that Ted reported. This change removes my test case, and removes this conversion of a DW_OP_addr into a load address in some instances. Differential Revision: https://reviews.llvm.org/D139226
2022-11-22[lldb] Allow plugins to extend DWARF expression parsing for vendor extensionsPhilip Pfaffe
Parsing DWARF expressions currently does not support DW_OPs that are vendor extensions. With this change expression parsing calls into SymbolFileDWARF for unknown opcodes, which is the semantically "closest" plugin that we have right now. Plugins can then extend SymbolFileDWARF to add support for vendor extensions. Reviewed By: labath Differential Revision: https://reviews.llvm.org/D137247