Closed noppej closed 2 years ago
@Tiwalun , @Yatekii , @Huntc, @Mabezdev
I would really appreciate if you could take a few minutes to review (and comment on) this proposal. It is a big chunk of work, and I'd like to get at least your alignment before I make the investment. I think it will be worth it to improve the user experience and ensure long term success/adoption of the debug extension.
Also, please feel free to invite others to comment if you think they can add to this discussion.
Sounds good to me :+1:.
I wrote the original issue, and this is exactly the kind of change I had in mind.
@Tiwalun Please review this PR, and keep in mind that it has to be synched with both:
cc: @Yatekii
:v: noppej can now approve this pull request. To approve and merge a pull request, simply reply with bors r+
. More detailed instructions are available here.
bors r+
Build succeeded:
This PR was motivated by discussions in #7, and will require rework of the equivalent functionality in probe-rs-debugger. It will involve a big code change in both repo's.
In the first iterations of this extension, the
launch
andattach
terminology was interpreted to apply to the debug adapter process. In other words, "launch a new instance of the debug adapter", or "attach to a to an existing debug adapter process". - Both operations allowed flashing and resetting of the target process running on the probe.The proposed change will reinterpret the
launch
andattach
terminology to apply to the target process running on the probe. To help clarify the different behaviours, I will use the following terminology:launch
orattach
request, and ...disconnect
request, or chooses toStop
a host side debug session.Reset
request, or when the device looses power.launch
request typeReset
request so that a new target session is started ii. Optionally flashes the target device firmware with the binary to be executedattach
request typeCommon behaviour to both
launch
andattach
request typesReset
request will causeprobe-rs
, to restart the target device, and associated target session. i. This will honour the value of thehalt_after_reset
flag. ii. The debug session is not affected.Disconnect
request in the debug session will ... i. Instructprobe-rs
to disconnect from the target device. ii. This implicitly ends the debug session. iii. The state of the target session is not affected. iv. There are some subtleties depending onlaunch
vsattach
as described in the MS DAP Specification for the Disconnect RequestStop
function (Terminate
request) in the debug session will behave the same as thedisconnect
, except ... i. The debug session will send astop
request tohalt
the target session before disconnecting. ii. There are some subtleties depending onlaunch
vsattach
as described in the MS DAP Specification for the Terminate RequestRunning
probe-rs-debugger
as a standalone for a VSCode debug sessionIn most cases, the VSCode debug extension will take care of automatically launching (and ending) the
probe-rs-debugger
executable to act as the debug adapter forprobe-rs
.It is possible for the user to take control of this, by running
probe-rs-debugger
from the command line, with the following commandprobe-rs-debugger debug --dap --port <any availably TCP/IP port number>
Any VSCode debug session can then attach to the specified on the server where
probe-rs-debugger
runs, and use the functionality above.launch.json
configuration, by adding the option"server":"<host address>:<port number>"
(e.g."server":"127.0.0.1:50000"
) ii. Such a server debug session will put the management (start and stop) of theprobe-rs-debugger
process completely under control of the user.Further reading:
The above proposal aims to be consistent with the process described in the VSCode debug docs