[Lldb-commits] [lldb] [lldb-dap][test] Set disableASLR to False for tests (PR #113593)
https://github.com/JDevlieghere approved this pull request. https://github.com/llvm/llvm-project/pull/113593 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Extend FindTypes to optionally search by mangled type name (PR #113007)
https://github.com/Michael137 edited https://github.com/llvm/llvm-project/pull/113007 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to lldb/examples (PR #113398)
@@ -0,0 +1,165 @@
+# A bytecode for (LLDB) data formatters
+
+## Background
+
+LLDB provides very rich customization options to display data types (see
https://lldb.llvm.org/use/variable.html ). To use custom data formatters,
developers typically need to edit the global `~/.lldbinit` file to make sure
they are found and loaded. An example for this workflow is the
`llvm/utils/lldbDataFormatters.py` script. Because of the manual configuration
that is involved, this workflow doesn't scale very well. What would be nice is
if developers or library authors could ship ship data formatters with their
code and LLDB automatically finds them.
+
+In Swift we added the `DebugDescription` macro (see
https://www.swift.org/blog/announcing-swift-6/#debugging ) that translates
Swift string interpolation into LLDB summary strings, and puts them into a
`.lldbsummaries` section, where LLDB can find them. This works well for simple
summaries, but doesn't scale to synthetic child providers or summaries that
need to perform some kind of conditional logic or computation. The logical next
step would be to store full Python formatters instead of summary strings, but
Python code is larger and more importantly it is potentially dangerous to just
load an execute untrusted Python code in LLDB.
+
+This document describes a minimal bytecode tailored to running LLDB
formatters. It defines a human-readable assembler representation for the
language, an efficient binary encoding, a virtual machine for evaluating it,
and format for embedding formatters into binary containers.
+
+### Goals
+
+Provide an efficient and secure encoding for data formatters that can be used
as a compilation target from user-friendly representations (such as DIL, Swift
DebugDescription, or NatVis).
+
+### Non-goals
+
+While humans could write the assembler syntax, making it user-friendly is not
a goal.
+
+## Design of the virtual machine
+
+The LLDB formatter virtual machine uses a stack-based bytecode, comparable
with DWARF expressions, but with higher-level data types and functions.
+
+The virtual machine has two stacks, a data and a control stack. The control
stack is kept separate to make it easier to reason about the security aspects
of the VM.
+
+### Data types
+These data types are "host" data types, in LLDB parlance.
+- _String_ (UTF-8)
+- _Int_ (64 bit)
+- _UInt_ (64 bit)
+- _Object_ (Basically an `SBValue`)
+- _Type_ (Basically an `SBType`)
+- _Selector_ (One of the predefine functions)
+
+_Object_ and _Type_ are opaque, they can only be used as a parameters of
`call`.
+
+## Instruction set
+
+### Stack operations
+
+These manipulate the data stack directly.
+
+- `dup (x -> x x)`
+- `drop (x y -> x)`
+- `pick (x ... UInt -> x ... x)`
+- `over (x y -> y)`
+- `swap (x y -> y x)`
+- `rot (x y z -> z x y)`
+
+### Control flow
+
+- `{` pushes a code block address onto the control stack
+- `}` (technically not an opcode) denotes the end of a code block
+- `if` pops a block from the control stack, if the top of the data stack is
nonzero, executes it
+- `ifelse` pops two blocks from the control stack, if the top of the data
stack is nonzero, executes the first, otherwise the second.
+
+### Literals for basic types
+
+- `123u ( -> UInt)` an unsigned 64-bit host integer.
+- `123 ( -> Int)` a signed 64-bit host integer.
+- `"abc" ( -> String)` a UTF-8 host string.
+- `@strlen ( -> Selector)` one of the predefined functions supported by the VM.
+
+### Arithmetic, logic, and comparison operations
+- `+ (x y -> [x+y])`
+- `-` etc ...
+- `*`
+- `/`
+- `%`
+- `<<`
+- `>>`
+- `shra` (arithmetic shift right)
+- `~`
+- `|`
+- `^`
+- `=`
+- `!=`
+- `<`
+- `>`
+- `=<`
+- `>=`
+
+### Function calls
+
+For security reasons the list of functions callable with `call` is predefined.
The supported functions are either existing methods on `SBValue`, or string
formatting operations.
+
+- `call (Object arg0 ... Selector -> retval)`
+
+Method is one of a predefined set of _Selectors_
+- `(Object @summary -> String)`
+- `(Object @type_summary -> String)`
+
+- `(Object @get_num_children -> UInt)`
+- `(Object UInt @get_child_at_index -> Object)`
+- `(Object String @get_child_index -> UInt)`
+- `(Object @get_type -> Type)`
+- `(Object UInt @get_template_argument_type -> Type)`
+- `(Object @get_value -> Object)`
+- `(Object @get_value_as_unsigned -> UInt)`
+- `(Object @get_value_as_signed -> Int)`
+- `(Object @get_value_as_address -> UInt)`
+- `(Object Type @cast -> Object)`
+
+- `(UInt @read_memory_byte -> UInt)`
+- `(UInt @read_memory_uint32 -> UInt)`
+- `(UInt @read_memory_int32 -> Int)`
+- `(UInt @read_memory_unsigned -> UInt)`
+- `(UInt @read_memory_signed -> Int)`
+- `(UInt @read_memory_address -> UInt)`
+- `(UInt Type @read_memory -> Object)`
+
+- `(String arg0 ... fmt -> String)`
+- `(String arg0 ... sprintf -> String)`
+- `(String strlen -> String)`
+
+## Byte Code
+
+Most instructions are just a single byte opcode. The only exceptions
[Lldb-commits] [lldb] Fix pointer to reference type (PR #113596)
https://github.com/jeffreytan81 closed https://github.com/llvm/llvm-project/pull/113596 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Extend FindTypes to optionally search by mangled type name (PR #113007)
https://github.com/Michael137 edited https://github.com/llvm/llvm-project/pull/113007 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fix crash missing MSInheritanceAttr on CXXRecordDecl with DWARF on Windows (PR #112928)
weliveindetail wrote: Hi @rastogishubham thanks for acting on this! The log of this particular run was deleted already, but https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/as-lldb-cmake/13958 likely failed for the same reason: ``` lldb-build/bin/clang --driver-mode=cl --target=specify-a-target-or-use-a-_host-substitution --target=x86_64-windows-msvc -c -gdwarf /Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/Shell/SymbolFile/DWARF/x86/member-pointers.cpp -o /Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/tools/lldb/test/Shell/SymbolFile/DWARF/x86/Output/member-pointers.cpp.tmp_win.obj clang: warning: '/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/Shell/SymbolFile/DWARF/x86/member-pointers.cpp' treated as the '/U' option [-Wslash-u-filename] clang: note: use '--' to treat subsequent arguments as filenames clang: error: no input files ``` Apparently, `/U` is an option for the clang `cl` mode driver and this collides with the start of the file name path in `/Users/...`. Let me prepare a patch for it. https://github.com/llvm/llvm-project/pull/112928 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Add the ability to break on call-site locations, improve inline stepping (PR #112939)
https://github.com/jimingham updated
https://github.com/llvm/llvm-project/pull/112939
>From 9c6705b21df14dc911665e1082c9b31ce00d7e7c Mon Sep 17 00:00:00 2001
From: Jim Ingham
Date: Thu, 3 Oct 2024 18:24:46 -0700
Subject: [PATCH 01/11] Add the ability to break on call-site locations, report
the correct position in the virtual inlined call stack when they are hit, and
step through the inlined stack from there.
---
.../lldb/Breakpoint/BreakpointLocation.h | 31
lldb/include/lldb/Breakpoint/BreakpointSite.h | 5 +
lldb/include/lldb/Target/StopInfo.h | 11 ++
.../lldb/Target/ThreadPlanStepInRange.h | 4 +-
lldb/source/Breakpoint/BreakpointLocation.cpp | 61 ++-
lldb/source/Breakpoint/BreakpointResolver.cpp | 12 ++
lldb/source/Breakpoint/BreakpointSite.cpp | 16 ++
lldb/source/Core/Declaration.cpp | 2 +-
lldb/source/Symbol/CompileUnit.cpp| 104 ++-
lldb/source/Target/StackFrameList.cpp | 170 ++
lldb/source/Target/StopInfo.cpp | 55 ++
lldb/source/Target/Thread.cpp | 8 +
lldb/source/Target/ThreadPlanStepInRange.cpp | 24 ++-
.../source/Target/ThreadPlanStepOverRange.cpp | 2 +-
.../inline-stepping/TestInlineStepping.py | 54 ++
.../inline-stepping/calling.cpp | 31
16 files changed, 462 insertions(+), 128 deletions(-)
diff --git a/lldb/include/lldb/Breakpoint/BreakpointLocation.h
b/lldb/include/lldb/Breakpoint/BreakpointLocation.h
index cca00335bc3c67..f9c258daf137f7 100644
--- a/lldb/include/lldb/Breakpoint/BreakpointLocation.h
+++ b/lldb/include/lldb/Breakpoint/BreakpointLocation.h
@@ -11,10 +11,12 @@
#include
#include
+#include
#include "lldb/Breakpoint/BreakpointOptions.h"
#include "lldb/Breakpoint/StoppointHitCounter.h"
#include "lldb/Core/Address.h"
+#include "lldb/Symbol/LineEntry.h"
#include "lldb/Utility/UserID.h"
#include "lldb/lldb-private.h"
@@ -281,6 +283,18 @@ class BreakpointLocation
/// Returns the breakpoint location ID.
lldb::break_id_t GetID() const { return m_loc_id; }
+
+ // Set the line entry that should be shown to users for this location.
+ // It is up to the caller to verify that this is a valid entry to show.
+ // The current use of this is to distinguish among line entries from a
+ // virtual inlined call stack that all share the same address.
+ void SetPreferredLineEntry(const LineEntry &line_entry) {
+m_preferred_line_entry = line_entry;
+ }
+
+ const std::optional GetPreferredLineEntry() {
+return m_preferred_line_entry;
+ }
protected:
friend class BreakpointSite;
@@ -305,6 +319,16 @@ class BreakpointLocation
/// It also takes care of decrementing the ignore counters.
/// If it returns false we should continue, otherwise stop.
bool IgnoreCountShouldStop();
+
+ // If this location knows that the virtual stack frame it represents is
+ // not frame 0, return the suggested stack frame instead. This will happen
+ // when the location's address contains a "virtual inlined call stack" and
the
+ // breakpoint was set on a file & line that are not at the bottom of that
+ // stack. For now we key off the "preferred line entry" - looking for that
+ // in the blocks that start with the stop PC.
+ // This version of the API doesn't take an "inlined" parameter because it
+ // only changes frames in the inline stack.
+ std::optional GetSuggestedStackFrameIndex();
private:
void SwapLocation(lldb::BreakpointLocationSP swap_from);
@@ -369,6 +393,13 @@ class BreakpointLocation
lldb::break_id_t m_loc_id; ///< Breakpoint location ID.
StoppointHitCounter m_hit_counter; ///< Number of times this breakpoint
/// location has been hit.
+ std::optional m_preferred_line_entry; // If this exists, use it
to print the stop
+// description rather than the LineEntry
+// m_address resolves to directly. Use
this
+// for instance when the location was given
+// somewhere in the virtual inlined call
+// stack since the Address always resolves
+// to the lowest entry in the stack.
void SetShouldResolveIndirectFunctions(bool do_resolve) {
m_should_resolve_indirect_functions = do_resolve;
diff --git a/lldb/include/lldb/Breakpoint/BreakpointSite.h
b/lldb/include/lldb/Breakpoint/BreakpointSite.h
index 17b76d51c1ae53..30cb5a80b908e0 100644
--- a/lldb/include/lldb/Breakpoint/BreakpointSite.h
+++ b/lldb/include/lldb/Breakpoint/BreakpointSite.h
@@ -169,6 +169,11 @@ class BreakpointSite : public
std::enable_shared_from_this,
///
/// \see lldb::DescriptionLevel
void GetDescription(Stream *s, lldb::DescriptionLevel level);
+
+ // This runs through all the breakpoint locations owning this
[Lldb-commits] [lldb] Add the ability to break on call-site locations, improve inline stepping (PR #112939)
@@ -508,8 +508,20 @@ void BreakpointLocation::GetDescription(Stream *s,
s->PutCString("re-exported target = ");
else
s->PutCString("where = ");
+
+ // If there's a preferred line entry for printing, use that.
+ bool show_function_info = true;
+ if (auto preferred = GetPreferredLineEntry()) {
+sc.line_entry = *preferred;
+// FIXME: We're going to get the function name wrong when the preferred
+// line entry is not the lowest one. For now, just leave the function
+// out in this case, but we really should also figure out how to easily
+// fake the function name here.
jimingham wrote:
I added one more change here, since the intention is that you cannot change the
PC of the breakpoint Location by setting a PreferredLineEntry, I changed the
code to actually check that when you call SetPreferredLineEntry. I put in an
assert in the setter, so we can catch any violations of this in the testsuite,
and then if this happens IRL, I made the BreakpointLocation log the event and
ignore the setting.
https://github.com/llvm/llvm-project/pull/112939
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to lldb/examples (PR #113398)
@@ -0,0 +1,165 @@
+# A bytecode for (LLDB) data formatters
+
+## Background
+
+LLDB provides very rich customization options to display data types (see
https://lldb.llvm.org/use/variable.html ). To use custom data formatters,
developers typically need to edit the global `~/.lldbinit` file to make sure
they are found and loaded. An example for this workflow is the
`llvm/utils/lldbDataFormatters.py` script. Because of the manual configuration
that is involved, this workflow doesn't scale very well. What would be nice is
if developers or library authors could ship ship data formatters with their
code and LLDB automatically finds them.
+
+In Swift we added the `DebugDescription` macro (see
https://www.swift.org/blog/announcing-swift-6/#debugging ) that translates
Swift string interpolation into LLDB summary strings, and puts them into a
`.lldbsummaries` section, where LLDB can find them. This works well for simple
summaries, but doesn't scale to synthetic child providers or summaries that
need to perform some kind of conditional logic or computation. The logical next
step would be to store full Python formatters instead of summary strings, but
Python code is larger and more importantly it is potentially dangerous to just
load an execute untrusted Python code in LLDB.
+
+This document describes a minimal bytecode tailored to running LLDB
formatters. It defines a human-readable assembler representation for the
language, an efficient binary encoding, a virtual machine for evaluating it,
and format for embedding formatters into binary containers.
+
+### Goals
+
+Provide an efficient and secure encoding for data formatters that can be used
as a compilation target from user-friendly representations (such as DIL, Swift
DebugDescription, or NatVis).
+
+### Non-goals
+
+While humans could write the assembler syntax, making it user-friendly is not
a goal.
+
+## Design of the virtual machine
+
+The LLDB formatter virtual machine uses a stack-based bytecode, comparable
with DWARF expressions, but with higher-level data types and functions.
+
+The virtual machine has two stacks, a data and a control stack. The control
stack is kept separate to make it easier to reason about the security aspects
of the VM.
+
+### Data types
+These data types are "host" data types, in LLDB parlance.
+- _String_ (UTF-8)
+- _Int_ (64 bit)
+- _UInt_ (64 bit)
+- _Object_ (Basically an `SBValue`)
+- _Type_ (Basically an `SBType`)
+- _Selector_ (One of the predefine functions)
+
+_Object_ and _Type_ are opaque, they can only be used as a parameters of
`call`.
+
+## Instruction set
+
+### Stack operations
+
+These manipulate the data stack directly.
+
+- `dup (x -> x x)`
+- `drop (x y -> x)`
+- `pick (x ... UInt -> x ... x)`
+- `over (x y -> y)`
+- `swap (x y -> y x)`
+- `rot (x y z -> z x y)`
+
+### Control flow
+
+- `{` pushes a code block address onto the control stack
+- `}` (technically not an opcode) denotes the end of a code block
+- `if` pops a block from the control stack, if the top of the data stack is
nonzero, executes it
+- `ifelse` pops two blocks from the control stack, if the top of the data
stack is nonzero, executes the first, otherwise the second.
+
+### Literals for basic types
+
+- `123u ( -> UInt)` an unsigned 64-bit host integer.
+- `123 ( -> Int)` a signed 64-bit host integer.
+- `"abc" ( -> String)` a UTF-8 host string.
+- `@strlen ( -> Selector)` one of the predefined functions supported by the VM.
+
+### Arithmetic, logic, and comparison operations
+- `+ (x y -> [x+y])`
+- `-` etc ...
+- `*`
+- `/`
+- `%`
+- `<<`
+- `>>`
+- `shra` (arithmetic shift right)
+- `~`
+- `|`
+- `^`
+- `=`
+- `!=`
+- `<`
+- `>`
+- `=<`
+- `>=`
+
+### Function calls
+
+For security reasons the list of functions callable with `call` is predefined.
The supported functions are either existing methods on `SBValue`, or string
formatting operations.
+
+- `call (Object arg0 ... Selector -> retval)`
+
+Method is one of a predefined set of _Selectors_
+- `(Object @summary -> String)`
+- `(Object @type_summary -> String)`
+
+- `(Object @get_num_children -> UInt)`
+- `(Object UInt @get_child_at_index -> Object)`
+- `(Object String @get_child_index -> UInt)`
+- `(Object @get_type -> Type)`
+- `(Object UInt @get_template_argument_type -> Type)`
+- `(Object @get_value -> Object)`
+- `(Object @get_value_as_unsigned -> UInt)`
+- `(Object @get_value_as_signed -> Int)`
+- `(Object @get_value_as_address -> UInt)`
+- `(Object Type @cast -> Object)`
+
+- `(UInt @read_memory_byte -> UInt)`
+- `(UInt @read_memory_uint32 -> UInt)`
+- `(UInt @read_memory_int32 -> Int)`
+- `(UInt @read_memory_unsigned -> UInt)`
+- `(UInt @read_memory_signed -> Int)`
+- `(UInt @read_memory_address -> UInt)`
+- `(UInt Type @read_memory -> Object)`
+
+- `(String arg0 ... fmt -> String)`
+- `(String arg0 ... sprintf -> String)`
+- `(String strlen -> String)`
+
+## Byte Code
+
+Most instructions are just a single byte opcode. The only exceptions
[Lldb-commits] [lldb] [lldb][NFC] Make the target's SectionLoadList private. (PR #113278)
@@ -1140,9 +1140,13 @@ class Target : public
std::enable_shared_from_this,
Address &pointer_addr,
bool force_live_memory = false);
- SectionLoadList &GetSectionLoadList() {
-return m_section_load_history.GetCurrentSectionLoadList();
- }
+ bool HasLoadedSections();
+
+ lldb::addr_t GetSectionLoadAddress(const lldb::SectionSP §ion_sp);
+
+ void ClearSectionLoadList();
jimingham wrote:
It seems like nobody but dynamic loaders should be calling these two. Is there
some way to express that?
https://github.com/llvm/llvm-project/pull/113278
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to lldb/examples (PR #113398)
@@ -0,0 +1,486 @@
+"""
+Specification, compiler, disassembler, and interpreter
+for LLDB dataformatter bytecode.
+
+See formatter-bytecode.md for more details.
+"""
+from __future__ import annotations
+
+# Types
+type_String = 1
+type_Int = 2
+type_UInt = 3
+type_Object = 4
+type_Type = 5
+
+# Opcodes
+opcode = dict()
+
+
+def define_opcode(n, mnemonic, name):
+globals()["op_" + name] = n
+if mnemonic:
+opcode[mnemonic] = n
+opcode[n] = mnemonic
+
+
+define_opcode(1, "dup", "dup")
+define_opcode(2, "drop", "drop")
+define_opcode(3, "pick", "pick")
+define_opcode(4, "over", "over")
+define_opcode(5, "swap", "swap")
+define_opcode(6, "rot", "rot")
+
+define_opcode(0x10, "{", "begin")
+define_opcode(0x11, "if", "if")
+define_opcode(0x12, "ifelse", "ifelse")
+
+define_opcode(0x20, None, "lit_uint")
+define_opcode(0x21, None, "lit_int")
+define_opcode(0x22, None, "lit_string")
+define_opcode(0x23, None, "lit_selector")
+
+define_opcode(0x30, "+", "plus")
+define_opcode(0x31, "-", "minus")
+define_opcode(0x32, "*", "mul")
+define_opcode(0x33, "/", "div")
+define_opcode(0x34, "%", "mod")
+define_opcode(0x35, "<<", "shl")
+define_opcode(0x36, ">>", "shr")
+define_opcode(0x37, "shra", "shra")
+
+define_opcode(0x40, "&", "and")
+define_opcode(0x41, "|", "or")
+define_opcode(0x42, "^", "xor")
+define_opcode(0x43, "~", "not")
+
+define_opcode(0x50, "=", "eq")
+define_opcode(0x51, "!=", "neq")
+define_opcode(0x52, "<", "lt")
+define_opcode(0x53, ">", "gt")
+define_opcode(0x54, "=<", "le")
+define_opcode(0x55, ">=", "ge")
+
+define_opcode(0x60, "call", "call")
+
+# Function signatures
+sig_summary = 0
+sig_init = 1
+sig_get_num_children = 2
+sig_get_child_index = 3
+sig_get_child_at_index = 4
+
+# Selectors
+selector = dict()
DavidSpickett wrote:
But then you have `sprintf` which isn't a member of anything it's a globally
defined thing.
https://github.com/llvm/llvm-project/pull/113398
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Move ValueObject into its own library (NFC) (PR #113393)
JDevlieghere wrote: The GitHub UI made it a lot easier to spot missing libraries. I'm pretty sure I've got them all. It doesn't lead to an error because we link everything together anyway, but it's still the right thing to do. I also had to rebase the PR. https://github.com/llvm/llvm-project/pull/113393 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to lldb/examples (PR #113398)
@@ -0,0 +1,486 @@
+"""
+Specification, compiler, disassembler, and interpreter
+for LLDB dataformatter bytecode.
+
+See formatter-bytecode.md for more details.
+"""
+from __future__ import annotations
+
+# Types
+type_String = 1
+type_Int = 2
+type_UInt = 3
+type_Object = 4
+type_Type = 5
+
+# Opcodes
+opcode = dict()
+
+
+def define_opcode(n, mnemonic, name):
+globals()["op_" + name] = n
+if mnemonic:
+opcode[mnemonic] = n
+opcode[n] = mnemonic
+
+
+define_opcode(1, "dup", "dup")
+define_opcode(2, "drop", "drop")
+define_opcode(3, "pick", "pick")
+define_opcode(4, "over", "over")
+define_opcode(5, "swap", "swap")
+define_opcode(6, "rot", "rot")
+
+define_opcode(0x10, "{", "begin")
+define_opcode(0x11, "if", "if")
+define_opcode(0x12, "ifelse", "ifelse")
+
+define_opcode(0x20, None, "lit_uint")
+define_opcode(0x21, None, "lit_int")
+define_opcode(0x22, None, "lit_string")
+define_opcode(0x23, None, "lit_selector")
+
+define_opcode(0x30, "+", "plus")
+define_opcode(0x31, "-", "minus")
+define_opcode(0x32, "*", "mul")
+define_opcode(0x33, "/", "div")
+define_opcode(0x34, "%", "mod")
+define_opcode(0x35, "<<", "shl")
+define_opcode(0x36, ">>", "shr")
+define_opcode(0x37, "shra", "shra")
porglezomp wrote:
Left shift doesn't have distinct arithmetic and logical shifts, they both
always shift 0s into the bottom bit. If you look at instruction sets you'll see
that generally just have these 3 operations.
https://github.com/llvm/llvm-project/pull/113398
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Fix pointer to reference type (PR #113596)
https://github.com/walter-erquinigo approved this pull request. https://github.com/llvm/llvm-project/pull/113596 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [llvm] Allow specifying libcxx builder image. (PR #110303)
Michael137 wrote: Hmm am I reading this right that the latest run still failed, despite the cherry-pick? https://github.com/llvm/llvm-project/pull/110303 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to lldb/examples (PR #113398)
@@ -0,0 +1,486 @@
+"""
+Specification, compiler, disassembler, and interpreter
+for LLDB dataformatter bytecode.
+
+See formatter-bytecode.md for more details.
+"""
+from __future__ import annotations
+
+# Types
+type_String = 1
+type_Int = 2
+type_UInt = 3
+type_Object = 4
+type_Type = 5
+
+# Opcodes
+opcode = dict()
+
+
+def define_opcode(n, mnemonic, name):
+globals()["op_" + name] = n
+if mnemonic:
+opcode[mnemonic] = n
+opcode[n] = mnemonic
+
+
+define_opcode(1, "dup", "dup")
+define_opcode(2, "drop", "drop")
+define_opcode(3, "pick", "pick")
+define_opcode(4, "over", "over")
+define_opcode(5, "swap", "swap")
+define_opcode(6, "rot", "rot")
+
+define_opcode(0x10, "{", "begin")
+define_opcode(0x11, "if", "if")
+define_opcode(0x12, "ifelse", "ifelse")
+
+define_opcode(0x20, None, "lit_uint")
+define_opcode(0x21, None, "lit_int")
+define_opcode(0x22, None, "lit_string")
+define_opcode(0x23, None, "lit_selector")
+
+define_opcode(0x30, "+", "plus")
+define_opcode(0x31, "-", "minus")
+define_opcode(0x32, "*", "mul")
+define_opcode(0x33, "/", "div")
+define_opcode(0x34, "%", "mod")
+define_opcode(0x35, "<<", "shl")
+define_opcode(0x36, ">>", "shr")
+define_opcode(0x37, "shra", "shra")
DavidSpickett wrote:
`shara` being shift right arithmetic as in copying in sign bit?
If so I agree that the left shift version is less used, I can see why you'd
leave it out. Perhaps you can implement `shla` as a combination of the others.
https://github.com/llvm/llvm-project/pull/113398
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap][test] Set disableASLR to False for tests (PR #113593)
https://github.com/Michael137 created
https://github.com/llvm/llvm-project/pull/113593
When running in constrained environments like docker, disable ASLR might fail
with errors like:
```
AssertionError: False is not true : launch failed (Cannot launch
'/__w/.../lldb-dap/stackTrace/subtleFrames/TestDAP_subtleFrames.test_subtleFrames/a.out':
personality set failed: Operation not permitted)
```
E.g., https://github.com/llvm/llvm-project/pull/110303
Hence we already run `settings set target.disable-aslr false` as part of the
init-commands for the non-DAP tests (see
https://github.com/llvm/llvm-project/pull/88312 and
https://discourse.llvm.org/t/running-lldb-in-a-container/76801).
But we never adjusted it for the DAP tests. Hence we get conflicting test
houtput like:
```
{
"arguments": {
"commandEscapePrefix": null,
"disableASLR": true,
"initCommands": [
...
"settings set target.disable-aslr false",
```
Disabling ASLR by default in tests isn't useulf (it's only really a debugging
aid for users). So this patch sets `disableASLR=False` by default.
>From 135092caf94e69c0aac25bcb73190ea69776d60e Mon Sep 17 00:00:00 2001
From: Michael Buch
Date: Thu, 24 Oct 2024 17:50:02 +0100
Subject: [PATCH] [lldb-dap][test] Set disableASLR to False for tests
When running in constrained environments like docker,
disable ASLR might fail with errors like:
```
AssertionError: False is not true : launch failed (Cannot launch
'/__w/.../lldb-dap/stackTrace/subtleFrames/TestDAP_subtleFrames.test_subtleFrames/a.out':
personality set failed: Operation not permitted)
```
E.g., https://github.com/llvm/llvm-project/pull/110303
Hence we already run `settings set target.disable-aslr false`
as part of the init-commands for the non-DAP tests (see
https://github.com/llvm/llvm-project/pull/88312 and
https://discourse.llvm.org/t/running-lldb-in-a-container/76801).
But we never adjusted it for the DAP tests. Hence we get conflicting
test houtput like:
```
{
"arguments": {
"commandEscapePrefix": null,
"disableASLR": true,
"initCommands": [
...
"settings set target.disable-aslr false",
```
Disabling ASLR by default in tests isn't useulf (it's only really
a debugging aid for users). So this patch sets `disableASLR=False`
by default.
---
.../Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py| 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
index 7e80912be44642..cf30aad6b7f35b 100644
--- a/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
+++ b/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
@@ -367,7 +367,7 @@ def launch(
cwd=None,
env=None,
stopOnEntry=False,
-disableASLR=True,
+disableASLR=False,
disableSTDIO=False,
shellExpandArguments=False,
trace=False,
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fix crash missing MSInheritanceAttr on CXXRecordDecl with DWARF on Windows (PR #112928)
Stefan =?utf-8?q?Gränitz?= , Stefan =?utf-8?q?Gränitz?= , Stefan =?utf-8?q?Gränitz?= , Stefan =?utf-8?q?Gränitz?= , Stefan =?utf-8?q?Gränitz?= , Stefan =?utf-8?q?Gränitz?= Message-ID: In-Reply-To: rastogishubham wrote: @weliveindetail thanks for the fix! I was at the llvm dev meeting so I was slow to respond. The bots are still green so we are good! https://github.com/llvm/llvm-project/pull/112928 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap][test] Set disableASLR to False for tests (PR #113593)
https://github.com/Michael137 edited https://github.com/llvm/llvm-project/pull/113593 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap][test] Set disableASLR to False for tests (PR #113593)
https://github.com/ldionne approved this pull request. Thank you for the prompt fix! https://github.com/llvm/llvm-project/pull/113593 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to lldb/examples (PR #113398)
@@ -0,0 +1,165 @@
+# A bytecode for (LLDB) data formatters
+
+## Background
+
+LLDB provides very rich customization options to display data types (see
https://lldb.llvm.org/use/variable.html ). To use custom data formatters,
developers typically need to edit the global `~/.lldbinit` file to make sure
they are found and loaded. An example for this workflow is the
`llvm/utils/lldbDataFormatters.py` script. Because of the manual configuration
that is involved, this workflow doesn't scale very well. What would be nice is
if developers or library authors could ship ship data formatters with their
code and LLDB automatically finds them.
+
+In Swift we added the `DebugDescription` macro (see
https://www.swift.org/blog/announcing-swift-6/#debugging ) that translates
Swift string interpolation into LLDB summary strings, and puts them into a
`.lldbsummaries` section, where LLDB can find them. This works well for simple
summaries, but doesn't scale to synthetic child providers or summaries that
need to perform some kind of conditional logic or computation. The logical next
step would be to store full Python formatters instead of summary strings, but
Python code is larger and more importantly it is potentially dangerous to just
load an execute untrusted Python code in LLDB.
+
+This document describes a minimal bytecode tailored to running LLDB
formatters. It defines a human-readable assembler representation for the
language, an efficient binary encoding, a virtual machine for evaluating it,
and format for embedding formatters into binary containers.
+
+### Goals
+
+Provide an efficient and secure encoding for data formatters that can be used
as a compilation target from user-friendly representations (such as DIL, Swift
DebugDescription, or NatVis).
+
+### Non-goals
+
+While humans could write the assembler syntax, making it user-friendly is not
a goal.
+
+## Design of the virtual machine
+
+The LLDB formatter virtual machine uses a stack-based bytecode, comparable
with DWARF expressions, but with higher-level data types and functions.
+
+The virtual machine has two stacks, a data and a control stack. The control
stack is kept separate to make it easier to reason about the security aspects
of the VM.
+
+### Data types
+These data types are "host" data types, in LLDB parlance.
+- _String_ (UTF-8)
+- _Int_ (64 bit)
+- _UInt_ (64 bit)
+- _Object_ (Basically an `SBValue`)
+- _Type_ (Basically an `SBType`)
+- _Selector_ (One of the predefine functions)
+
+_Object_ and _Type_ are opaque, they can only be used as a parameters of
`call`.
+
+## Instruction set
+
+### Stack operations
+
+These manipulate the data stack directly.
+
+- `dup (x -> x x)`
+- `drop (x y -> x)`
+- `pick (x ... UInt -> x ... x)`
+- `over (x y -> y)`
+- `swap (x y -> y x)`
+- `rot (x y z -> z x y)`
+
+### Control flow
+
+- `{` pushes a code block address onto the control stack
+- `}` (technically not an opcode) denotes the end of a code block
+- `if` pops a block from the control stack, if the top of the data stack is
nonzero, executes it
+- `ifelse` pops two blocks from the control stack, if the top of the data
stack is nonzero, executes the first, otherwise the second.
+
+### Literals for basic types
+
+- `123u ( -> UInt)` an unsigned 64-bit host integer.
+- `123 ( -> Int)` a signed 64-bit host integer.
+- `"abc" ( -> String)` a UTF-8 host string.
+- `@strlen ( -> Selector)` one of the predefined functions supported by the VM.
+
+### Arithmetic, logic, and comparison operations
+- `+ (x y -> [x+y])`
+- `-` etc ...
+- `*`
+- `/`
+- `%`
+- `<<`
+- `>>`
+- `shra` (arithmetic shift right)
+- `~`
+- `|`
+- `^`
+- `=`
+- `!=`
+- `<`
+- `>`
+- `=<`
+- `>=`
+
+### Function calls
+
+For security reasons the list of functions callable with `call` is predefined.
The supported functions are either existing methods on `SBValue`, or string
formatting operations.
+
+- `call (Object arg0 ... Selector -> retval)`
+
+Method is one of a predefined set of _Selectors_
+- `(Object @summary -> String)`
+- `(Object @type_summary -> String)`
+
+- `(Object @get_num_children -> UInt)`
+- `(Object UInt @get_child_at_index -> Object)`
+- `(Object String @get_child_index -> UInt)`
+- `(Object @get_type -> Type)`
+- `(Object UInt @get_template_argument_type -> Type)`
+- `(Object @get_value -> Object)`
+- `(Object @get_value_as_unsigned -> UInt)`
+- `(Object @get_value_as_signed -> Int)`
+- `(Object @get_value_as_address -> UInt)`
+- `(Object Type @cast -> Object)`
+
+- `(UInt @read_memory_byte -> UInt)`
+- `(UInt @read_memory_uint32 -> UInt)`
+- `(UInt @read_memory_int32 -> Int)`
+- `(UInt @read_memory_unsigned -> UInt)`
+- `(UInt @read_memory_signed -> Int)`
+- `(UInt @read_memory_address -> UInt)`
+- `(UInt Type @read_memory -> Object)`
+
+- `(String arg0 ... fmt -> String)`
+- `(String arg0 ... sprintf -> String)`
+- `(String strlen -> String)`
+
+## Byte Code
+
+Most instructions are just a single byte opcode. The only exceptions
[Lldb-commits] [lldb] [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to lldb/examples (PR #113398)
@@ -0,0 +1,165 @@
+# A bytecode for (LLDB) data formatters
+
+## Background
+
+LLDB provides very rich customization options to display data types (see
https://lldb.llvm.org/use/variable.html ). To use custom data formatters,
developers typically need to edit the global `~/.lldbinit` file to make sure
they are found and loaded. An example for this workflow is the
`llvm/utils/lldbDataFormatters.py` script. Because of the manual configuration
that is involved, this workflow doesn't scale very well. What would be nice is
if developers or library authors could ship ship data formatters with their
code and LLDB automatically finds them.
+
+In Swift we added the `DebugDescription` macro (see
https://www.swift.org/blog/announcing-swift-6/#debugging ) that translates
Swift string interpolation into LLDB summary strings, and puts them into a
`.lldbsummaries` section, where LLDB can find them. This works well for simple
summaries, but doesn't scale to synthetic child providers or summaries that
need to perform some kind of conditional logic or computation. The logical next
step would be to store full Python formatters instead of summary strings, but
Python code is larger and more importantly it is potentially dangerous to just
load an execute untrusted Python code in LLDB.
+
+This document describes a minimal bytecode tailored to running LLDB
formatters. It defines a human-readable assembler representation for the
language, an efficient binary encoding, a virtual machine for evaluating it,
and format for embedding formatters into binary containers.
+
+### Goals
+
+Provide an efficient and secure encoding for data formatters that can be used
as a compilation target from user-friendly representations (such as DIL, Swift
DebugDescription, or NatVis).
+
+### Non-goals
+
+While humans could write the assembler syntax, making it user-friendly is not
a goal.
+
+## Design of the virtual machine
+
+The LLDB formatter virtual machine uses a stack-based bytecode, comparable
with DWARF expressions, but with higher-level data types and functions.
+
+The virtual machine has two stacks, a data and a control stack. The control
stack is kept separate to make it easier to reason about the security aspects
of the VM.
+
+### Data types
+These data types are "host" data types, in LLDB parlance.
+- _String_ (UTF-8)
+- _Int_ (64 bit)
+- _UInt_ (64 bit)
+- _Object_ (Basically an `SBValue`)
+- _Type_ (Basically an `SBType`)
+- _Selector_ (One of the predefine functions)
+
+_Object_ and _Type_ are opaque, they can only be used as a parameters of
`call`.
+
+## Instruction set
+
+### Stack operations
+
+These manipulate the data stack directly.
+
+- `dup (x -> x x)`
+- `drop (x y -> x)`
+- `pick (x ... UInt -> x ... x)`
+- `over (x y -> y)`
+- `swap (x y -> y x)`
+- `rot (x y z -> z x y)`
+
+### Control flow
+
+- `{` pushes a code block address onto the control stack
+- `}` (technically not an opcode) denotes the end of a code block
+- `if` pops a block from the control stack, if the top of the data stack is
nonzero, executes it
+- `ifelse` pops two blocks from the control stack, if the top of the data
stack is nonzero, executes the first, otherwise the second.
+
+### Literals for basic types
+
+- `123u ( -> UInt)` an unsigned 64-bit host integer.
+- `123 ( -> Int)` a signed 64-bit host integer.
+- `"abc" ( -> String)` a UTF-8 host string.
+- `@strlen ( -> Selector)` one of the predefined functions supported by the VM.
+
+### Arithmetic, logic, and comparison operations
+- `+ (x y -> [x+y])`
+- `-` etc ...
+- `*`
+- `/`
+- `%`
+- `<<`
+- `>>`
+- `shra` (arithmetic shift right)
+- `~`
+- `|`
+- `^`
+- `=`
+- `!=`
+- `<`
+- `>`
+- `=<`
+- `>=`
+
+### Function calls
+
+For security reasons the list of functions callable with `call` is predefined.
The supported functions are either existing methods on `SBValue`, or string
formatting operations.
+
+- `call (Object arg0 ... Selector -> retval)`
+
+Method is one of a predefined set of _Selectors_
+- `(Object @summary -> String)`
+- `(Object @type_summary -> String)`
+
+- `(Object @get_num_children -> UInt)`
+- `(Object UInt @get_child_at_index -> Object)`
+- `(Object String @get_child_index -> UInt)`
+- `(Object @get_type -> Type)`
+- `(Object UInt @get_template_argument_type -> Type)`
+- `(Object @get_value -> Object)`
+- `(Object @get_value_as_unsigned -> UInt)`
+- `(Object @get_value_as_signed -> Int)`
+- `(Object @get_value_as_address -> UInt)`
+- `(Object Type @cast -> Object)`
+
+- `(UInt @read_memory_byte -> UInt)`
+- `(UInt @read_memory_uint32 -> UInt)`
+- `(UInt @read_memory_int32 -> Int)`
+- `(UInt @read_memory_unsigned -> UInt)`
+- `(UInt @read_memory_signed -> Int)`
+- `(UInt @read_memory_address -> UInt)`
+- `(UInt Type @read_memory -> Object)`
+
+- `(String arg0 ... fmt -> String)`
+- `(String arg0 ... sprintf -> String)`
+- `(String strlen -> String)`
+
+## Byte Code
+
+Most instructions are just a single byte opcode. The only exceptions
[Lldb-commits] [lldb] [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to lldb/examples (PR #113398)
@@ -0,0 +1,165 @@
+# A bytecode for (LLDB) data formatters
+
+## Background
+
+LLDB provides very rich customization options to display data types (see
https://lldb.llvm.org/use/variable.html ). To use custom data formatters,
developers typically need to edit the global `~/.lldbinit` file to make sure
they are found and loaded. An example for this workflow is the
`llvm/utils/lldbDataFormatters.py` script. Because of the manual configuration
that is involved, this workflow doesn't scale very well. What would be nice is
if developers or library authors could ship ship data formatters with their
code and LLDB automatically finds them.
+
+In Swift we added the `DebugDescription` macro (see
https://www.swift.org/blog/announcing-swift-6/#debugging ) that translates
Swift string interpolation into LLDB summary strings, and puts them into a
`.lldbsummaries` section, where LLDB can find them. This works well for simple
summaries, but doesn't scale to synthetic child providers or summaries that
need to perform some kind of conditional logic or computation. The logical next
step would be to store full Python formatters instead of summary strings, but
Python code is larger and more importantly it is potentially dangerous to just
load an execute untrusted Python code in LLDB.
+
+This document describes a minimal bytecode tailored to running LLDB
formatters. It defines a human-readable assembler representation for the
language, an efficient binary encoding, a virtual machine for evaluating it,
and format for embedding formatters into binary containers.
+
+### Goals
+
+Provide an efficient and secure encoding for data formatters that can be used
as a compilation target from user-friendly representations (such as DIL, Swift
DebugDescription, or NatVis).
+
+### Non-goals
+
+While humans could write the assembler syntax, making it user-friendly is not
a goal.
+
+## Design of the virtual machine
+
+The LLDB formatter virtual machine uses a stack-based bytecode, comparable
with DWARF expressions, but with higher-level data types and functions.
+
+The virtual machine has two stacks, a data and a control stack. The control
stack is kept separate to make it easier to reason about the security aspects
of the VM.
+
+### Data types
+These data types are "host" data types, in LLDB parlance.
+- _String_ (UTF-8)
+- _Int_ (64 bit)
+- _UInt_ (64 bit)
+- _Object_ (Basically an `SBValue`)
+- _Type_ (Basically an `SBType`)
+- _Selector_ (One of the predefine functions)
+
+_Object_ and _Type_ are opaque, they can only be used as a parameters of
`call`.
+
+## Instruction set
+
+### Stack operations
+
+These manipulate the data stack directly.
+
+- `dup (x -> x x)`
+- `drop (x y -> x)`
+- `pick (x ... UInt -> x ... x)`
+- `over (x y -> y)`
+- `swap (x y -> y x)`
+- `rot (x y z -> z x y)`
+
+### Control flow
+
+- `{` pushes a code block address onto the control stack
+- `}` (technically not an opcode) denotes the end of a code block
+- `if` pops a block from the control stack, if the top of the data stack is
nonzero, executes it
+- `ifelse` pops two blocks from the control stack, if the top of the data
stack is nonzero, executes the first, otherwise the second.
+
+### Literals for basic types
+
+- `123u ( -> UInt)` an unsigned 64-bit host integer.
+- `123 ( -> Int)` a signed 64-bit host integer.
+- `"abc" ( -> String)` a UTF-8 host string.
+- `@strlen ( -> Selector)` one of the predefined functions supported by the VM.
+
+### Arithmetic, logic, and comparison operations
+- `+ (x y -> [x+y])`
+- `-` etc ...
+- `*`
+- `/`
+- `%`
+- `<<`
+- `>>`
+- `shra` (arithmetic shift right)
+- `~`
+- `|`
+- `^`
+- `=`
+- `!=`
+- `<`
+- `>`
+- `=<`
+- `>=`
+
+### Function calls
+
+For security reasons the list of functions callable with `call` is predefined.
The supported functions are either existing methods on `SBValue`, or string
formatting operations.
+
+- `call (Object arg0 ... Selector -> retval)`
+
+Method is one of a predefined set of _Selectors_
DavidSpickett wrote:
And this is a stricly predefined list I'm guessing. As opposed to generating
the list from all the members of SBValue.
Which makes sense, we don't want a sandbox escape because of some internal
function on SBValue that we forgot to validate.
https://github.com/llvm/llvm-project/pull/113398
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to lldb/examples (PR #113398)
@@ -0,0 +1,165 @@
+# A bytecode for (LLDB) data formatters
+
+## Background
+
+LLDB provides very rich customization options to display data types (see
https://lldb.llvm.org/use/variable.html ). To use custom data formatters,
developers typically need to edit the global `~/.lldbinit` file to make sure
they are found and loaded. An example for this workflow is the
`llvm/utils/lldbDataFormatters.py` script. Because of the manual configuration
that is involved, this workflow doesn't scale very well. What would be nice is
if developers or library authors could ship ship data formatters with their
code and LLDB automatically finds them.
+
+In Swift we added the `DebugDescription` macro (see
https://www.swift.org/blog/announcing-swift-6/#debugging ) that translates
Swift string interpolation into LLDB summary strings, and puts them into a
`.lldbsummaries` section, where LLDB can find them. This works well for simple
summaries, but doesn't scale to synthetic child providers or summaries that
need to perform some kind of conditional logic or computation. The logical next
step would be to store full Python formatters instead of summary strings, but
Python code is larger and more importantly it is potentially dangerous to just
load an execute untrusted Python code in LLDB.
+
+This document describes a minimal bytecode tailored to running LLDB
formatters. It defines a human-readable assembler representation for the
language, an efficient binary encoding, a virtual machine for evaluating it,
and format for embedding formatters into binary containers.
+
+### Goals
+
+Provide an efficient and secure encoding for data formatters that can be used
as a compilation target from user-friendly representations (such as DIL, Swift
DebugDescription, or NatVis).
+
+### Non-goals
+
+While humans could write the assembler syntax, making it user-friendly is not
a goal.
+
+## Design of the virtual machine
+
+The LLDB formatter virtual machine uses a stack-based bytecode, comparable
with DWARF expressions, but with higher-level data types and functions.
+
+The virtual machine has two stacks, a data and a control stack. The control
stack is kept separate to make it easier to reason about the security aspects
of the VM.
+
+### Data types
+These data types are "host" data types, in LLDB parlance.
+- _String_ (UTF-8)
+- _Int_ (64 bit)
+- _UInt_ (64 bit)
+- _Object_ (Basically an `SBValue`)
+- _Type_ (Basically an `SBType`)
+- _Selector_ (One of the predefine functions)
+
+_Object_ and _Type_ are opaque, they can only be used as a parameters of
`call`.
+
+## Instruction set
+
+### Stack operations
+
+These manipulate the data stack directly.
+
+- `dup (x -> x x)`
+- `drop (x y -> x)`
+- `pick (x ... UInt -> x ... x)`
+- `over (x y -> y)`
+- `swap (x y -> y x)`
+- `rot (x y z -> z x y)`
+
+### Control flow
+
+- `{` pushes a code block address onto the control stack
+- `}` (technically not an opcode) denotes the end of a code block
+- `if` pops a block from the control stack, if the top of the data stack is
nonzero, executes it
+- `ifelse` pops two blocks from the control stack, if the top of the data
stack is nonzero, executes the first, otherwise the second.
+
+### Literals for basic types
+
+- `123u ( -> UInt)` an unsigned 64-bit host integer.
+- `123 ( -> Int)` a signed 64-bit host integer.
+- `"abc" ( -> String)` a UTF-8 host string.
DavidSpickett wrote:
I don't know much about string encodings but I know someone asked the other day
about printing strings in I think a non-utf8 form. Does UTF-8 work well enough
as a container for the other possible encodings?
Or in other words, are there situations where an `ASCII host string` would be
needed?
https://github.com/llvm/llvm-project/pull/113398
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to lldb/examples (PR #113398)
@@ -0,0 +1,165 @@
+# A bytecode for (LLDB) data formatters
+
+## Background
+
+LLDB provides very rich customization options to display data types (see
https://lldb.llvm.org/use/variable.html ). To use custom data formatters,
developers typically need to edit the global `~/.lldbinit` file to make sure
they are found and loaded. An example for this workflow is the
`llvm/utils/lldbDataFormatters.py` script. Because of the manual configuration
that is involved, this workflow doesn't scale very well. What would be nice is
if developers or library authors could ship ship data formatters with their
code and LLDB automatically finds them.
+
+In Swift we added the `DebugDescription` macro (see
https://www.swift.org/blog/announcing-swift-6/#debugging ) that translates
Swift string interpolation into LLDB summary strings, and puts them into a
`.lldbsummaries` section, where LLDB can find them. This works well for simple
summaries, but doesn't scale to synthetic child providers or summaries that
need to perform some kind of conditional logic or computation. The logical next
step would be to store full Python formatters instead of summary strings, but
Python code is larger and more importantly it is potentially dangerous to just
load an execute untrusted Python code in LLDB.
+
+This document describes a minimal bytecode tailored to running LLDB
formatters. It defines a human-readable assembler representation for the
language, an efficient binary encoding, a virtual machine for evaluating it,
and format for embedding formatters into binary containers.
+
+### Goals
+
+Provide an efficient and secure encoding for data formatters that can be used
as a compilation target from user-friendly representations (such as DIL, Swift
DebugDescription, or NatVis).
+
+### Non-goals
+
+While humans could write the assembler syntax, making it user-friendly is not
a goal.
+
+## Design of the virtual machine
+
+The LLDB formatter virtual machine uses a stack-based bytecode, comparable
with DWARF expressions, but with higher-level data types and functions.
+
+The virtual machine has two stacks, a data and a control stack. The control
stack is kept separate to make it easier to reason about the security aspects
of the VM.
+
+### Data types
+These data types are "host" data types, in LLDB parlance.
+- _String_ (UTF-8)
+- _Int_ (64 bit)
+- _UInt_ (64 bit)
+- _Object_ (Basically an `SBValue`)
+- _Type_ (Basically an `SBType`)
+- _Selector_ (One of the predefine functions)
+
+_Object_ and _Type_ are opaque, they can only be used as a parameters of
`call`.
+
+## Instruction set
+
+### Stack operations
+
+These manipulate the data stack directly.
+
+- `dup (x -> x x)`
+- `drop (x y -> x)`
+- `pick (x ... UInt -> x ... x)`
+- `over (x y -> y)`
+- `swap (x y -> y x)`
+- `rot (x y z -> z x y)`
+
+### Control flow
+
+- `{` pushes a code block address onto the control stack
+- `}` (technically not an opcode) denotes the end of a code block
+- `if` pops a block from the control stack, if the top of the data stack is
nonzero, executes it
+- `ifelse` pops two blocks from the control stack, if the top of the data
stack is nonzero, executes the first, otherwise the second.
+
+### Literals for basic types
+
+- `123u ( -> UInt)` an unsigned 64-bit host integer.
+- `123 ( -> Int)` a signed 64-bit host integer.
+- `"abc" ( -> String)` a UTF-8 host string.
+- `@strlen ( -> Selector)` one of the predefined functions supported by the VM.
+
+### Arithmetic, logic, and comparison operations
+- `+ (x y -> [x+y])`
+- `-` etc ...
+- `*`
+- `/`
+- `%`
+- `<<`
+- `>>`
+- `shra` (arithmetic shift right)
+- `~`
+- `|`
+- `^`
+- `=`
+- `!=`
+- `<`
+- `>`
+- `=<`
+- `>=`
+
+### Function calls
+
+For security reasons the list of functions callable with `call` is predefined.
The supported functions are either existing methods on `SBValue`, or string
formatting operations.
+
+- `call (Object arg0 ... Selector -> retval)`
+
+Method is one of a predefined set of _Selectors_
+- `(Object @summary -> String)`
+- `(Object @type_summary -> String)`
+
+- `(Object @get_num_children -> UInt)`
+- `(Object UInt @get_child_at_index -> Object)`
+- `(Object String @get_child_index -> UInt)`
+- `(Object @get_type -> Type)`
+- `(Object UInt @get_template_argument_type -> Type)`
+- `(Object @get_value -> Object)`
+- `(Object @get_value_as_unsigned -> UInt)`
+- `(Object @get_value_as_signed -> Int)`
+- `(Object @get_value_as_address -> UInt)`
+- `(Object Type @cast -> Object)`
+
+- `(UInt @read_memory_byte -> UInt)`
+- `(UInt @read_memory_uint32 -> UInt)`
+- `(UInt @read_memory_int32 -> Int)`
+- `(UInt @read_memory_unsigned -> UInt)`
+- `(UInt @read_memory_signed -> Int)`
+- `(UInt @read_memory_address -> UInt)`
+- `(UInt Type @read_memory -> Object)`
+
+- `(String arg0 ... fmt -> String)`
+- `(String arg0 ... sprintf -> String)`
+- `(String strlen -> String)`
+
+## Byte Code
+
+Most instructions are just a single byte opcode. The only exceptions
[Lldb-commits] [lldb] [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to lldb/examples (PR #113398)
@@ -0,0 +1,486 @@
+"""
+Specification, compiler, disassembler, and interpreter
+for LLDB dataformatter bytecode.
+
+See formatter-bytecode.md for more details.
+"""
+from __future__ import annotations
+
+# Types
+type_String = 1
+type_Int = 2
+type_UInt = 3
+type_Object = 4
+type_Type = 5
+
+# Opcodes
+opcode = dict()
+
+
+def define_opcode(n, mnemonic, name):
+globals()["op_" + name] = n
+if mnemonic:
+opcode[mnemonic] = n
+opcode[n] = mnemonic
+
+
+define_opcode(1, "dup", "dup")
+define_opcode(2, "drop", "drop")
+define_opcode(3, "pick", "pick")
+define_opcode(4, "over", "over")
+define_opcode(5, "swap", "swap")
+define_opcode(6, "rot", "rot")
+
+define_opcode(0x10, "{", "begin")
+define_opcode(0x11, "if", "if")
+define_opcode(0x12, "ifelse", "ifelse")
DavidSpickett wrote:
I don't see a `else`, how will these be used? Is it always one of:
```
if condition:
```
Or:
```
if condition:
else:
```
And you make `if`/`else if` chains by doing `ifelse` followed by another
`ifelse`?
https://github.com/llvm/llvm-project/pull/113398
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to lldb/examples (PR #113398)
@@ -0,0 +1,165 @@
+# A bytecode for (LLDB) data formatters
+
+## Background
+
+LLDB provides very rich customization options to display data types (see
https://lldb.llvm.org/use/variable.html ). To use custom data formatters,
developers typically need to edit the global `~/.lldbinit` file to make sure
they are found and loaded. An example for this workflow is the
`llvm/utils/lldbDataFormatters.py` script. Because of the manual configuration
that is involved, this workflow doesn't scale very well. What would be nice is
if developers or library authors could ship ship data formatters with their
code and LLDB automatically finds them.
+
+In Swift we added the `DebugDescription` macro (see
https://www.swift.org/blog/announcing-swift-6/#debugging ) that translates
Swift string interpolation into LLDB summary strings, and puts them into a
`.lldbsummaries` section, where LLDB can find them. This works well for simple
summaries, but doesn't scale to synthetic child providers or summaries that
need to perform some kind of conditional logic or computation. The logical next
step would be to store full Python formatters instead of summary strings, but
Python code is larger and more importantly it is potentially dangerous to just
load an execute untrusted Python code in LLDB.
+
+This document describes a minimal bytecode tailored to running LLDB
formatters. It defines a human-readable assembler representation for the
language, an efficient binary encoding, a virtual machine for evaluating it,
and format for embedding formatters into binary containers.
+
+### Goals
+
+Provide an efficient and secure encoding for data formatters that can be used
as a compilation target from user-friendly representations (such as DIL, Swift
DebugDescription, or NatVis).
+
+### Non-goals
+
+While humans could write the assembler syntax, making it user-friendly is not
a goal.
+
+## Design of the virtual machine
+
+The LLDB formatter virtual machine uses a stack-based bytecode, comparable
with DWARF expressions, but with higher-level data types and functions.
+
+The virtual machine has two stacks, a data and a control stack. The control
stack is kept separate to make it easier to reason about the security aspects
of the VM.
+
+### Data types
+These data types are "host" data types, in LLDB parlance.
+- _String_ (UTF-8)
+- _Int_ (64 bit)
+- _UInt_ (64 bit)
+- _Object_ (Basically an `SBValue`)
+- _Type_ (Basically an `SBType`)
+- _Selector_ (One of the predefine functions)
+
+_Object_ and _Type_ are opaque, they can only be used as a parameters of
`call`.
+
+## Instruction set
+
+### Stack operations
+
+These manipulate the data stack directly.
+
+- `dup (x -> x x)`
+- `drop (x y -> x)`
+- `pick (x ... UInt -> x ... x)`
+- `over (x y -> y)`
+- `swap (x y -> y x)`
+- `rot (x y z -> z x y)`
+
+### Control flow
+
+- `{` pushes a code block address onto the control stack
+- `}` (technically not an opcode) denotes the end of a code block
+- `if` pops a block from the control stack, if the top of the data stack is
nonzero, executes it
+- `ifelse` pops two blocks from the control stack, if the top of the data
stack is nonzero, executes the first, otherwise the second.
DavidSpickett wrote:
How would you do a while loop, or should we not be doing that? Can you branch
backwards?
https://github.com/llvm/llvm-project/pull/113398
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to lldb/examples (PR #113398)
@@ -0,0 +1,486 @@
+"""
+Specification, compiler, disassembler, and interpreter
+for LLDB dataformatter bytecode.
+
+See formatter-bytecode.md for more details.
+"""
+from __future__ import annotations
+
+# Types
+type_String = 1
+type_Int = 2
+type_UInt = 3
+type_Object = 4
+type_Type = 5
+
+# Opcodes
+opcode = dict()
+
+
+def define_opcode(n, mnemonic, name):
+globals()["op_" + name] = n
+if mnemonic:
+opcode[mnemonic] = n
+opcode[n] = mnemonic
+
+
+define_opcode(1, "dup", "dup")
+define_opcode(2, "drop", "drop")
+define_opcode(3, "pick", "pick")
+define_opcode(4, "over", "over")
+define_opcode(5, "swap", "swap")
+define_opcode(6, "rot", "rot")
+
+define_opcode(0x10, "{", "begin")
+define_opcode(0x11, "if", "if")
+define_opcode(0x12, "ifelse", "ifelse")
+
+define_opcode(0x20, None, "lit_uint")
+define_opcode(0x21, None, "lit_int")
+define_opcode(0x22, None, "lit_string")
+define_opcode(0x23, None, "lit_selector")
+
+define_opcode(0x30, "+", "plus")
+define_opcode(0x31, "-", "minus")
+define_opcode(0x32, "*", "mul")
+define_opcode(0x33, "/", "div")
+define_opcode(0x34, "%", "mod")
+define_opcode(0x35, "<<", "shl")
+define_opcode(0x36, ">>", "shr")
+define_opcode(0x37, "shra", "shra")
+
+define_opcode(0x40, "&", "and")
+define_opcode(0x41, "|", "or")
+define_opcode(0x42, "^", "xor")
+define_opcode(0x43, "~", "not")
+
+define_opcode(0x50, "=", "eq")
+define_opcode(0x51, "!=", "neq")
+define_opcode(0x52, "<", "lt")
+define_opcode(0x53, ">", "gt")
+define_opcode(0x54, "=<", "le")
+define_opcode(0x55, ">=", "ge")
DavidSpickett wrote:
Then here I was thinking why not have the spaceship compare `<=>` instead of
all these but we're not optimising for the size of the encoding space here, but
for the size of the compiled program, correct?
So spaceship plus an if to check for the result you want is going to be bigger
than a dedicated opcode for that comparison.
https://github.com/llvm/llvm-project/pull/113398
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb-dap][test] Set disableASLR to False for tests (PR #113593)
https://github.com/Michael137 edited https://github.com/llvm/llvm-project/pull/113593 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to lldb/examples (PR #113398)
@@ -0,0 +1,165 @@
+# A bytecode for (LLDB) data formatters
+
+## Background
+
+LLDB provides very rich customization options to display data types (see
https://lldb.llvm.org/use/variable.html ). To use custom data formatters,
developers typically need to edit the global `~/.lldbinit` file to make sure
they are found and loaded. An example for this workflow is the
`llvm/utils/lldbDataFormatters.py` script. Because of the manual configuration
that is involved, this workflow doesn't scale very well. What would be nice is
if developers or library authors could ship ship data formatters with their
code and LLDB automatically finds them.
+
+In Swift we added the `DebugDescription` macro (see
https://www.swift.org/blog/announcing-swift-6/#debugging ) that translates
Swift string interpolation into LLDB summary strings, and puts them into a
`.lldbsummaries` section, where LLDB can find them. This works well for simple
summaries, but doesn't scale to synthetic child providers or summaries that
need to perform some kind of conditional logic or computation. The logical next
step would be to store full Python formatters instead of summary strings, but
Python code is larger and more importantly it is potentially dangerous to just
load an execute untrusted Python code in LLDB.
+
+This document describes a minimal bytecode tailored to running LLDB
formatters. It defines a human-readable assembler representation for the
language, an efficient binary encoding, a virtual machine for evaluating it,
and format for embedding formatters into binary containers.
+
+### Goals
+
+Provide an efficient and secure encoding for data formatters that can be used
as a compilation target from user-friendly representations (such as DIL, Swift
DebugDescription, or NatVis).
+
+### Non-goals
+
+While humans could write the assembler syntax, making it user-friendly is not
a goal.
+
+## Design of the virtual machine
+
+The LLDB formatter virtual machine uses a stack-based bytecode, comparable
with DWARF expressions, but with higher-level data types and functions.
+
+The virtual machine has two stacks, a data and a control stack. The control
stack is kept separate to make it easier to reason about the security aspects
of the VM.
+
+### Data types
+These data types are "host" data types, in LLDB parlance.
+- _String_ (UTF-8)
+- _Int_ (64 bit)
+- _UInt_ (64 bit)
+- _Object_ (Basically an `SBValue`)
+- _Type_ (Basically an `SBType`)
+- _Selector_ (One of the predefine functions)
+
+_Object_ and _Type_ are opaque, they can only be used as a parameters of
`call`.
+
+## Instruction set
+
+### Stack operations
+
+These manipulate the data stack directly.
+
+- `dup (x -> x x)`
+- `drop (x y -> x)`
+- `pick (x ... UInt -> x ... x)`
+- `over (x y -> y)`
+- `swap (x y -> y x)`
+- `rot (x y z -> z x y)`
+
+### Control flow
+
+- `{` pushes a code block address onto the control stack
+- `}` (technically not an opcode) denotes the end of a code block
+- `if` pops a block from the control stack, if the top of the data stack is
nonzero, executes it
+- `ifelse` pops two blocks from the control stack, if the top of the data
stack is nonzero, executes the first, otherwise the second.
+
+### Literals for basic types
+
+- `123u ( -> UInt)` an unsigned 64-bit host integer.
+- `123 ( -> Int)` a signed 64-bit host integer.
+- `"abc" ( -> String)` a UTF-8 host string.
+- `@strlen ( -> Selector)` one of the predefined functions supported by the VM.
+
+### Arithmetic, logic, and comparison operations
+- `+ (x y -> [x+y])`
+- `-` etc ...
+- `*`
+- `/`
+- `%`
+- `<<`
+- `>>`
+- `shra` (arithmetic shift right)
+- `~`
+- `|`
+- `^`
+- `=`
+- `!=`
+- `<`
+- `>`
+- `=<`
+- `>=`
+
+### Function calls
+
+For security reasons the list of functions callable with `call` is predefined.
The supported functions are either existing methods on `SBValue`, or string
formatting operations.
+
+- `call (Object arg0 ... Selector -> retval)`
+
+Method is one of a predefined set of _Selectors_
+- `(Object @summary -> String)`
+- `(Object @type_summary -> String)`
+
+- `(Object @get_num_children -> UInt)`
+- `(Object UInt @get_child_at_index -> Object)`
+- `(Object String @get_child_index -> UInt)`
+- `(Object @get_type -> Type)`
+- `(Object UInt @get_template_argument_type -> Type)`
+- `(Object @get_value -> Object)`
+- `(Object @get_value_as_unsigned -> UInt)`
+- `(Object @get_value_as_signed -> Int)`
+- `(Object @get_value_as_address -> UInt)`
+- `(Object Type @cast -> Object)`
+
+- `(UInt @read_memory_byte -> UInt)`
+- `(UInt @read_memory_uint32 -> UInt)`
+- `(UInt @read_memory_int32 -> Int)`
+- `(UInt @read_memory_unsigned -> UInt)`
+- `(UInt @read_memory_signed -> Int)`
+- `(UInt @read_memory_address -> UInt)`
+- `(UInt Type @read_memory -> Object)`
+
+- `(String arg0 ... fmt -> String)`
+- `(String arg0 ... sprintf -> String)`
+- `(String strlen -> String)`
+
+## Byte Code
+
+Most instructions are just a single byte opcode. The only exceptions
[Lldb-commits] [lldb] [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to lldb/examples (PR #113398)
DavidSpickett wrote: This is very cool overall. At first the idea of a whole new VM seems like way too much, but I think I'm getting a better sense of the tradeoffs having read through this. https://github.com/llvm/llvm-project/pull/113398 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Move ValueObject into its own library (NFC) (PR #113393)
https://github.com/labath approved this pull request. https://github.com/llvm/llvm-project/pull/113393 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Move ValueObject into its own library (NFC) (PR #113393)
cmtice wrote: > It looks like the CMakeLists.txt for Breakpoint and Command libraries is > missing a dependency on the ValueObject lib (and they do appear to depend on > it). > It looks like the changes to these CMakeLists.txt (and maybe a few others?) are still missing. Or aren't they needed? https://github.com/llvm/llvm-project/pull/113393 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][NFC] Make the target's SectionLoadList private. (PR #113278)
@@ -1140,9 +1140,13 @@ class Target : public
std::enable_shared_from_this,
Address &pointer_addr,
bool force_live_memory = false);
- SectionLoadList &GetSectionLoadList() {
-return m_section_load_history.GetCurrentSectionLoadList();
- }
+ bool HasLoadedSections();
+
+ lldb::addr_t GetSectionLoadAddress(const lldb::SectionSP §ion_sp);
+
+ void ClearSectionLoadList();
clayborg wrote:
`GetSectionLoadAddress(...)` is called all over the place, but
`ClearSectionLoadList()` is called only by `DynamicLoaderMacOS`, but it should
be able to be called by any dynamic loader, so I wouldn't want to limit the
ability to call it. And we can't tie it to a dynamic loader as I could see us
wanting to add a command that would call this function for symbolication
purposes.
https://github.com/llvm/llvm-project/pull/113278
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] 76edf72 - Reland: [lldb] Fix crash missing MSInheritanceAttr with DWARF on Windows (#112928)
Author: Stefan Gränitz
Date: 2024-10-24T13:47:15+02:00
New Revision: 76edf72501cd6f66788c631fada95972a797a4a6
URL:
https://github.com/llvm/llvm-project/commit/76edf72501cd6f66788c631fada95972a797a4a6
DIFF:
https://github.com/llvm/llvm-project/commit/76edf72501cd6f66788c631fada95972a797a4a6.diff
LOG: Reland: [lldb] Fix crash missing MSInheritanceAttr with DWARF on Windows
(#112928)
Member pointers refer to data or function members of a `CXXRecordDecl`,
which require a `MSInheritanceAttr` in order to be complete. Without that
we cannot calculate the size of a member pointer in memory. The attempt
has been causing a crash further down in the clang AST context. In order
to implement the feature, DWARF will need a new attribtue to convey the
information. For the moment, this patch teaches LLDB to handle to
situation and avoid the crash.
Added:
lldb/test/Shell/SymbolFile/DWARF/x86/member-pointers.cpp
Modified:
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
Removed:
diff --git a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
index a57cd8efce8a11..f5063175d6e070 100644
--- a/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ b/lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -2771,6 +2771,9 @@ static bool GetCompleteQualType(clang::ASTContext *ast,
ast, llvm::cast(qual_type)->getModifiedType(),
allow_completion);
+ case clang::Type::MemberPointer:
+return !qual_type.getTypePtr()->isIncompleteType();
+
default:
break;
}
diff --git a/lldb/test/Shell/SymbolFile/DWARF/x86/member-pointers.cpp
b/lldb/test/Shell/SymbolFile/DWARF/x86/member-pointers.cpp
new file mode 100644
index 00..c7bd95774d33f7
--- /dev/null
+++ b/lldb/test/Shell/SymbolFile/DWARF/x86/member-pointers.cpp
@@ -0,0 +1,24 @@
+// REQUIRES: lld
+
+// Itanium ABI:
+// RUN: %clang --target=x86_64-pc-linux -gdwarf -c -o %t_linux.o %s
+// RUN: %lldb -f %t_linux.o -b -o "target variable mp" | FileCheck %s
+//
+// CHECK: (char SI::*) mp = 0x
+
+// Microsoft ABI:
+// RUN: %clang_cl --target=x86_64-windows-msvc -c -gdwarf -o %t_win.obj -- %s
+// RUN: lld-link /out:%t_win.exe %t_win.obj /nodefaultlib /entry:main /debug
+// RUN: %lldb -f %t_win.exe -b -o "target variable mp" | FileCheck
--check-prefix=CHECK-MSVC %s
+//
+// DWARF has no representation of MSInheritanceAttr, so we cannot determine
the size
+// of member-pointers yet. For the moment, make sure we don't crash on such
variables.
+// CHECK-MSVC: error: Unable to determine byte size.
+
+struct SI {
+ char si;
+};
+
+char SI::*mp = &SI::si;
+
+int main() { return 0; }
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Fix crash missing MSInheritanceAttr on CXXRecordDecl with DWARF on Windows (PR #112928)
weliveindetail wrote: I fixed the test and it now passes for me on macOS. Hope the bots are good now. https://github.com/llvm/llvm-project/pull/112928 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Fix pointer to reference type (PR #113596)
https://github.com/jeffreytan81 created
https://github.com/llvm/llvm-project/pull/113596
We have got customer reporting "v &obj" and "p &obj" reporting different
results.
Turns out it only happens for obj that is itself a reference type which "v
&obj" reports the address of the reference itself instead of the target object
the reference points to. This diverged from C++ semantics.
This PR fixes this issue by returning the address of the dereferenced object if
it is reference type.
A new test is added which fails before.
>From 5e84fcf4d1e6efcba5072d4aafd1151652e85339 Mon Sep 17 00:00:00 2001
From: jeffreytan81
Date: Thu, 24 Oct 2024 10:42:18 -0700
Subject: [PATCH] Fix pointer to reference type
---
lldb/source/Core/ValueObject.cpp | 10 +
.../TestCPPDereferencingReferences.py | 21 +++
.../cpp/dereferencing_references/main.cpp | 2 ++
3 files changed, 33 insertions(+)
diff --git a/lldb/source/Core/ValueObject.cpp b/lldb/source/Core/ValueObject.cpp
index 5b1c171c01f2db..df0393213343fa 100644
--- a/lldb/source/Core/ValueObject.cpp
+++ b/lldb/source/Core/ValueObject.cpp
@@ -2911,6 +2911,16 @@ ValueObjectSP ValueObject::AddressOf(Status &error) {
AddressType address_type = eAddressTypeInvalid;
const bool scalar_is_load_address = false;
+
+ // For reference type we need to get the address of the object that
+ // it refers to.
+ ValueObjectSP deref_obj;
+ if (GetCompilerType().IsReferenceType()) {
+deref_obj = Dereference(error);
+if (error.Fail() || !deref_obj)
+ return ValueObjectSP();
+return deref_obj->AddressOf(error);
+ }
addr_t addr = GetAddressOf(scalar_is_load_address, &address_type);
error.Clear();
if (addr != LLDB_INVALID_ADDRESS && address_type != eAddressTypeHost) {
diff --git
a/lldb/test/API/lang/cpp/dereferencing_references/TestCPPDereferencingReferences.py
b/lldb/test/API/lang/cpp/dereferencing_references/TestCPPDereferencingReferences.py
index 938fb1a6edf32c..1374d4e1ec67ab 100644
---
a/lldb/test/API/lang/cpp/dereferencing_references/TestCPPDereferencingReferences.py
+++
b/lldb/test/API/lang/cpp/dereferencing_references/TestCPPDereferencingReferences.py
@@ -25,3 +25,24 @@ def test(self):
# Typedef to a reference should dereference to the underlying type.
td_val = self.expect_var_path("td_to_ref_type", type="td_int_ref")
self.assertEqual(td_val.Dereference().GetType().GetName(), "int")
+
+def test_take_address_of_reference(self):
+"""Tests taking address of lvalue/rvalue references in lldb works
correctly."""
+self.build()
+lldbutil.run_to_source_breakpoint(
+self, "// break here", lldb.SBFileSpec("main.cpp")
+)
+
+plref_val_from_code = self.expect_var_path("pl_ref", type="TTT *")
+plref_val_from_expr_path = self.expect_var_path("&l_ref", type="TTT *")
+self.assertEqual(
+plref_val_from_code.GetValueAsAddress(),
+plref_val_from_expr_path.GetValueAsAddress(),
+)
+
+prref_val_from_code = self.expect_var_path("pr_ref", type="TTT *")
+prref_val_from_expr_path = self.expect_var_path("&r_ref", type="TTT *")
+self.assertEqual(
+prref_val_from_code.GetValueAsAddress(),
+prref_val_from_expr_path.GetValueAsAddress(),
+)
diff --git a/lldb/test/API/lang/cpp/dereferencing_references/main.cpp
b/lldb/test/API/lang/cpp/dereferencing_references/main.cpp
index b64978a9029f81..4ddffd167ddeed 100644
--- a/lldb/test/API/lang/cpp/dereferencing_references/main.cpp
+++ b/lldb/test/API/lang/cpp/dereferencing_references/main.cpp
@@ -9,5 +9,7 @@ int main() {
// typedef of a reference
td_int_ref td_to_ref_type = i;
+ TTT *pl_ref = &l_ref;
+ TTT *pr_ref = &r_ref;
return l_ref; // break here
}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Fix pointer to reference type (PR #113596)
https://github.com/jeffreytan81 ready_for_review https://github.com/llvm/llvm-project/pull/113596 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Fix pointer to reference type (PR #113596)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: None (jeffreytan81)
Changes
We have got customer reporting "v &obj" and "p &obj" reporting
different results.
Turns out it only happens for obj that is itself a reference type which "v
&obj" reports the address of the reference itself instead of the target
object the reference points to. This diverged from C++ semantics.
This PR fixes this issue by returning the address of the dereferenced object if
it is reference type.
A new test is added which fails before.
---
Full diff: https://github.com/llvm/llvm-project/pull/113596.diff
3 Files Affected:
- (modified) lldb/source/Core/ValueObject.cpp (+10)
- (modified)
lldb/test/API/lang/cpp/dereferencing_references/TestCPPDereferencingReferences.py
(+21)
- (modified) lldb/test/API/lang/cpp/dereferencing_references/main.cpp (+2)
``diff
diff --git a/lldb/source/Core/ValueObject.cpp b/lldb/source/Core/ValueObject.cpp
index 5b1c171c01f2db..df0393213343fa 100644
--- a/lldb/source/Core/ValueObject.cpp
+++ b/lldb/source/Core/ValueObject.cpp
@@ -2911,6 +2911,16 @@ ValueObjectSP ValueObject::AddressOf(Status &error) {
AddressType address_type = eAddressTypeInvalid;
const bool scalar_is_load_address = false;
+
+ // For reference type we need to get the address of the object that
+ // it refers to.
+ ValueObjectSP deref_obj;
+ if (GetCompilerType().IsReferenceType()) {
+deref_obj = Dereference(error);
+if (error.Fail() || !deref_obj)
+ return ValueObjectSP();
+return deref_obj->AddressOf(error);
+ }
addr_t addr = GetAddressOf(scalar_is_load_address, &address_type);
error.Clear();
if (addr != LLDB_INVALID_ADDRESS && address_type != eAddressTypeHost) {
diff --git
a/lldb/test/API/lang/cpp/dereferencing_references/TestCPPDereferencingReferences.py
b/lldb/test/API/lang/cpp/dereferencing_references/TestCPPDereferencingReferences.py
index 938fb1a6edf32c..1374d4e1ec67ab 100644
---
a/lldb/test/API/lang/cpp/dereferencing_references/TestCPPDereferencingReferences.py
+++
b/lldb/test/API/lang/cpp/dereferencing_references/TestCPPDereferencingReferences.py
@@ -25,3 +25,24 @@ def test(self):
# Typedef to a reference should dereference to the underlying type.
td_val = self.expect_var_path("td_to_ref_type", type="td_int_ref")
self.assertEqual(td_val.Dereference().GetType().GetName(), "int")
+
+def test_take_address_of_reference(self):
+"""Tests taking address of lvalue/rvalue references in lldb works
correctly."""
+self.build()
+lldbutil.run_to_source_breakpoint(
+self, "// break here", lldb.SBFileSpec("main.cpp")
+)
+
+plref_val_from_code = self.expect_var_path("pl_ref", type="TTT *")
+plref_val_from_expr_path = self.expect_var_path("&l_ref", type="TTT *")
+self.assertEqual(
+plref_val_from_code.GetValueAsAddress(),
+plref_val_from_expr_path.GetValueAsAddress(),
+)
+
+prref_val_from_code = self.expect_var_path("pr_ref", type="TTT *")
+prref_val_from_expr_path = self.expect_var_path("&r_ref", type="TTT *")
+self.assertEqual(
+prref_val_from_code.GetValueAsAddress(),
+prref_val_from_expr_path.GetValueAsAddress(),
+)
diff --git a/lldb/test/API/lang/cpp/dereferencing_references/main.cpp
b/lldb/test/API/lang/cpp/dereferencing_references/main.cpp
index b64978a9029f81..4ddffd167ddeed 100644
--- a/lldb/test/API/lang/cpp/dereferencing_references/main.cpp
+++ b/lldb/test/API/lang/cpp/dereferencing_references/main.cpp
@@ -9,5 +9,7 @@ int main() {
// typedef of a reference
td_int_ref td_to_ref_type = i;
+ TTT *pl_ref = &l_ref;
+ TTT *pr_ref = &r_ref;
return l_ref; // break here
}
``
https://github.com/llvm/llvm-project/pull/113596
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] Push down cpython module to the submodule (PR #113066)
dingxiangfei2009 wrote: Thank you for your review @JDevlieghere. I think there is still issue with this patch. Until I sort out the root cause, I will close this PR first to reduce review load. Have a nice day! https://github.com/llvm/llvm-project/pull/113066 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Extend FindTypes to optionally search by mangled type name (PR #113007)
Michael137 wrote: Yea using the new `TypeQuery` option in `lldb-test` seems doable. Whether `obj2yaml`/`yaml2obj` supports `.debug_names`, i'm not sure, haven't tried https://github.com/llvm/llvm-project/pull/113007 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Lookup static const members in FindGlobalVariables (PR #111859)
https://github.com/kuilpd updated
https://github.com/llvm/llvm-project/pull/111859
>From 4c394ec162b58b3cde3af924a5e9be1de8250a07 Mon Sep 17 00:00:00 2001
From: Ilia Kuklin
Date: Tue, 30 Jul 2024 17:02:10 +0500
Subject: [PATCH 1/2] [lldb] Lookup static const members in FindGlobalVariables
Static const members initialized inside a class definition might not have a
corresponding DW_TAG_variable (DWARF 4 and earlier), so they're not indexed by
ManualDWARFIndex.
Add an additional lookup in FindGlobalVariables. Try looking up the enclosing
type (e.g. foo::bar for foo::bar::A) and then searching for a static const
member (A) within this type.
---
.../SymbolFile/DWARF/SymbolFileDWARF.cpp | 130 ++
.../SymbolFile/DWARF/SymbolFileDWARF.h| 3 +
.../API/python_api/frame/globals/Makefile | 4 +
.../frame/globals/TestTargetGlobals.py| 43 ++
.../API/python_api/frame/globals/main.cpp | 12 ++
5 files changed, 192 insertions(+)
create mode 100644 lldb/test/API/python_api/frame/globals/Makefile
create mode 100644 lldb/test/API/python_api/frame/globals/TestTargetGlobals.py
create mode 100644 lldb/test/API/python_api/frame/globals/main.cpp
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
index 9287d4baf19e9c..d53da79c1efcee 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -2439,6 +2439,48 @@ void SymbolFileDWARF::FindGlobalVariables(
return variables.GetSize() - original_size < max_matches;
});
+ // If we don't have enough matches and the variable context is not empty, try
+ // to resolve the context as a type and look for static const members.
+ if (variables.GetSize() - original_size < max_matches && !context.empty()) {
+llvm::StringRef type_name;
+if (std::optional parsed_name =
+Type::GetTypeScopeAndBasename(context))
+ type_name = parsed_name->basename;
+else
+ type_name = context;
+
+m_index->GetTypes(ConstString(type_name), [&](DWARFDIE parent) {
+ llvm::StringRef parent_type_name = parent.GetDWARFDeclContext()
+ .GetQualifiedNameAsConstString()
+ .GetStringRef();
+
+ // This type is from another scope, skip it.
+ if (!parent_type_name.ends_with(context))
+return true;
+
+ auto *dwarf_cu = llvm::dyn_cast(parent.GetCU());
+ if (!dwarf_cu)
+return true;
+
+ sc.comp_unit = GetCompUnitForDWARFCompUnit(*dwarf_cu);
+
+ for (DWARFDIE die = parent.GetFirstChild(); die.IsValid();
+ die = die.GetSibling()) {
+// Try parsing the entry as a static const member.
+if (auto var_sp = ParseStaticConstMemberDIE(sc, die)) {
+ if (var_sp->GetUnqualifiedName().GetStringRef() != basename)
+continue;
+
+ // There can be only one member with a given name.
+ variables.AddVariableIfUnique(var_sp);
+ break;
+}
+ }
+
+ return variables.GetSize() - original_size < max_matches;
+});
+ }
+
// Return the number of variable that were appended to the list
const uint32_t num_matches = variables.GetSize() - original_size;
if (log && num_matches > 0) {
@@ -3371,6 +3413,94 @@ size_t SymbolFileDWARF::ParseVariablesForContext(const
SymbolContext &sc) {
return 0;
}
+VariableSP SymbolFileDWARF::ParseStaticConstMemberDIE(
+const lldb_private::SymbolContext &sc, const DWARFDIE &die) {
+ if (die.GetDWARF() != this)
+return die.GetDWARF()->ParseStaticConstMemberDIE(sc, die);
+
+ // Look only for members, ignore all other types of entries.
+ if (die.Tag() != DW_TAG_member)
+return nullptr;
+
+ if (VariableSP var_sp = GetDIEToVariable()[die.GetDIE()])
+return var_sp; // Already been parsed!
+
+ const char *name = nullptr;
+ const char *mangled = nullptr;
+ Declaration decl;
+ DWARFExpression location;
+ DWARFFormValue type_die_form;
+ DWARFFormValue const_value_form;
+
+ DWARFAttributes attributes = die.GetAttributes();
+ const size_t num_attributes = attributes.Size();
+
+ for (size_t i = 0; i < num_attributes; ++i) {
+dw_attr_t attr = attributes.AttributeAtIndex(i);
+DWARFFormValue form_value;
+
+if (!attributes.ExtractFormValueAtIndex(i, form_value))
+ continue;
+
+switch (attr) {
+case DW_AT_decl_file:
+ decl.SetFile(sc.comp_unit->GetSupportFiles().GetFileSpecAtIndex(
+ form_value.Unsigned()));
+ break;
+case DW_AT_decl_line:
+ decl.SetLine(form_value.Unsigned());
+ break;
+case DW_AT_decl_column:
+ decl.SetColumn(form_value.Unsigned());
+ break;
+case DW_AT_name:
+ name = form_value.AsCString();
+ break;
+case DW_AT_type:
+ type_die_form = form_value;
+ break;
+case DW_AT_const_value:
+ const_
[Lldb-commits] [lldb] [lldb] Lookup static const members in FindGlobalVariables (PR #111859)
kuilpd wrote: > It might actually be better to fix this problem during indexing, in the > ManualDWARFIndex -- basically, if we're indexing a v4 unit _and_ we run into > a static const(expr?) variable (can we detect that reliably by looking at the > DIE alone?), then we add it to the index, just as if it was a v5 > DW_TAG_variable. Implemented this as best as I could understand from the DWARF specs, but not sure if there are some cases where the checks I made can be false positive. > Could we re-use `TestConstStaticIntegralMember.py`? Surprised it doesn't > already have the tests added here XFAILed Thank you, I expanded this test instead of making a new one. https://github.com/llvm/llvm-project/pull/111859 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Move ValueObject into its own library (NFC) (PR #113393)
https://github.com/JDevlieghere closed https://github.com/llvm/llvm-project/pull/113393 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Remove SymbolFilePDB and make the native one the default (PR #113647)
llvmbot wrote: @llvm/pr-subscribers-lldb Author: Jonas Devlieghere (JDevlieghere) Changes Remove `SymbolFilePDB` in favor of always using `SymbolFileNativePDB`. This effectively makes `LLDB_USE_NATIVE_PDB_READER` the default. The non-native (DIA based) PDB symbol file implementation was unmaintained and known to have issues. --- Patch is 212.52 KiB, truncated to 20.00 KiB below, full version: https://github.com/llvm/llvm-project/pull/113647.diff 66 Files Affected: - (modified) lldb/source/Plugins/SymbolFile/CMakeLists.txt (-1) - (removed) lldb/source/Plugins/SymbolFile/PDB/CMakeLists.txt (-18) - (removed) lldb/source/Plugins/SymbolFile/PDB/PDBASTParser.cpp (-1455) - (removed) lldb/source/Plugins/SymbolFile/PDB/PDBASTParser.h (-116) - (removed) lldb/source/Plugins/SymbolFile/PDB/PDBLocationToDWARFExpression.cpp (-182) - (removed) lldb/source/Plugins/SymbolFile/PDB/PDBLocationToDWARFExpression.h (-47) - (removed) lldb/source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp (-2053) - (removed) lldb/source/Plugins/SymbolFile/PDB/SymbolFilePDB.h (-252) - (modified) lldb/source/Plugins/TypeSystem/Clang/CMakeLists.txt (+1-1) - (modified) lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp (-9) - (modified) lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h (-3) - (modified) lldb/test/Shell/Minidump/Windows/Sigsegv/sigsegv.test (+1-1) - (modified) lldb/test/Shell/Process/Windows/exception_access_violation.cpp (+2-2) - (modified) lldb/test/Shell/Process/Windows/process_load.cpp (+1-1) - (modified) lldb/test/Shell/SymbolFile/NativePDB/ast-functions-msvc.cpp (+1-1) - (modified) lldb/test/Shell/SymbolFile/NativePDB/ast-functions.cpp (+1-1) - (modified) lldb/test/Shell/SymbolFile/NativePDB/ast-methods.cpp (+2-2) - (modified) lldb/test/Shell/SymbolFile/NativePDB/ast-types.cpp (+1-1) - (modified) lldb/test/Shell/SymbolFile/NativePDB/bitfields.cpp (+1-1) - (modified) lldb/test/Shell/SymbolFile/NativePDB/blocks.s (+1-1) - (modified) lldb/test/Shell/SymbolFile/NativePDB/break-by-function.cpp (+1-1) - (modified) lldb/test/Shell/SymbolFile/NativePDB/break-by-line.cpp (+1-1) - (modified) lldb/test/Shell/SymbolFile/NativePDB/class_layout.cpp (+1-1) - (modified) lldb/test/Shell/SymbolFile/NativePDB/disassembly.cpp (+1-1) - (modified) lldb/test/Shell/SymbolFile/NativePDB/function-types-builtins.cpp (+1-1) - (modified) lldb/test/Shell/SymbolFile/NativePDB/function-types-calling-conv.cpp (+1-1) - (modified) lldb/test/Shell/SymbolFile/NativePDB/function-types-classes.cpp (+1-1) - (modified) lldb/test/Shell/SymbolFile/NativePDB/global-classes.cpp (+1-1) - (modified) lldb/test/Shell/SymbolFile/NativePDB/global-ctor-dtor.cpp (+1-1) - (modified) lldb/test/Shell/SymbolFile/NativePDB/globals-bss.cpp (+1-1) - (modified) lldb/test/Shell/SymbolFile/NativePDB/globals-fundamental.cpp (+1-1) - (modified) lldb/test/Shell/SymbolFile/NativePDB/icf.cpp (+1-1) - (modified) lldb/test/Shell/SymbolFile/NativePDB/incomplete-tag-type.cpp (+1-1) - (modified) lldb/test/Shell/SymbolFile/NativePDB/inline_sites.test (+1-1) - (modified) lldb/test/Shell/SymbolFile/NativePDB/inline_sites_live.cpp (+1-1) - (modified) lldb/test/Shell/SymbolFile/NativePDB/load-pdb.cpp (+1-1) - (modified) lldb/test/Shell/SymbolFile/NativePDB/local-variables-registers.s (+1-1) - (modified) lldb/test/Shell/SymbolFile/NativePDB/local-variables.cpp (+1-1) - (modified) lldb/test/Shell/SymbolFile/NativePDB/locate-pdb.cpp (+2-2) - (modified) lldb/test/Shell/SymbolFile/NativePDB/lookup-by-address.cpp (+1-1) - (modified) lldb/test/Shell/SymbolFile/NativePDB/lookup-by-types.cpp (+1-1) - (modified) lldb/test/Shell/SymbolFile/NativePDB/nested-blocks-same-address.s (+1-1) - (modified) lldb/test/Shell/SymbolFile/NativePDB/nested-types.cpp (+1-1) - (modified) lldb/test/Shell/SymbolFile/NativePDB/s_constant.cpp (+1-1) - (modified) lldb/test/Shell/SymbolFile/NativePDB/source-list.cpp (+1-1) - (modified) lldb/test/Shell/SymbolFile/NativePDB/stack_unwinding01.cpp (+1-1) - (modified) lldb/test/Shell/SymbolFile/NativePDB/tag-types.cpp (+1-1) - (modified) lldb/test/Shell/SymbolFile/NativePDB/typedefs.cpp (+1-1) - (modified) lldb/test/Shell/SymbolFile/PDB/ast-restore.test (+2-4) - (modified) lldb/test/Shell/SymbolFile/PDB/compilands.test (+1-2) - (modified) lldb/test/Shell/SymbolFile/PDB/function-level-linking.test (+1-2) - (modified) lldb/test/Shell/SymbolFile/PDB/variables-locations.test (+1-2) - (modified) lldb/unittests/SymbolFile/CMakeLists.txt (-3) - (modified) lldb/unittests/SymbolFile/DWARF/CMakeLists.txt (-1) - (modified) lldb/unittests/SymbolFile/DWARF/SymbolFileDWARFTests.cpp (+1-4) - (removed) lldb/unittests/SymbolFile/PDB/CMakeLists.txt (-25) - (removed) lldb/unittests/SymbolFile/PDB/Inputs/test-pdb-alt.cpp (-7) - (removed) lldb/unittests/SymbolFile/PDB/Inputs/test-pdb-nested.h (-6) - (removed) lldb/unittests/SymbolFile/PDB/Inputs/test-pdb-types.cpp (-77) - (removed) lldb/unittests/SymbolFile/PDB/Inputs/t
[Lldb-commits] [lldb] 25909b8 - Fix pointer to reference type (#113596)
Author: jeffreytan81
Date: 2024-10-24T17:13:32-07:00
New Revision: 25909b811a7ddc983d042b15cb54ec271a673d63
URL:
https://github.com/llvm/llvm-project/commit/25909b811a7ddc983d042b15cb54ec271a673d63
DIFF:
https://github.com/llvm/llvm-project/commit/25909b811a7ddc983d042b15cb54ec271a673d63.diff
LOG: Fix pointer to reference type (#113596)
We have got customer reporting "v &obj" and "p &obj" reporting different
results.
Turns out it only happens for obj that is itself a reference type which
"v &obj" reports the address of the reference itself instead of the
target object the reference points to. This diverged from C++ semantics.
This PR fixes this issue by returning the address of the dereferenced
object if it is reference type.
A new test is added which fails before.
Co-authored-by: jeffreytan81
Added:
Modified:
lldb/source/Core/ValueObject.cpp
lldb/test/API/lang/cpp/dereferencing_references/TestCPPDereferencingReferences.py
lldb/test/API/lang/cpp/dereferencing_references/main.cpp
Removed:
diff --git a/lldb/source/Core/ValueObject.cpp
b/lldb/source/Core/ValueObject.cpp
index 5b1c171c01f2db..5e3839b89ce0ec 100644
--- a/lldb/source/Core/ValueObject.cpp
+++ b/lldb/source/Core/ValueObject.cpp
@@ -2911,6 +2911,15 @@ ValueObjectSP ValueObject::AddressOf(Status &error) {
AddressType address_type = eAddressTypeInvalid;
const bool scalar_is_load_address = false;
+
+ // For reference type we need to get the address of the object that
+ // it refers to.
+ if (GetCompilerType().IsReferenceType()) {
+ValueObjectSP deref_obj = Dereference(error);
+if (error.Fail() || !deref_obj)
+ return ValueObjectSP();
+return deref_obj->AddressOf(error);
+ }
addr_t addr = GetAddressOf(scalar_is_load_address, &address_type);
error.Clear();
if (addr != LLDB_INVALID_ADDRESS && address_type != eAddressTypeHost) {
diff --git
a/lldb/test/API/lang/cpp/dereferencing_references/TestCPPDereferencingReferences.py
b/lldb/test/API/lang/cpp/dereferencing_references/TestCPPDereferencingReferences.py
index 938fb1a6edf32c..1374d4e1ec67ab 100644
---
a/lldb/test/API/lang/cpp/dereferencing_references/TestCPPDereferencingReferences.py
+++
b/lldb/test/API/lang/cpp/dereferencing_references/TestCPPDereferencingReferences.py
@@ -25,3 +25,24 @@ def test(self):
# Typedef to a reference should dereference to the underlying type.
td_val = self.expect_var_path("td_to_ref_type", type="td_int_ref")
self.assertEqual(td_val.Dereference().GetType().GetName(), "int")
+
+def test_take_address_of_reference(self):
+"""Tests taking address of lvalue/rvalue references in lldb works
correctly."""
+self.build()
+lldbutil.run_to_source_breakpoint(
+self, "// break here", lldb.SBFileSpec("main.cpp")
+)
+
+plref_val_from_code = self.expect_var_path("pl_ref", type="TTT *")
+plref_val_from_expr_path = self.expect_var_path("&l_ref", type="TTT *")
+self.assertEqual(
+plref_val_from_code.GetValueAsAddress(),
+plref_val_from_expr_path.GetValueAsAddress(),
+)
+
+prref_val_from_code = self.expect_var_path("pr_ref", type="TTT *")
+prref_val_from_expr_path = self.expect_var_path("&r_ref", type="TTT *")
+self.assertEqual(
+prref_val_from_code.GetValueAsAddress(),
+prref_val_from_expr_path.GetValueAsAddress(),
+)
diff --git a/lldb/test/API/lang/cpp/dereferencing_references/main.cpp
b/lldb/test/API/lang/cpp/dereferencing_references/main.cpp
index b64978a9029f81..4ddffd167ddeed 100644
--- a/lldb/test/API/lang/cpp/dereferencing_references/main.cpp
+++ b/lldb/test/API/lang/cpp/dereferencing_references/main.cpp
@@ -9,5 +9,7 @@ int main() {
// typedef of a reference
td_int_ref td_to_ref_type = i;
+ TTT *pl_ref = &l_ref;
+ TTT *pr_ref = &r_ref;
return l_ref; // break here
}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][NFC] Make the target's SectionLoadList private. (PR #113278)
@@ -1140,9 +1140,13 @@ class Target : public
std::enable_shared_from_this,
Address &pointer_addr,
bool force_live_memory = false);
- SectionLoadList &GetSectionLoadList() {
-return m_section_load_history.GetCurrentSectionLoadList();
- }
+ bool HasLoadedSections();
+
+ lldb::addr_t GetSectionLoadAddress(const lldb::SectionSP §ion_sp);
+
+ void ClearSectionLoadList();
jimingham wrote:
Okay.
https://github.com/llvm/llvm-project/pull/113278
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Finish implementing support for DW_FORM_data16 (PR #113508)
jasonmolenda wrote: Looks good to me, but Adrian might want a look. https://github.com/llvm/llvm-project/pull/113508 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Remove SymbolFilePDB and make the native one the default (PR #113647)
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff a31ce36f568723ffa5b4155d0ba009403ccd0d9e
c11f8f87156e630f9fed1e5bc615217353bba56d --extensions h,cpp --
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.h
lldb/test/Shell/Process/Windows/exception_access_violation.cpp
lldb/test/Shell/Process/Windows/process_load.cpp
lldb/test/Shell/SymbolFile/NativePDB/ast-functions-msvc.cpp
lldb/test/Shell/SymbolFile/NativePDB/ast-functions.cpp
lldb/test/Shell/SymbolFile/NativePDB/ast-methods.cpp
lldb/test/Shell/SymbolFile/NativePDB/ast-types.cpp
lldb/test/Shell/SymbolFile/NativePDB/bitfields.cpp
lldb/test/Shell/SymbolFile/NativePDB/break-by-function.cpp
lldb/test/Shell/SymbolFile/NativePDB/break-by-line.cpp
lldb/test/Shell/SymbolFile/NativePDB/class_layout.cpp
lldb/test/Shell/SymbolFile/NativePDB/disassembly.cpp
lldb/test/Shell/SymbolFile/NativePDB/function-types-builtins.cpp
lldb/test/Shell/SymbolFile/NativePDB/function-types-calling-conv.cpp
lldb/test/Shell/SymbolFile/NativePDB/function-types-classes.cpp
lldb/test/Shell/SymbolFile/NativePDB/global-classes.cpp
lldb/test/Shell/SymbolFile/NativePDB/global-ctor-dtor.cpp
lldb/test/Shell/SymbolFile/NativePDB/globals-bss.cpp
lldb/test/Shell/SymbolFile/NativePDB/globals-fundamental.cpp
lldb/test/Shell/SymbolFile/NativePDB/icf.cpp
lldb/test/Shell/SymbolFile/NativePDB/incomplete-tag-type.cpp
lldb/test/Shell/SymbolFile/NativePDB/inline_sites_live.cpp
lldb/test/Shell/SymbolFile/NativePDB/load-pdb.cpp
lldb/test/Shell/SymbolFile/NativePDB/local-variables.cpp
lldb/test/Shell/SymbolFile/NativePDB/locate-pdb.cpp
lldb/test/Shell/SymbolFile/NativePDB/lookup-by-address.cpp
lldb/test/Shell/SymbolFile/NativePDB/lookup-by-types.cpp
lldb/test/Shell/SymbolFile/NativePDB/nested-types.cpp
lldb/test/Shell/SymbolFile/NativePDB/s_constant.cpp
lldb/test/Shell/SymbolFile/NativePDB/source-list.cpp
lldb/test/Shell/SymbolFile/NativePDB/stack_unwinding01.cpp
lldb/test/Shell/SymbolFile/NativePDB/tag-types.cpp
lldb/test/Shell/SymbolFile/NativePDB/typedefs.cpp
lldb/unittests/SymbolFile/DWARF/SymbolFileDWARFTests.cpp
lldb/test/Shell/SymbolFile/NativePDB/Inputs/AstRestoreTest.cpp
lldb/test/Shell/SymbolFile/NativePDB/Inputs/CallingConventionsTest.cpp
lldb/test/Shell/SymbolFile/NativePDB/Inputs/ClassLayoutTest.cpp
lldb/test/Shell/SymbolFile/NativePDB/Inputs/CompilandsTest.cpp
lldb/test/Shell/SymbolFile/NativePDB/Inputs/ExpressionsTest.cpp
lldb/test/Shell/SymbolFile/NativePDB/Inputs/FuncSymbols.cpp
lldb/test/Shell/SymbolFile/NativePDB/Inputs/FuncSymbolsTestMain.cpp
lldb/test/Shell/SymbolFile/NativePDB/Inputs/FunctionLevelLinkingTest.cpp
lldb/test/Shell/SymbolFile/NativePDB/Inputs/FunctionLevelLinkingTest.h
lldb/test/Shell/SymbolFile/NativePDB/Inputs/FunctionNestedBlockTest.cpp
lldb/test/Shell/SymbolFile/NativePDB/Inputs/PointerTypeTest.cpp
lldb/test/Shell/SymbolFile/NativePDB/Inputs/SimpleTypesTest.cpp
lldb/test/Shell/SymbolFile/NativePDB/Inputs/TypeQualsTest.cpp
lldb/test/Shell/SymbolFile/NativePDB/Inputs/UdtLayoutTest.cpp
lldb/test/Shell/SymbolFile/NativePDB/Inputs/VBases.cpp
lldb/test/Shell/SymbolFile/NativePDB/Inputs/VariablesLocationsTest.cpp
lldb/test/Shell/SymbolFile/NativePDB/Inputs/VariablesTest.cpp
``
View the diff from clang-format here.
``diff
diff --git a/lldb/test/Shell/SymbolFile/NativePDB/Inputs/AstRestoreTest.cpp
b/lldb/test/Shell/SymbolFile/NativePDB/Inputs/AstRestoreTest.cpp
index fb20c9d734..05a4d872b0 100644
--- a/lldb/test/Shell/SymbolFile/NativePDB/Inputs/AstRestoreTest.cpp
+++ b/lldb/test/Shell/SymbolFile/NativePDB/Inputs/AstRestoreTest.cpp
@@ -4,7 +4,7 @@ namespace N1 {
namespace {
enum Enum { Enum_0 = 1, Enum_1 = 2, Enum_2 = 4, Enum_3 = 8 };
enum class ScopedEnum { Enum_0 = 1, Enum_1 = 2, Enum_2 = 4, Enum_3 = 8 };
-}
+} // namespace
Enum Global = Enum_3;
@@ -16,9 +16,7 @@ class Class : public Base {
public:
Class(Enum e) : m_ce(e) {}
- static int StaticFunc(const Class &c) {
-return c.PrivateFunc(c.m_inner) + Global + ClassStatic;
- }
+ static int StaticFunc(const Class &c) { return c.PrivateFunc(c.m_inner) +
Global + ClassStatic; }
const Enum m_ce;
@@ -44,12 +42,8 @@ private:
};
int Class::ClassStatic = 7;
-template
-struct Template {
- template
- void TemplateFunc() {
-T::StaticFunc(T(E));
- }
+template struct Template {
+ template void TemplateFunc() { T::StaticFunc(T(E)); }
};
void foo() { Template().TemplateFunc(); }
diff --git
a/lldb/test/Shell/SymbolFile/NativePDB/Inputs/CallingConventionsTest.cpp
b/lldb/test/Shell/SymbolFile/NativePDB/Inputs/CallingConventionsTest.cpp
index 60854c04c6..26f544b123 100644
--- a/lldb/test/Shell/SymbolFile/NativePDB/Inputs/CallingConventionsTest.cpp
+++ b/lldb/test/Shell/SymbolFile/NativePDB/Inputs/CallingC
[Lldb-commits] [lldb] [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to lldb/examples (PR #113398)
@@ -0,0 +1,165 @@
+# A bytecode for (LLDB) data formatters
+
+## Background
+
+LLDB provides very rich customization options to display data types (see
https://lldb.llvm.org/use/variable.html ). To use custom data formatters,
developers typically need to edit the global `~/.lldbinit` file to make sure
they are found and loaded. An example for this workflow is the
`llvm/utils/lldbDataFormatters.py` script. Because of the manual configuration
that is involved, this workflow doesn't scale very well. What would be nice is
if developers or library authors could ship ship data formatters with their
code and LLDB automatically finds them.
+
+In Swift we added the `DebugDescription` macro (see
https://www.swift.org/blog/announcing-swift-6/#debugging ) that translates
Swift string interpolation into LLDB summary strings, and puts them into a
`.lldbsummaries` section, where LLDB can find them. This works well for simple
summaries, but doesn't scale to synthetic child providers or summaries that
need to perform some kind of conditional logic or computation. The logical next
step would be to store full Python formatters instead of summary strings, but
Python code is larger and more importantly it is potentially dangerous to just
load an execute untrusted Python code in LLDB.
+
+This document describes a minimal bytecode tailored to running LLDB
formatters. It defines a human-readable assembler representation for the
language, an efficient binary encoding, a virtual machine for evaluating it,
and format for embedding formatters into binary containers.
+
+### Goals
+
+Provide an efficient and secure encoding for data formatters that can be used
as a compilation target from user-friendly representations (such as DIL, Swift
DebugDescription, or NatVis).
+
+### Non-goals
+
+While humans could write the assembler syntax, making it user-friendly is not
a goal.
+
+## Design of the virtual machine
+
+The LLDB formatter virtual machine uses a stack-based bytecode, comparable
with DWARF expressions, but with higher-level data types and functions.
+
+The virtual machine has two stacks, a data and a control stack. The control
stack is kept separate to make it easier to reason about the security aspects
of the VM.
+
+### Data types
+These data types are "host" data types, in LLDB parlance.
+- _String_ (UTF-8)
+- _Int_ (64 bit)
+- _UInt_ (64 bit)
+- _Object_ (Basically an `SBValue`)
+- _Type_ (Basically an `SBType`)
+- _Selector_ (One of the predefine functions)
+
+_Object_ and _Type_ are opaque, they can only be used as a parameters of
`call`.
+
+## Instruction set
+
+### Stack operations
+
+These manipulate the data stack directly.
+
+- `dup (x -> x x)`
+- `drop (x y -> x)`
+- `pick (x ... UInt -> x ... x)`
+- `over (x y -> y)`
+- `swap (x y -> y x)`
+- `rot (x y z -> z x y)`
+
+### Control flow
+
+- `{` pushes a code block address onto the control stack
+- `}` (technically not an opcode) denotes the end of a code block
+- `if` pops a block from the control stack, if the top of the data stack is
nonzero, executes it
+- `ifelse` pops two blocks from the control stack, if the top of the data
stack is nonzero, executes the first, otherwise the second.
+
+### Literals for basic types
+
+- `123u ( -> UInt)` an unsigned 64-bit host integer.
+- `123 ( -> Int)` a signed 64-bit host integer.
+- `"abc" ( -> String)` a UTF-8 host string.
+- `@strlen ( -> Selector)` one of the predefined functions supported by the VM.
+
+### Arithmetic, logic, and comparison operations
+- `+ (x y -> [x+y])`
+- `-` etc ...
+- `*`
+- `/`
+- `%`
+- `<<`
+- `>>`
+- `shra` (arithmetic shift right)
+- `~`
+- `|`
+- `^`
+- `=`
+- `!=`
+- `<`
+- `>`
+- `=<`
+- `>=`
+
+### Function calls
+
+For security reasons the list of functions callable with `call` is predefined.
The supported functions are either existing methods on `SBValue`, or string
formatting operations.
+
+- `call (Object arg0 ... Selector -> retval)`
+
+Method is one of a predefined set of _Selectors_
+- `(Object @summary -> String)`
+- `(Object @type_summary -> String)`
+
+- `(Object @get_num_children -> UInt)`
+- `(Object UInt @get_child_at_index -> Object)`
+- `(Object String @get_child_index -> UInt)`
+- `(Object @get_type -> Type)`
+- `(Object UInt @get_template_argument_type -> Type)`
+- `(Object @get_value -> Object)`
+- `(Object @get_value_as_unsigned -> UInt)`
+- `(Object @get_value_as_signed -> Int)`
+- `(Object @get_value_as_address -> UInt)`
+- `(Object Type @cast -> Object)`
+
+- `(UInt @read_memory_byte -> UInt)`
+- `(UInt @read_memory_uint32 -> UInt)`
+- `(UInt @read_memory_int32 -> Int)`
+- `(UInt @read_memory_unsigned -> UInt)`
+- `(UInt @read_memory_signed -> Int)`
+- `(UInt @read_memory_address -> UInt)`
+- `(UInt Type @read_memory -> Object)`
+
+- `(String arg0 ... fmt -> String)`
+- `(String arg0 ... sprintf -> String)`
+- `(String strlen -> String)`
+
+## Byte Code
+
+Most instructions are just a single byte opcode. The only exceptions
[Lldb-commits] [lldb] [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to lldb/examples (PR #113398)
@@ -0,0 +1,486 @@
+"""
+Specification, compiler, disassembler, and interpreter
+for LLDB dataformatter bytecode.
+
+See formatter-bytecode.md for more details.
+"""
+from __future__ import annotations
+
+# Types
+type_String = 1
+type_Int = 2
+type_UInt = 3
+type_Object = 4
+type_Type = 5
+
+# Opcodes
+opcode = dict()
+
+
+def define_opcode(n, mnemonic, name):
+globals()["op_" + name] = n
+if mnemonic:
+opcode[mnemonic] = n
+opcode[n] = mnemonic
+
+
+define_opcode(1, "dup", "dup")
+define_opcode(2, "drop", "drop")
+define_opcode(3, "pick", "pick")
+define_opcode(4, "over", "over")
+define_opcode(5, "swap", "swap")
+define_opcode(6, "rot", "rot")
+
+define_opcode(0x10, "{", "begin")
+define_opcode(0x11, "if", "if")
+define_opcode(0x12, "ifelse", "ifelse")
+
+define_opcode(0x20, None, "lit_uint")
+define_opcode(0x21, None, "lit_int")
+define_opcode(0x22, None, "lit_string")
+define_opcode(0x23, None, "lit_selector")
+
+define_opcode(0x30, "+", "plus")
+define_opcode(0x31, "-", "minus")
+define_opcode(0x32, "*", "mul")
+define_opcode(0x33, "/", "div")
+define_opcode(0x34, "%", "mod")
+define_opcode(0x35, "<<", "shl")
+define_opcode(0x36, ">>", "shr")
+define_opcode(0x37, "shra", "shra")
+
+define_opcode(0x40, "&", "and")
+define_opcode(0x41, "|", "or")
+define_opcode(0x42, "^", "xor")
+define_opcode(0x43, "~", "not")
+
+define_opcode(0x50, "=", "eq")
+define_opcode(0x51, "!=", "neq")
+define_opcode(0x52, "<", "lt")
+define_opcode(0x53, ">", "gt")
+define_opcode(0x54, "=<", "le")
+define_opcode(0x55, ">=", "ge")
+
+define_opcode(0x60, "call", "call")
+
+# Function signatures
+sig_summary = 0
+sig_init = 1
+sig_get_num_children = 2
+sig_get_child_index = 3
+sig_get_child_at_index = 4
+
+# Selectors
+selector = dict()
+
+
+def define_selector(n, name):
+globals()["sel_" + name] = n
+selector["@" + name] = n
+selector[n] = "@" + name
+
+
+define_selector(0, "summary")
+define_selector(1, "type_summary")
+
+define_selector(0x10, "get_num_children")
+define_selector(0x11, "get_child_at_index")
+define_selector(0x12, "get_child_with_name")
+define_selector(0x13, "get_child_index")
+define_selector(0x15, "get_type")
+define_selector(0x16, "get_template_argument_type")
+define_selector(0x20, "get_value")
+define_selector(0x21, "get_value_as_unsigned")
+define_selector(0x22, "get_value_as_signed")
+define_selector(0x23, "get_value_as_address")
+define_selector(0x24, "cast")
+
+define_selector(0x40, "read_memory_byte")
+define_selector(0x41, "read_memory_uint32")
+define_selector(0x42, "read_memory_int32")
+define_selector(0x43, "read_memory_unsigned")
+define_selector(0x44, "read_memory_signed")
+define_selector(0x45, "read_memory_address")
+define_selector(0x46, "read_memory")
+
+define_selector(0x50, "fmt")
+define_selector(0x51, "sprintf")
+define_selector(0x52, "strlen")
+
+
+
+# Compiler.
+
+
+
+def compile(assembler: str) -> bytearray:
+"""Compile assembler into bytecode"""
+# This is a stack of all in-flight/unterminated blocks.
+bytecode = [bytearray()]
+
+def emit(byte):
+bytecode[-1].append(byte)
+
+tokens = list(assembler.split(" "))
+tokens.reverse()
+while tokens:
+tok = tokens.pop()
+if tok == "":
+pass
+elif tok == "{":
+bytecode.append(bytearray())
+elif tok == "}":
+block = bytecode.pop()
+emit(op_begin)
+emit(len(block)) # FIXME: uleb
+bytecode[-1].extend(block)
+elif tok[0].isdigit():
+if tok[-1] == "u":
+emit(op_lit_uint)
+emit(int(tok[:-1])) # FIXME
+else:
+emit(op_lit_int)
+emit(int(tok)) # FIXME
+elif tok[0] == "@":
+emit(op_lit_selector)
+emit(selector[tok])
+elif tok[0] == '"':
+s = bytearray()
+done = False
+chrs = tok[1:]
+while not done:
+quoted = False
+for c in chrs:
+if quoted:
+s.append(ord(c)) # FIXME
+quoted = False
+elif c == "\\":
+quoted = True
+elif c == '"':
+done = True
+break
+# FIXME assert this is last in token
+else:
+s.append(ord(c))
+if not done:
+s.append(ord(" "))
+chrs = tokens.pop()
+
+emit(op_lit_string)
+emit(len(s))
+bytecode[-1].extend(s)
+else:
+emit(opcode[tok])
+assert len(bytecode) == 1 # unterminated {
+return bytecode[0]
+
+
+#
[Lldb-commits] [lldb] [lldb] Remove SymbolFilePDB and make the native one the default (PR #113647)
https://github.com/sstamenova approved this pull request. https://github.com/llvm/llvm-project/pull/113647 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Use LLVM's helper for Unicode conversion (NFC) (PR #112582)
JDevlieghere wrote: @labath FYI this is ready for review. https://github.com/llvm/llvm-project/pull/112582 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Remove SymbolFilePDB and make the native one the default (PR #113647)
@@ -1,11 +1,9 @@ REQUIRES: system-windows, msvc sstamenova wrote: The tests in SymbolFile/PDB should probably move to SymbolFile/NativePDB for consistency https://github.com/llvm/llvm-project/pull/113647 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Move ValueObject into its own library (NFC) (PR #113393)
labath wrote: > Given that most of these files start with 1st ValueObject` I felt like that > was the better name for the library, rather than DIL which doesn't exist yet. > I'm fine with putting the DIL implementation in the new ValueObject library > (potentially in a DIL subdirectory) or keep it in Core like you suggested. Sorry, I didn't mean to imply that the directory should be called DIL -- that would again be too DIL-specific (and vapourware). I was more thinking of a name which was generic enough so it encompasses both. I don't really have a good suggestion, except maybe "Value" (so that you have a *Value*Object and and E-value-ator for it sitting next to each other. That said, now that I've written this, I am starting to think that I'd be fine with an "evaluator" in a directory called "valueobject" as well, so I'm going to stamp this. If you think that "Value" is better, then feel free to rename it to that. Otherwise, this is fine as well. (I've also checked that this builds on linux with the stricter dep checking) https://github.com/llvm/llvm-project/pull/113393 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Add a compiler/interpreter of LLDB data formatter bytecode to lldb/examples (PR #113398)
@@ -0,0 +1,486 @@
+"""
+Specification, compiler, disassembler, and interpreter
+for LLDB dataformatter bytecode.
+
+See formatter-bytecode.md for more details.
+"""
+from __future__ import annotations
+
+# Types
+type_String = 1
+type_Int = 2
+type_UInt = 3
+type_Object = 4
+type_Type = 5
+
+# Opcodes
+opcode = dict()
+
+
+def define_opcode(n, mnemonic, name):
+globals()["op_" + name] = n
+if mnemonic:
+opcode[mnemonic] = n
+opcode[n] = mnemonic
+
+
+define_opcode(1, "dup", "dup")
+define_opcode(2, "drop", "drop")
+define_opcode(3, "pick", "pick")
+define_opcode(4, "over", "over")
+define_opcode(5, "swap", "swap")
+define_opcode(6, "rot", "rot")
+
+define_opcode(0x10, "{", "begin")
+define_opcode(0x11, "if", "if")
+define_opcode(0x12, "ifelse", "ifelse")
+
+define_opcode(0x20, None, "lit_uint")
+define_opcode(0x21, None, "lit_int")
+define_opcode(0x22, None, "lit_string")
+define_opcode(0x23, None, "lit_selector")
+
+define_opcode(0x30, "+", "plus")
+define_opcode(0x31, "-", "minus")
+define_opcode(0x32, "*", "mul")
+define_opcode(0x33, "/", "div")
+define_opcode(0x34, "%", "mod")
+define_opcode(0x35, "<<", "shl")
+define_opcode(0x36, ">>", "shr")
+define_opcode(0x37, "shra", "shra")
+
+define_opcode(0x40, "&", "and")
+define_opcode(0x41, "|", "or")
+define_opcode(0x42, "^", "xor")
+define_opcode(0x43, "~", "not")
+
+define_opcode(0x50, "=", "eq")
+define_opcode(0x51, "!=", "neq")
+define_opcode(0x52, "<", "lt")
+define_opcode(0x53, ">", "gt")
+define_opcode(0x54, "=<", "le")
+define_opcode(0x55, ">=", "ge")
+
+define_opcode(0x60, "call", "call")
+
+# Function signatures
+sig_summary = 0
+sig_init = 1
+sig_get_num_children = 2
+sig_get_child_index = 3
+sig_get_child_at_index = 4
+
+# Selectors
+selector = dict()
DavidSpickett wrote:
But the point of this fixed list is to prevent a security issue if you could
call anything.
Do these selectors run as if their `this` pointer is the ValueObject that
you're currently formatting? So it's a bit like you don't have a global scope,
that global scope is instead the methods of the ValueObject, plus a few
utilities. So your "context", your world view, is just that one ValueObject.
https://github.com/llvm/llvm-project/pull/113398
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Extend FindTypes to optionally search by mangled type name (PR #113007)
@@ -1032,11 +1032,17 @@ void SymbolFileCTF::FindTypes(const
lldb_private::TypeQuery &match,
ConstString name = match.GetTypeBasename();
for (TypeSP type_sp : GetTypeList().Types()) {
-if (type_sp && type_sp->GetName() == name) {
- results.InsertUnique(type_sp);
- if (results.Done(match))
-return;
-}
+if (!type_sp)
+ continue;
+auto type_name =
+match.GetSearchByMangledName()
+? type_sp->GetForwardCompilerType().GetMangledTypeName()
+: type_sp->GetName();
+if (type_name != name)
+ continue;
+results.InsertUnique(type_sp);
+if (results.Done(match))
+ return;
Michael137 wrote:
Also, do we need to implement this for new lookup option for `CTF` and `PDB`?
Given it will probably be always unused (e.g., CTF is only used with `C` IIUC),
maybe lets limit this change to just DWARF for now?
https://github.com/llvm/llvm-project/pull/113007
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add a target.launch-working-dir setting (PR #113521)
https://github.com/walter-erquinigo updated
https://github.com/llvm/llvm-project/pull/113521
>From 4c80e266e53c53393700a3030edfc471137d2fd5 Mon Sep 17 00:00:00 2001
From: walter erquinigo
Date: Thu, 24 Oct 2024 00:17:48 -0400
Subject: [PATCH] [LLDB] Add a target.launch-working-dir setting
Internally we use bazel in a way in which it can drop you in a LLDB session
with the target launched in a particular cwd, which is needed for things to
work. We've been making this automation work via `process launch -w`. However,
if later the user wants to restart the process with `r`, then they end up using
a different cwd for relaunching the process.
As a way to fix this, I'm adding a target-level setting that allows setting a
default cwd used for launching the process without needing the user to specify
it manually.
---
lldb/include/lldb/Target/Target.h | 3 +
lldb/source/Commands/CommandObjectProcess.cpp | 7 ++
lldb/source/Target/Target.cpp | 9 +++
lldb/source/Target/TargetProperties.td| 4 ++
.../process/launch/TestProcessLaunch.py | 68 +++
5 files changed, 91 insertions(+)
diff --git a/lldb/include/lldb/Target/Target.h
b/lldb/include/lldb/Target/Target.h
index e4848f19e64d62..0e8bbb41f29941 100644
--- a/lldb/include/lldb/Target/Target.h
+++ b/lldb/include/lldb/Target/Target.h
@@ -37,6 +37,7 @@
#include "lldb/Utility/RealpathPrefixes.h"
#include "lldb/Utility/Timeout.h"
#include "lldb/lldb-public.h"
+#include "llvm/ADT/StringRef.h"
namespace lldb_private {
@@ -114,6 +115,8 @@ class TargetProperties : public Properties {
void SetDisableSTDIO(bool b);
+ std::optional GetLaunchWorkingDirectory() const;
+
const char *GetDisassemblyFlavor() const;
InlineStrategy GetInlineStrategy() const;
diff --git a/lldb/source/Commands/CommandObjectProcess.cpp
b/lldb/source/Commands/CommandObjectProcess.cpp
index e7c7d07ad47722..b7984c0c1ab860 100644
--- a/lldb/source/Commands/CommandObjectProcess.cpp
+++ b/lldb/source/Commands/CommandObjectProcess.cpp
@@ -201,6 +201,13 @@ class CommandObjectProcessLaunch : public
CommandObjectProcessLaunchOrAttach {
if (target->GetDisableSTDIO())
m_options.launch_info.GetFlags().Set(eLaunchFlagDisableSTDIO);
+if (!m_options.launch_info.GetWorkingDirectory()) {
+ if (std::optional wd =
+ target->GetLaunchWorkingDirectory()) {
+m_options.launch_info.SetWorkingDirectory(FileSpec(*wd));
+ }
+}
+
// Merge the launch info environment with the target environment.
Environment target_env = target->GetEnvironment();
m_options.launch_info.GetEnvironment().insert(target_env.begin(),
diff --git a/lldb/source/Target/Target.cpp b/lldb/source/Target/Target.cpp
index 04395e37f0425d..ef4dabf00c1a9e 100644
--- a/lldb/source/Target/Target.cpp
+++ b/lldb/source/Target/Target.cpp
@@ -4428,6 +4428,15 @@ void TargetProperties::SetDisableSTDIO(bool b) {
const uint32_t idx = ePropertyDisableSTDIO;
SetPropertyAtIndex(idx, b);
}
+std::optional
+TargetProperties::GetLaunchWorkingDirectory() const {
+ const uint32_t idx = ePropertyLaunchWorkingDir;
+ llvm::StringRef value = GetPropertyAtIndexAs(
+ idx, g_target_properties[idx].default_cstr_value);
+ if (value.empty())
+return {};
+ return value;
+}
const char *TargetProperties::GetDisassemblyFlavor() const {
const uint32_t idx = ePropertyDisassemblyFlavor;
diff --git a/lldb/source/Target/TargetProperties.td
b/lldb/source/Target/TargetProperties.td
index fb61478fb752dc..a6e833d5c6e3f9 100644
--- a/lldb/source/Target/TargetProperties.td
+++ b/lldb/source/Target/TargetProperties.td
@@ -201,6 +201,10 @@ let Definition = "target" in {
def DebugUtilityExpression: Property<"debug-utility-expression", "Boolean">,
DefaultFalse,
Desc<"Enable debugging of LLDB-internal utility expressions.">;
+ def LaunchWorkingDir: Property<"launch-working-dir", "String">,
+DefaultStringValue<"">,
+Desc<"A default value for the working directory to use when launching
processes. "
+ "It's not used when empty.">;
}
let Definition = "process_experimental" in {
diff --git a/lldb/test/API/commands/process/launch/TestProcessLaunch.py
b/lldb/test/API/commands/process/launch/TestProcessLaunch.py
index 45f9f494ab8f5c..4bab553af01ad9 100644
--- a/lldb/test/API/commands/process/launch/TestProcessLaunch.py
+++ b/lldb/test/API/commands/process/launch/TestProcessLaunch.py
@@ -8,6 +8,7 @@
from lldbsuite.test.decorators import *
from lldbsuite.test.lldbtest import *
from lldbsuite.test import lldbutil
+from pathlib import Path
class ProcessLaunchTestCase(TestBase):
@@ -206,3 +207,70 @@ def test_environment_with_special_char(self):
self.assertEqual(value, evil_var)
process.Continue()
self.assertState(process.GetState(), lldb.eStateExited, PROCESS_EXITED)
+
+def test_target_launch_working_dir_prop(self):
+"""Test that the setting `target.launch-w
[Lldb-commits] [lldb] f52b895 - [lldb][AArch64] Read fpmr register from core files (#110104)
Author: David Spickett
Date: 2024-10-24T10:27:56+01:00
New Revision: f52b89561f2d929c0c6f37fd818229fbcad3b26c
URL:
https://github.com/llvm/llvm-project/commit/f52b89561f2d929c0c6f37fd818229fbcad3b26c
DIFF:
https://github.com/llvm/llvm-project/commit/f52b89561f2d929c0c6f37fd818229fbcad3b26c.diff
LOG: [lldb][AArch64] Read fpmr register from core files (#110104)
https://developer.arm.com/documentation/ddi0601/2024-06/AArch64-Registers/FPMR--Floating-point-Mode-Register
for details of the register.
Added:
lldb/test/API/linux/aarch64/fpmr/corefile
Modified:
lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp
lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.h
lldb/source/Plugins/Process/elf-core/RegisterUtilities.h
lldb/test/API/linux/aarch64/fpmr/TestAArch64LinuxFPMR.py
lldb/test/API/linux/aarch64/fpmr/main.c
Removed:
diff --git
a/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp
b/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp
index 413bf1bbdb2a58..2ddf8440aeb035 100644
--- a/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp
+++ b/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp
@@ -64,6 +64,11 @@ RegisterContextCorePOSIX_arm64::Create(Thread &thread, const
ArchSpec &arch,
if (zt_data.GetByteSize() >= 64)
opt_regsets.Set(RegisterInfoPOSIX_arm64::eRegsetMaskZT);
+ DataExtractor fpmr_data =
+ getRegset(notes, arch.GetTriple(), AARCH64_FPMR_Desc);
+ if (fpmr_data.GetByteSize() >= sizeof(uint64_t))
+opt_regsets.Set(RegisterInfoPOSIX_arm64::eRegsetMaskFPMR);
+
auto register_info_up =
std::make_unique(arch, opt_regsets);
return std::unique_ptr(
@@ -128,6 +133,9 @@
RegisterContextCorePOSIX_arm64::RegisterContextCorePOSIX_arm64(
if (m_register_info_up->IsZTPresent())
m_zt_data = getRegset(notes, target_triple, AARCH64_ZT_Desc);
+ if (m_register_info_up->IsFPMRPresent())
+m_fpmr_data = getRegset(notes, target_triple, AARCH64_FPMR_Desc);
+
ConfigureRegisterContext();
}
@@ -370,6 +378,11 @@ bool RegisterContextCorePOSIX_arm64::ReadRegister(const
RegisterInfo *reg_info,
*reg_info, reinterpret_cast(&m_sme_pseudo_regs) + offset,
reg_info->byte_size, lldb_private::endian::InlHostByteOrder(),
error);
}
+ } else if (IsFPMR(reg)) {
+offset = reg_info->byte_offset - m_register_info_up->GetFPMROffset();
+assert(offset < m_fpmr_data.GetByteSize());
+value.SetFromMemoryData(*reg_info, m_fpmr_data.GetDataStart() + offset,
+reg_info->byte_size, lldb::eByteOrderLittle,
error);
} else
return false;
diff --git
a/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.h
b/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.h
index ff94845e58d602..35588c40c2eb1a 100644
--- a/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.h
+++ b/lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.h
@@ -62,6 +62,7 @@ class RegisterContextCorePOSIX_arm64 : public
RegisterContextPOSIX_arm64 {
lldb_private::DataExtractor m_za_data;
lldb_private::DataExtractor m_mte_data;
lldb_private::DataExtractor m_zt_data;
+ lldb_private::DataExtractor m_fpmr_data;
SVEState m_sve_state = SVEState::Unknown;
uint16_t m_sve_vector_length = 0;
diff --git a/lldb/source/Plugins/Process/elf-core/RegisterUtilities.h
b/lldb/source/Plugins/Process/elf-core/RegisterUtilities.h
index 12aa5f72371c51..b97279b0d735b8 100644
--- a/lldb/source/Plugins/Process/elf-core/RegisterUtilities.h
+++ b/lldb/source/Plugins/Process/elf-core/RegisterUtilities.h
@@ -144,6 +144,10 @@ constexpr RegsetDesc AARCH64_MTE_Desc[] = {
llvm::ELF::NT_ARM_TAGGED_ADDR_CTRL},
};
+constexpr RegsetDesc AARCH64_FPMR_Desc[] = {
+{llvm::Triple::Linux, llvm::Triple::aarch64, llvm::ELF::NT_ARM_FPMR},
+};
+
constexpr RegsetDesc PPC_VMX_Desc[] = {
{llvm::Triple::FreeBSD, llvm::Triple::UnknownArch, llvm::ELF::NT_PPC_VMX},
{llvm::Triple::Linux, llvm::Triple::UnknownArch, llvm::ELF::NT_PPC_VMX},
diff --git a/lldb/test/API/linux/aarch64/fpmr/TestAArch64LinuxFPMR.py
b/lldb/test/API/linux/aarch64/fpmr/TestAArch64LinuxFPMR.py
index d022c8eb3d6cc4..7f8dc811c5df36 100644
--- a/lldb/test/API/linux/aarch64/fpmr/TestAArch64LinuxFPMR.py
+++ b/lldb/test/API/linux/aarch64/fpmr/TestAArch64LinuxFPMR.py
@@ -11,9 +11,13 @@
class AArch64LinuxFPMR(TestBase):
NO_DEBUG_INFO_TESTCASE = True
+# The value set by the inferior.
+EXPECTED_FPMR = (0b101010 << 32) | 0b101
+EXPECTED_FPMR_FIELDS = ["LSCALE2 = 42", "F8S1 = FP8_E4M3 | 0x4"]
+
@skipUnlessArch("aarch64")
@skipUnlessPlatform(["linux"])
-def test_fpmr_register(self):
+def test_fpmr_register_live(self):
if not self.isAArch64FPMR():
se
[Lldb-commits] [lldb] [lldb][AArch64] Read fpmr register from core files (PR #110104)
DavidSpickett wrote: Np. I also realised I have been missing review requests on llvm-zorg for weeks too, including yours. https://github.com/llvm/llvm-project/pull/110104 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb] Extend FindTypes to optionally search by mangled type name (PR #113007)
@@ -300,6 +303,12 @@ class TypeQuery {
m_options &= ~e_find_one;
}
+ /// Returns true if the type query is supposed to treat the name to be
+ /// searched as a mangled name.
+ bool GetSearchByMangledName() const {
+return (m_options & e_search_by_mangled_name) != 0;
+ }
Michael137 wrote:
Is there a setter that only lives on the Apple fork then? Don't think it'd be
too outrageous to add both the getter/setter here as we do for all the other
options (even if we only have coverage for it on the Apple fork i guess)
https://github.com/llvm/llvm-project/pull/113007
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [lldb][AArch64] Read fpmr register from core files (PR #110104)
https://github.com/DavidSpickett closed https://github.com/llvm/llvm-project/pull/110104 ___ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] [LLDB] Add a target.launch-working-dir setting (PR #113521)
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Walter Erquinigo (walter-erquinigo)
Changes
Internally we use bazel in a way in which it can drop you in a LLDB session
with the target launched in a particular cwd, which is needed for things to
work. We've been making this automation work via `process launch -w`. However,
if later the user wants to restart the process with `r`, then they end up using
a different cwd for relaunching the process. As a way to fix this, I'm adding a
target-level setting that allows overriding the cwd used for launching the
process without needing the user to specify it manually.
---
Full diff: https://github.com/llvm/llvm-project/pull/113521.diff
5 Files Affected:
- (modified) lldb/include/lldb/Target/Target.h (+3)
- (modified) lldb/source/Commands/CommandObjectProcess.cpp (+5)
- (modified) lldb/source/Target/Target.cpp (+9)
- (modified) lldb/source/Target/TargetProperties.td (+4)
- (modified) lldb/test/API/commands/process/launch/TestProcessLaunch.py (+45)
``diff
diff --git a/lldb/include/lldb/Target/Target.h
b/lldb/include/lldb/Target/Target.h
index e4848f19e64d62..0e8bbb41f29941 100644
--- a/lldb/include/lldb/Target/Target.h
+++ b/lldb/include/lldb/Target/Target.h
@@ -37,6 +37,7 @@
#include "lldb/Utility/RealpathPrefixes.h"
#include "lldb/Utility/Timeout.h"
#include "lldb/lldb-public.h"
+#include "llvm/ADT/StringRef.h"
namespace lldb_private {
@@ -114,6 +115,8 @@ class TargetProperties : public Properties {
void SetDisableSTDIO(bool b);
+ std::optional GetLaunchWorkingDirectory() const;
+
const char *GetDisassemblyFlavor() const;
InlineStrategy GetInlineStrategy() const;
diff --git a/lldb/source/Commands/CommandObjectProcess.cpp
b/lldb/source/Commands/CommandObjectProcess.cpp
index e7c7d07ad47722..297c94c1f0a055 100644
--- a/lldb/source/Commands/CommandObjectProcess.cpp
+++ b/lldb/source/Commands/CommandObjectProcess.cpp
@@ -201,6 +201,11 @@ class CommandObjectProcessLaunch : public
CommandObjectProcessLaunchOrAttach {
if (target->GetDisableSTDIO())
m_options.launch_info.GetFlags().Set(eLaunchFlagDisableSTDIO);
+if (std::optional wd =
+target->GetLaunchWorkingDirectory()) {
+ m_options.launch_info.SetWorkingDirectory(FileSpec(*wd));
+}
+
// Merge the launch info environment with the target environment.
Environment target_env = target->GetEnvironment();
m_options.launch_info.GetEnvironment().insert(target_env.begin(),
diff --git a/lldb/source/Target/Target.cpp b/lldb/source/Target/Target.cpp
index 04395e37f0425d..ef4dabf00c1a9e 100644
--- a/lldb/source/Target/Target.cpp
+++ b/lldb/source/Target/Target.cpp
@@ -4428,6 +4428,15 @@ void TargetProperties::SetDisableSTDIO(bool b) {
const uint32_t idx = ePropertyDisableSTDIO;
SetPropertyAtIndex(idx, b);
}
+std::optional
+TargetProperties::GetLaunchWorkingDirectory() const {
+ const uint32_t idx = ePropertyLaunchWorkingDir;
+ llvm::StringRef value = GetPropertyAtIndexAs(
+ idx, g_target_properties[idx].default_cstr_value);
+ if (value.empty())
+return {};
+ return value;
+}
const char *TargetProperties::GetDisassemblyFlavor() const {
const uint32_t idx = ePropertyDisassemblyFlavor;
diff --git a/lldb/source/Target/TargetProperties.td
b/lldb/source/Target/TargetProperties.td
index fb61478fb752dc..613442501d6b6d 100644
--- a/lldb/source/Target/TargetProperties.td
+++ b/lldb/source/Target/TargetProperties.td
@@ -201,6 +201,10 @@ let Definition = "target" in {
def DebugUtilityExpression: Property<"debug-utility-expression", "Boolean">,
DefaultFalse,
Desc<"Enable debugging of LLDB-internal utility expressions.">;
+ def LaunchWorkingDir: Property<"launch-working-dir", "String">,
+DefaultStringValue<"">,
+Desc<"An override for the working directory to use when launching
processes. "
+ "It's not used when empty.">;
}
let Definition = "process_experimental" in {
diff --git a/lldb/test/API/commands/process/launch/TestProcessLaunch.py
b/lldb/test/API/commands/process/launch/TestProcessLaunch.py
index 45f9f494ab8f5c..f3afc385a56086 100644
--- a/lldb/test/API/commands/process/launch/TestProcessLaunch.py
+++ b/lldb/test/API/commands/process/launch/TestProcessLaunch.py
@@ -8,6 +8,7 @@
from lldbsuite.test.decorators import *
from lldbsuite.test.lldbtest import *
from lldbsuite.test import lldbutil
+from pathlib import Path
class ProcessLaunchTestCase(TestBase):
@@ -206,3 +207,47 @@ def test_environment_with_special_char(self):
self.assertEqual(value, evil_var)
process.Continue()
self.assertState(process.GetState(), lldb.eStateExited, PROCESS_EXITED)
+
+def test_target_launch_working_dir_prop(self):
+"""Test that the setting `target.launch-working-dir` is correctly used
when launching a process."""
+d = {"CXX_SOURCES": "print_cwd.cpp"}
+self.build(dictionary=d)
+self.setTearDownCleanup(d)
+exe = s
