LLDB: GDB remote protocol feature/packet `swbreak` not supported

[ByteNacked]

Hello,
When I was trying to use latest lldb with gdbserver, I came across an issue of not supported feature/packet swbreak in GDB remote protocol.
As far as I understand, without this feature, software breakpoints do not work correctly then using with gdbserver.

On swbreak in gdb manual:

On some architectures, such as x86, at the architecture level, when a breakpoint instruction executes the program counter points at the breakpoint address plus an offset. On such targets, the stub is responsible for adjusting the PC to point back at the breakpoint address.

And this is exactly that (not) happens then I trying to use software breakpoints in this setup,
PC register does not adjusted and program crashes.

Is that intendent behaviour?
Will patches adding this feature be accepted?

Ubuntu 20.04.4 LTS x86_64
llvb version : latest master/main
gdbserver version : GNU gdbserver (Ubuntu 9.2-0ubuntu1~20.04.1) 9.2

[llvmbot]

@llvm/issue-subscribers-lldb

[DavidSpickett]

If I understand correctly, the PC is only adjusted by the stub if it's going to set this swbreak stop reason. Otherwise it sends the unmodified PC and expects the client to do the adjustment.

Is that intendent behaviour?

I doubt that it is intentional not to support this, it's probably because lldb-server does this adjustment and we only tested with that (see lldb/source/Host/common/NativeProcessProtocol.cpp::void NativeProcessProtocol::FixupBreakpointPCAsNeeded ).

I assume lldb tells gdb-server that it does not support this packet type. So when we hit the break we get the uncorrected PC but lldb is used to lldb-server doing the correction regardless.

Will patches adding this feature be accepted?

If we have a way to test them, sure. At most that means making lldb-server also send these packets, at least making lldb parse them. You might be able to test by just making a packet stream to give lldb.

This is gated with qSupported so adding it to new lldbs shouldn't be an issue.

[ByteNacked]

Thank you for the answer.

I've tinkered a bit with this problem and came to the conclusion that the situation is exactly as you described it.
Main point is that lldb-server adjust PC unconditionally and the gdb-server needs additional feature (swbreak+) sent form the client to perform the adjustment (also obviously support of this type of the packet on client side).

At most that means making lldb-server also send these packets

I got the at most part, but as far as I understand,
making lldb-server send these packets will be useless as lldb uses own custom protocol extension to indicate software breakpoint.

[DavidSpickett]

My point was that you might be arguing to move lldb-server to using swbreak as well/instead, to align it with gdbserver. That is more work and like you said we already have an equivalent for lldb to lldb-server connections.

If you can make lldb understand swbreak and test it without any lldb-server changes that's fine. I know we can test lldb-server by supplying it packets (e.g. lldb/test/API/tools/lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.py) but I'm not sure if we can do the same with lldb. The closest I've written is stuff like lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp.

If the change is small enough it might be able to go in without specific testing.

[ByteNacked]

Okay, thanks,
I'll look into lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp .

[labath]

If you can make lldb understand swbreak and test it without any lldb-server changes that's fine. I know we can test lldb-server by supplying it packets (e.g. lldb/test/API/tools/lldb-server/memory-tagging/TestGdbRemoteMemoryTagging.py) but I'm not sure if we can do the same with lldb.

Tests for the opposite direction can be found in test/API/functionalities/gdb_remote_client/

[xusheng6]

Is there any update on this? This is now causing Vector35/debugger#535 for the Binary Ninja debugger

[DavidSpickett]

Zero changes in this area lately. PRs welcome if anyone wants to fix this themselves.

https://lldb.llvm.org/resources/build.html
https://llvm.org/docs/Contributing.html#how-to-submit-a-patch

[xusheng6]

Zero changes in this area lately. PRs welcome if anyone wants to fix this themselves.

https://lldb.llvm.org/resources/build.html https://llvm.org/docs/Contributing.html#how-to-submit-a-patch

Thanks for letting me know. I will consider it, but do not expect too much :)

[xusheng6]

I created a PR that should fix this: #102873, please have a look at it!