search

bloombloombloom / Bloom

A debug interface for AVR-based embedded systems development on GNU/Linux.
https://bloom.oscillate.io/
Other
65 stars 4 forks source link

Support `target extended-remote` mode #42

Closed septatrix closed 1 year ago

septatrix commented 2 years ago

This way of attaching has a few different semantics regarding loading, attaching, behaviour after detaching etc. Some of this can now be supported as load has been implemented. For a more complete list refer to the gdb documentation.

Other things like the behaviour after detaching would be great to match the intended way as the current implementation (keep connected after closing the debug session) would match extended-remote and not remote which is supposed to exit the gdb server. This should also improve integration with IDEs which expect the respective behaviour (e.g. CLion) without having to manually configure it in the bloom.json.

navnavnav commented 2 years ago

Hi @septatrix

Can you please elaborate on the benefits of this?

We can't attach to the AVR until we've connected to the debug tool and activated the physical interface, which involves the resetting of the target, so I don't see how the attach command can be of any use. If users want to debug a program that's already running, they can start a debug session with 0 breakpoints, let the target run and then stop it when they're ready to begin debugging. They cannot attach to the target without starting a debug session, but starting a debug session involves resetting the target, so effectively, they cannot attach to the target that's already running, without resetting the target.

few different semantics regarding loading

Can you elaborate on this please? What different semantics for loading would this enable and how would AVR developers make use of them? The program is already on the AVR target - I can't see any reason why users would want to specify the program being run as an argument to Bloom - what would Bloom do with that parameter? Are you just looking for a way to program the target automatically, at the beginning of a debug session? If so, I would recommend doing this via CLion's debug configuration, but that's not an option ATM (more on that below). Another option would be to use a .gdbinit file.

Other things like the behaviour after detaching would be great to match the intended way as the current implementation (keep connected after closing the debug session) would match extended-remote and not remote which is supposed to exit the gdb server.

As you've already mentioned, Bloom can already match the intended way via a simple configuration tweak. If the user wishes for Bloom to exit at the end of the debug session, they can configure it to do so. And I've not had any users object to this, because it takes no more than 60 seconds to make the configuration change. If users begin to raise objections to this, I may consider changing the default value of shutdownPostDebugSession to true, so Bloom will follow the intended way by default. But as I mentioned, no one has raised any objections to the current way.

This should also improve integration with IDEs which expect the respective behaviour (e.g. CLion) without having to manually configure it in the bloom.json.

In the case of CLion, I'm afraid it will have little to no effect until CLion developers fix the issue on their end. Bloom cannot intercept the SIGKILL that CLion is issuing. CLion needs to give Bloom more time to shutdown. They claim that they're sending a SIGTERM before a SIGKILL, but there is no evidence of this. In fact, my findings suggest that CLion is killing Bloom immediately, with no SIGTERM in between the disconnecting and the issuing of the SIGKILL. Once CLion developers have resolved this issue, Bloom users should have no problem using CLion to manage Bloom's process.

septatrix commented 2 years ago

Yeah most of the behaviour cannot be reasonable mapped to an AVR target. The two major things I was thinking about was run and dropping shutdownPostDebugSession because if the GDB protocol already has a way to signal the intended behaviour after disconnection it would make sense to use it instead of going with a competing option

navnavnav commented 2 years ago

What would the run command do in the context of AVR debugging? As mentioned above, the program is already loaded on the AVR. And from what I can see, the run command will not trigger a load to upload a different program to the AVR, so I'm still struggling to see the benefit in this.

and dropping shutdownPostDebugSession because if the GDB protocol already has a way to signal the intended behaviour after disconnection it would make sense to use it instead of going with a competing option

From what I can see, GDB doesn't signal the intended behaviour at all (regardless of how you initiate the remote session). The only way Bloom would be able to tell if the user started an extended-remote session, instead of remote session, is upon receiving a command packet that is specific to the extended-remote protocol, which will only happen if the user invokes a GDB command that is only supported by the extended-remote protocol. I don't see how this is better than just letting the user decide via a config param.