[BUG] ACK still sent after LLDB specifies QStartNoAckMode #2252

cynfox commented 2026年05月11日 15:51:27 +02:00

I have been recently attempting to integrate my BMP into the rest of my debug tooling. I use neovim and due to existing plugin limitations, my only option appears to be using gdb --interpreter dap or lldb-dap.

Unfortunately, both seem to be lacking in support for extended-remote:

• GDB Bug 34133 – Crash when specifying --interpreter=dap and using the attach command while in an extended remote context.
• [LLDB] "error: command is not implemented" on process plugin

In the meantime, if a BMDA gdbserver could be started as follows, perhaps with an additional flag to specify that this should launch a server that performs these steps during connection, and one to break on entry.
blackmagic-bmda -M swdp_scan -E -w -V program.elf

This would put the BMP in a state where it is debuggable as a more standard setup where the remote already has a program running, you're attaching to it, and should be able to work with the standard remote rather than extended-remote. This should make BMDA both functional on new and older versions of both debuggers, whilst a fix is being made for both gdb and lldb to support extended-remote.

Additionally, in the LLDB bug report, it appears that they have some concerns about a suspicious ACK, received after running QStartNoAckMode and receiving OK .

I have been recently attempting to integrate my BMP into the rest of my debug tooling. I use neovim and due to existing plugin limitations, my only option appears to be using `gdb --interpreter dap` or `lldb-dap`. Unfortunately, both seem to be lacking in support for `extended-remote`: - [**GDB Bug 34133** – Crash when specifying --interpreter=dap and using the `attach` command while in an extended remote context.](https://sourceware.org/bugzilla/show_bug.cgi?id=34133) - [[LLDB] "error: command is not implemented" on process plugin](https://github.com/llvm/llvm-project/issues/196535#issuecomment-4420757457) In the meantime, if a BMDA gdbserver could be started as follows, perhaps with an additional flag to specify that this should launch a server that performs these steps during connection, and one to break on entry. ```blackmagic-bmda -M swdp_scan -E -w -V program.elf``` This would put the BMP in a state where it is debuggable as a more standard setup where the remote already has a program running, you're attaching to it, and should be able to work with the standard `remote` rather than `extended-remote`. This should make BMDA both functional on new and older versions of both debuggers, whilst a fix is being made for both `gdb` and `lldb` to support `extended-remote`. Additionally, in the LLDB bug report, it appears that they [have some concerns](https://github.com/llvm/llvm-project/issues/196535#issuecomment-4407858385) about a suspicious ACK, received after running `QStartNoAckMode` and receiving `OK` .

cynfox commented 2026年05月11日 16:14:39 +02:00

In retrospect, I may be able to get this working with --interpreter=mi and cpptool. I'll test it out when I get back home.

e: Did not mean to close this issue. It is still relevant, I may just have another workaround

In retrospect, I may be able to get this working with `--interpreter=mi` and `cpptool`. I'll test it out when I get back home. e: Did not mean to close this issue. It is still relevant, I may just have another workaround

dragonmux commented 2026年05月11日 17:25:50 +02:00

👋 So, there are a lot of moving pieces to what you're saying here, and so this reply is going to be in several parts..

First: GDB doesn't lack support for extended-remote, it defines what that means. If there's something we're doing wrong there, that should very probably be considered our bug.. however GDB as a debug adaptor protocol server is both news to us and new, so expect them to have issues there.. this is NOT a standard setup.. at least, for now.. you are playing with experimental support there.

Second: LLDB and no-ack mode has been a headache for a long while, it is our bug that we mishandle it wrt that qSupported ACK and so that needs addressing if we didn't already fix it on main - this is entirely separate to everything else going on here though and this is our first time hearing there's still a protocol issue here.

Third: BMD relies very heavily on extended-remote commands like vCont, vRun, vKill, etc.. it is not possible for us to be a non-extended remote. This has absolutely nothing to do with the way you want to use BMD though which was and is already possible with the much more normal and common setup of using GDB directly, and attaching to already running firmware, or indeed via adaptors like Cortex-Debug. Having GDB and LLDB be DAPs themselves is, again, reasonably new functionality in them. extended-remote has much much more to do with what subsets of the GDB RSP commands are valid than any kind of part of your use-case.

Fourth: While it is not ready yet, the roadmap for bmputil has it implementing the DAP protocol down the ways, entirely obviating the need for any of this hackery to integrate it with your setup. While this obviously solves nothing immediately, rather than doing lots to try and make BMDA work more in this way (beyond fixing obvious protocol issues like ACKs being sent in no-ack mode, that's very clearly wrong), the project is more interested in focusing attention on improving the tooling and providing a more complete debugging experience that's less constrained by GDB's limitations and foibles which constrain the project in some fairly unfun ways (like not being able to put messages out to the debugger for the user during events like attach, because O packet responses are not valid during vAttach).

Hopefully this helps a bit with both understanding where extended-remote fits in the protocol picture puzzle, and what a "standard setup" looks like to the project.

If this issue is used to track fixing the extra ACK problem, we would suggest that this solves your larger problem more completely as then things will work properly with LLDB rit large. This needs testing first against main though so we can know if it's still a problem (we suspect so, but we don't have reproducer instructions in your initial report to be able to recreate enough of your environment to try and see ourself).

👋 So, there are a lot of moving pieces to what you're saying here, and so this reply is going to be in several parts.. First: GDB doesn't lack support for extended-remote, it defines what that means. If there's something we're doing wrong there, that should very probably be considered our bug.. however GDB as a debug adaptor protocol server is both news to us and new, so expect them to have issues there.. this is _NOT_ a standard setup.. at least, for now.. you are playing with experimental support there. Second: LLDB and no-ack mode has been a headache for a long while, it is our bug that we mishandle it wrt that qSupported ACK and so that needs addressing if we didn't already fix it on `main` - this is entirely separate to everything else going on here though and this is our first time hearing there's still a protocol issue here. Third: BMD relies very heavily on extended-remote commands like vCont, vRun, vKill, etc.. it is not possible for us to be a non-extended remote. This has absolutely nothing to do with the way you want to use BMD though which was and is already possible with the much more normal and common setup of using GDB directly, and attaching to already running firmware, or indeed via adaptors like Cortex-Debug. Having GDB and LLDB be DAPs themselves is, again, reasonably new functionality in them. extended-remote has much much more to do with what subsets of the GDB RSP commands are valid than any kind of part of your use-case. Fourth: While it is not ready yet, the roadmap for `bmputil` has it implementing the DAP protocol down the ways, entirely obviating the need for any of this hackery to integrate it with your setup. While this obviously solves nothing immediately, rather than doing lots to try and make BMDA work more in this way (beyond fixing obvious protocol issues like ACKs being sent in no-ack mode, that's very clearly wrong), the project is more interested in focusing attention on improving the tooling and providing a more complete debugging experience that's less constrained by GDB's limitations and foibles which constrain the project in some fairly unfun ways (like not being able to put messages out to the debugger for the user during events like attach, because `O` packet responses are not valid during `vAttach`). Hopefully this helps a bit with both understanding where extended-remote fits in the protocol picture puzzle, and what a "standard setup" looks like to the project. If this issue is used to track fixing the extra ACK problem, we would suggest that this solves your larger problem more completely as then things will work properly with LLDB rit large. This needs testing first against `main` though so we can know if it's still a problem (we suspect so, but we don't have reproducer instructions in your initial report to be able to recreate enough of your environment to try and see ourself).

cynfox commented 2026年05月11日 18:00:32 +02:00

First: GDB doesn't lack support for extended-remote, it defines what that means. If there's something we're doing wrong there, that should very probably be considered our bug.. however GDB as a debug adaptor protocol server is both news to us and new, so expect them to have issues there.. this is NOT a standard setup.. at least, for now.. you are playing with experimental support there.

Yep! I did mean lack of support for extended-remote as far as DAP functionality goes, which I do understand is still in it's infancy, GDB 14.1 was the first with DAP support.
In LLDB's case lldb-dap (formerly lldb-vscode) has been around since 2018, their issue is more that they don't support extended-remote with their gdbserver connections almost at all.

Second: LLDB and no-ack mode has been a headache for a long while, it is our bug that we mishandle it wrt that qSupported ACK and so that needs addressing if we didn't already fix it on main - this is entirely separate to everything else going on here though and this is our first time hearing there's still a protocol issue here.

I'll change the title of this issue to specify the NoAck issue so it's easier to find.

Third: BMD relies very heavily on extended-remote commands like vCont, vRun, vKill, etc.. it is not possible for us to be a non-extended remote. This has absolutely nothing to do with the way you want to use BMD though which was and is already possible with the much more normal and common setup of using GDB directly, and attaching to already running firmware, or indeed via adaptors like Cortex-Debug. Having GDB and LLDB be DAPs themselves is, again, reasonably new functionality in them. extended-remote has much much more to do with what subsets of the GDB RSP commands are valid than any kind of part of your use-case.

I was unaware that there was more functionality that was being relied on in extended-remote mode, the documentation online that explains how it works and what it does is quite lacking.

Fourth: While it is not ready yet, the roadmap for bmputil has it implementing the DAP protocol down the ways, entirely obviating the need for any of this hackery to integrate it with your setup. While this obviously solves nothing immediately, rather than doing lots to try and make BMDA work more in this way (beyond fixing obvious protocol issues like ACKs being sent in no-ack mode, that's very clearly wrong), the project is more interested in focusing attention on improving the tooling and providing a more complete debugging experience that's less constrained by GDB's limitations and foibles which constrain the project in some fairly unfun ways (like not being able to put messages out to the debugger for the user during events like attach, because O packet responses are not valid during vAttach).

It's good to hear that bmputil is getting DAP eventually, that will definitely streamline this whole mess quite a bit.

If this issue is used to track fixing the extra ACK problem, we would suggest that this solves your larger problem more completely as then things will work properly with LLDB rit large. This needs testing first against main though so we can know if it's still a problem (we suspect so, but we don't have reproducer instructions in your initial report to be able to recreate enough of your environment to try and see ourself).

Unfortunately, as it stands LLDB fails to initialize the plugin that allows sending monitor commands, and thus you can't even scan for devices, or send the gdb attach command. This can be tested by doing the following:

1. Start a BMDA server
2. Launch lldb and run the following commands

(lldb) gdb-remote 2000
(lldb) process plugin packet monitor swdp_scan

The first command will succeed but the second will fail, as extended-remote doesn't actually load the plugins necessary to send these commands. This issue is entirely independent of lldb-dap and is just present in lldb itself, which is why i was curious about switching to remote over extended-remote.

> First: GDB doesn't lack support for extended-remote, it defines what that means. If there's something we're doing wrong there, that should very probably be considered our bug.. however GDB as a debug adaptor protocol server is both news to us and new, so expect them to have issues there.. this is NOT a standard setup.. at least, for now.. you are playing with experimental support there. Yep! I did mean lack of support for extended-remote as far as DAP functionality goes, which I do understand is still in it's infancy, GDB 14.1 was the first with DAP support. In LLDB's case `lldb-dap` (formerly `lldb-vscode`) has been around since 2018, their issue is more that they don't support extended-remote with their `gdbserver` connections almost at all. > Second: LLDB and no-ack mode has been a headache for a long while, it is our bug that we mishandle it wrt that qSupported ACK and so that needs addressing if we didn't already fix it on main - this is entirely separate to everything else going on here though and this is our first time hearing there's still a protocol issue here. I'll change the title of this issue to specify the NoAck issue so it's easier to find. >Third: BMD relies very heavily on extended-remote commands like vCont, vRun, vKill, etc.. it is not possible for us to be a non-extended remote. This has absolutely nothing to do with the way you want to use BMD though which was and is already possible with the much more normal and common setup of using GDB directly, and attaching to already running firmware, or indeed via adaptors like Cortex-Debug. Having GDB and LLDB be DAPs themselves is, again, reasonably new functionality in them. extended-remote has much much more to do with what subsets of the GDB RSP commands are valid than any kind of part of your use-case. I was unaware that there was more functionality that was being relied on in extended-remote mode, the documentation online that explains how it works and what it does is quite lacking. > Fourth: While it is not ready yet, the roadmap for bmputil has it implementing the DAP protocol down the ways, entirely obviating the need for any of this hackery to integrate it with your setup. While this obviously solves nothing immediately, rather than doing lots to try and make BMDA work more in this way (beyond fixing obvious protocol issues like ACKs being sent in no-ack mode, that's very clearly wrong), the project is more interested in focusing attention on improving the tooling and providing a more complete debugging experience that's less constrained by GDB's limitations and foibles which constrain the project in some fairly unfun ways (like not being able to put messages out to the debugger for the user during events like attach, because O packet responses are not valid during vAttach). It's good to hear that bmputil is getting DAP eventually, that will definitely streamline this whole mess quite a bit. > If this issue is used to track fixing the extra ACK problem, we would suggest that this solves your larger problem more completely as then things will work properly with LLDB rit large. This needs testing first against main though so we can know if it's still a problem (we suspect so, but we don't have reproducer instructions in your initial report to be able to recreate enough of your environment to try and see ourself). Unfortunately, as it stands LLDB fails to initialize the plugin that allows sending monitor commands, and thus you can't even scan for devices, or send the gdb attach command. This can be tested by doing the following: 1. Start a BMDA server 2. Launch lldb and run the following commands ``` (lldb) gdb-remote 2000 (lldb) process plugin packet monitor swdp_scan ``` The first command will succeed but the second will fail, as extended-remote doesn't actually load the plugins necessary to send these commands. This issue is entirely independent of lldb-dap and is just present in lldb itself, which is why i was curious about switching to `remote` over `extended-remote`.