This is an archive of the discontinued LLVM Phabricator instance.

Add runToBinaryEntry option for lldb-vscode
AbandonedPublic

Authored by yinghuitan on Nov 23 2022, 9:28 AM.

Details

Summary

This patch adds a new runToBinaryEntry option which sets a one-shot breakpoint
at program entry. This option is useful for synchronizing module loading with
dynamic loader to measure debugger startup performance: when program entry
one-short breakpoint hits most of the dependency modules should have been
loaded so this provides a good sample point for debugger startup time.

More explicitly for lldb-vscode, when this option is enabled, "Initialized" DAP
event is synchronously sent after most dependency modules are loaded.

Note: this is re-submission of https://reviews.llvm.org/D135798

Diff Detail

Event Timeline

yinghuitan created this revision.Nov 23 2022, 9:28 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 23 2022, 9:28 AM
yinghuitan requested review of this revision.Nov 23 2022, 9:28 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 23 2022, 9:28 AM
clayborg requested changes to this revision.Nov 23 2022, 10:32 AM

We have to let the IDE set breakpoints after the "initialized" packet is sent and _then_ do this functionality. So this patch needs to be modified to make that happen.

lldb/tools/lldb-vscode/lldb-vscode.cpp
1807–1809

If this synchronously runs to the entry point of the program prior to letting the IDE set breakpoints (which happens when the "initialized" packet is sent), then we can't do this. We can miss breakpoints if they are set in the C++ global initializer lists. The flow with this in here will not stop at the entry point and allow the IDE to set breakpoints first and this must happen.

lldb/tools/lldb-vscode/package.json
162

Description should be capitalized correct and the language is a bit off "run to program entry one-shot breakpoint"? Did you mean "run to program entry using a one-shot breakpoint"?

This revision now requires changes to proceed.Nov 23 2022, 10:32 AM

Ideally this feature would enable a one shot breakpoint and let the startup happen just like it was before this patch.

We don't want the user to see this stop right? It seems like we should allow some commands to be run with this one shot breakpoint and have it auto continue? What is supposed to happen now? the IDE knows that it set this startup option and then does something on the first stop?

yinghuitan abandoned this revision.Nov 23 2022, 11:16 AM

Discussed offline. We can't rely on initialized event because it has to happen before all breakpoints are set. Will create a new design for htis.