[RFC] Extending formatters with a "source code reference"

Subprojects LLDB
1

Hi,

I quickly wanted to get a feeling for what the LLVM/LLDB community thinks about Add "source code reference" to `Variable` · Issue #372 · microsoft/debug-adapter-protocol · GitHub, i.e. a proposal to associate “source code references” with variables in the debugger.

E.g., for function pointers/std::function instances, LLDB could add the necessary meta-data to a variable’s value such that the debugger UI (e.g., Visual Studio Code) can offer a button “Go to source code”. Similarly, lldb’s formatter for std::source_location can point this source code reference to the location stored inside the std::source_location. The debugger UI/VS Code could show the “Go to source code” button which takes you directly to the source code location which this std::source_location is referring to.

Would we be willing to add a command type source_ref add std::source_location --python-function my_function_ref or something similar to LLDB? And extend SBValue such that it can store an additional, optional source code reference?

2

I’ve been considering something along these lines but more general for a little bit. This post was the impetus to actually write it up. I think we could do what you want and a fair bit of other cool things if we did:

Take a look and see what you think.

1 Like
3

If we can make the proposed general-purpose meta-data framework also work for this use case, that could indeed provide some nice synergies. However, I am not yet completely convinced that the proposed SBValue Metadata Providers will fit for the “attach source locations to values” use case. I will reply to your RFC soon, and give you the chance to convince me

Edit: I am sold on the proposal to implement a more general-purpose metadata framework by now.

4

Some more context: I can think of the following types which could benefit from source code locations:

  1. all function pointers, all member function pointers
  2. std::function, std::copyable_function, std::moveable_function, std::function_ref
  3. all normal pointers
  4. std::source_location, std::stacktrace_entry, std::stacktrace
  5. std::coroutine_handle

Function pointers would be annotated with the source code location where the function was defined which they currently point to. For

void greet() { std::cout << "Hello World\n"; }
using FuncPtrType = void(*)();
FuncPtrType myFuncPtr = &greet;

the source location associated with myFuncPtr would point to the definition of greet. Similar for member function pointers and the various std::*function* variants.

For all normal pointers: Given the source code

int globalA = 1;
int globalB = 2;

int* ptr = &globalA;

the value ptr would be annotated in the debugger with the location of the entity it points to, i.e. to location of globalA.

std::source_location and std::stacktrace_entry would point to whichever location is stored inside the source_location. std::stacktrace is just a container containing multiple std::stacktrace_entry instances.

For std::coroutine_handle, the source location would point to the exact line/column in the source code where this coroutine is currently suspended. It’s still a bit unclear how I would represent this information in DWARF (see discussion in [RFC] Debug info for coroutine suspension locations). But it seems before figuring that out, I will first take a detour to find an end-to-end solution (Visual Studio Code, Debug Adapter Protocol and LLDB) to provide source locations for other more easily achievable types for which all the necessary information is already in the DWARF debug info