[all-commits] [llvm/llvm-project] 2f2e31: Initial step in targets DAP support (#86623)

[jeffreytan81 via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 2f2e31c3c980407b2660b4f5d10e7cdb3fa79138
      https://github.com/llvm/llvm-project/commit/2f2e31c3c980407b2660b4f5d10e7cdb3fa79138
  Author: jeffreytan81 <jeffreytan at meta.com>
  Date:   2024-04-25 (Thu, 25 Apr 2024)

  Changed paths:
    M lldb/include/lldb/API/SBLineEntry.h
    M lldb/include/lldb/API/SBSymbolContextList.h
    M lldb/include/lldb/API/SBTarget.h
    M lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py
    M lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py
    M lldb/source/API/SBLineEntry.cpp
    M lldb/source/API/SBTarget.cpp
    A lldb/test/API/tools/lldb-dap/stepInTargets/Makefile
    A lldb/test/API/tools/lldb-dap/stepInTargets/TestDAP_stepInTargets.py
    A lldb/test/API/tools/lldb-dap/stepInTargets/main.cpp
    M lldb/tools/lldb-dap/DAP.h
    M lldb/tools/lldb-dap/lldb-dap.cpp

  Log Message:
  -----------
  Initial step in targets DAP support  (#86623)

This patch provides the initial implementation for the "Step Into
Specific/Step In Targets" feature in VSCode DAP.

The implementation disassembles all the call instructions in step range
and try to resolve operand name (assuming one operand) using debug info.
Later, the call target function name is chosen by end user and specified
in the StepInto() API call.

It is v1 because of using the existing step in target function name API.
This implementation has several limitations:
* Won't for indirect/virtual function call -- in most cases, our
disassembler won't be able to solve the indirect call target
address/name.
* Won't work for target function without debug info -- if the target
function has symbol but not debug info, the existing
ThreadPlanStepInRange won't stop.
* Relying on function names can be fragile -- if there is some middle
glue/thunk code, our disassembler can only resolve the glue/thunk code's
name not the real target function name. It can be fragile to depend
compiler/linker emits the same names for both.
* Does not support step into raw address call sites -- it is a valid
scenario that in Visual Studio debugger, user can explicitly choose a
raw address to step into which land in the function without debug
info/symbol, then choose UI to load the debug info on-demand for that
module/frame to continue exploring.

A more reliable design could be extending the ThreadPlanStepInRange to
support step in based on call-site instruction offset/PC which I will
propose in next iteration.

---------

Co-authored-by: jeffreytan81 <jeffreytan at fb.com>



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications