================
@@ -1085,6 +1084,17 @@ std::string
VariableDescription::GetResult(llvm::StringRef context) {
return description.trim().str();
}
+std::optional<lldb::addr_t> GetMemoryReference(lldb::SBValue v) {
+ if (!v.GetType().IsPointerType() && !v.GetType().IsArrayType())
+ return std::nullopt;
+
----------------
clayborg wrote:
I used to love being able to see a value in memory with the Metrowerks IDE many
years ago. Do we want to just alway return the load address?
```
std::optional<lldb::addr_t> GetMemoryReference(lldb::SBValue v) {
lldb::addr_t load_addr = v.GetLoadAddress();
if (load_addr != LLDB_INVALID_ADDRESS)
return load_addr;
return std::nullopt;
}
```
This way we always show the address of any value. If the value is a pointer, we
will show the address of pointer itself in memory, not what is being pointed
to. This way these will have different memory addresses:
```
int my_value;
int* my_ptr = &my_value;
```
The specification states:
```
/**
* A memory reference to a location appropriate for this result.
* For pointer type eval results, this is generally a reference to the
* memory address contained in the pointer.
* This attribute may be returned by a debug adapter if corresponding
* capability `supportsMemoryReferences` is true.
*/
memoryReference?: string;
```
So `A memory reference to a location appropriate for this result.` in my mind
is where the value lives in memory and I would like to see any value and where
it is in memory. Even though the next sentence mentions a pointer should be
dereferenced. Seems like a shame to only allow us to view memory for pointers
as they are the easiest to view in memory with `memory read` commands already
because we can copy the value of the pointer from the variable view and then
type `memory read <paste>` and see the memory in the debug console already. But
if we have a structure that lives in memory, it is harder to see that value in
memory as we would always need to first type `&myStruct` in the debug console
just to get a pointer so that we could then open up the memory viewer.
Happy to hear opinions on this.
https://github.com/llvm/llvm-project/pull/104317
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits