> On Apr 19, 2021, at 12:59 AM, Michał Górny via lldb-dev
> <lldb-dev@lists.llvm.org> wrote:
>
> Hi, everyone.
>
> I'm considering running some effort to improve protocol-level
> compatibility between LLDB and GDB. I'd like to hear if there's
> interest in such patches being accepted into LLDB.
Yes!
>
> My goal would be to make it possible to use LLDB to connect to gdbserver
> (and other servers implementing the same protocol), and to be able to
> use full set of debugger's features while doing that. Ideally, also
> connecting to lldb-server from GDB would be supported too.
That would be great. Anything we can do to make GDB and LLDB play with any GDB
servers and lldb-servers would be very nice.
>
> I think the first blocker towards this project are existing
> implementation bugs in LLDB. For example, the vFile implementation is
> documented as using incorrect data encoding and open flags. This is not
> something that can be trivially fixed without breaking compatibility
> between different versions of LLDB.
We should just fix this bug in LLDB in both LLDB's logic and lldb-server IMHO.
We typically distribute both "lldb" and "lldb-server" together so this
shouldn't be a huge problem.
>
> My current idea would be to add some logic to distinguish the current
> (i.e. 'old') versions of LLDB from GDB, and to have new versions of LLDB
> indicate GDB protocol fixes via qSupported.
>
> For example, unless I'm mistaken 'QThreadSuffixSupported' is purely
> an LLDB extension.
I believe it. We did this because having to first select a thread and then read
a register, means you have to send the two packets and make sure no other
packets are sent in between. We did a lot of work to reduce the number of
packets between the debugger and the GDB server as latency is what slows down
debug sessions and if you have high latency, and send a lot more packets, then
things slow down quite a bit.
> Let's say we implement GDB-compatible vFile packets
> as 'gdb-compat:vFile' feature.
>
> The client would:
>
> 1. Send 'gdb-compat:vFile' in qSupported to indicate that it's ready to
> use correct GDB-style packets.
>
> 2. Check for server's qSupported response. Now:
>
> - if it contains 'gdb-compat:vFile+', then we're dealing with new
> version of lldb-server and we use gdb-style vFile packets,
>
> - otherwise, if it contains 'QThreadSuffixSupported+', then we're
> dealing with old version of lldb-server and we use lldb-style vFile
> packets,
>
> - otherwise, we assume we're dealing with real GDB, and we use gdb-style
> packets.
>
> On the server-side, we would similarly check for 'gdb-compat:vFile+' in
> client's qSupported, and for the call to 'QThreadSuffixSupported' to
> determine whether we're dealing with GDB or LLDB client.
>
> What do you think?
I would be fine just fixing the bugs in the LLDB implementation and move
forward. Happy to hear others chime in though if they feel differently.
The other main issue LLDB has when using other GDB servers is the dynamic
register information is not enough for debuggers to live on unless there is
some hard coded support in the debugger that can help fill in register
numberings. The GDB server has its own numbers, and that is great, but in order
to truly be dynamic, we need to know the compiler register number (such as the
reg numbers used for .eh_frame) and the DWARF register numbers for debug info
that uses registers numbers (these are usually the same as the compiler
register numbers, but they do sometimes differ (like x86)). LLDB also likes to
know "generic" register numbers like which register it the PC (RIP for x86_64,
EIP for x86, etc), SP, FP and a few more. lldb-server has extensions for this
so that the dynamic register info it emits is enough for LLDB. We have added
extra key/value pairs to the XML that is retrieved via "target.xml" so that it
can be complete. See the function in
lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp:
bool ParseRegisters(XMLNode feature_node, GdbServerTargetInfo &target_info,
GDBRemoteDynamicRegisterInfo &dyn_reg_info, ABISP abi_sp,
uint32_t ®_num_remote, uint32_t ®_num_local);
There are many keys we added: "encoding", "format", "gcc_regnum",
"ehframe_regnum", "dwarf_regnum", "generic", "value_regnums",
"invalidate_regnums", "dynamic_size_dwarf_expr_bytes"
I look forward to seeing any patches that help move this forward!
Greg Clayton
>
> --
> Best regards,
> Michał Górny
>
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
