[lldb-dev] [RFC] Improving protocol-level compatibility between LLDB and GDB

[Pavel Labath via lldb-dev]

I am very happy to see this effort and I fully encourage it.

On 20/04/2021 09:13, Michał Górny via lldb-dev wrote:
> On Mon, 2021-04-19 at 16:29 -0700, Greg Clayton wrote:
>>> 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.
> 
> Hmm, I've focused on this because I recall hearing that OSX users
> sometimes run new client against system server... but now I realized
> this isn't relevant to LLGS ;-).  Still, I'm happy to do things
> the right way if people feel like it's needed, or the easy way if it's
> not.

The vFile packets are, used in the "platform" mode of the connection 
(which, btw, is also something that gdb does not have), and that is 
implemented by lldb-server on all hosts (although I think apple may have 
some custom platform implementations as well). In any case though, 
changing flag values on the client will affect all servers that it 
communicates with, regardless of the platform.

At one point, Jason cared enough about this to add a warning about not 
changing these constants to the code. I'd suggest checking with him 
whether this is still relevant.

Or just going with your proposed solution, which sounds perfectly 
reasonable to me....

> 
>> 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 &reg_num_remote, uint32_t &reg_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"
>>
> 
> Yes, this is probably going to be the hardest part.  While working
> on plugins, I've found LLDB register implementation very hard to figure
> out, especially that the plugins seem to be a mix of new, old and older
> solutions to the same problem.
> 
> We will probably need more ground-level design changes too.  IIRC lldb
> sends YMM registers as a whole (i.e. with duplication with XMM
> registers) while GDB sends them split like in XSAVE.  I'm not yet sure
> how to handle this best -- if we don't want to push the extra complexity
> on plugins, it might make sense to decouple the packet format from
> the data passed to plugins.
> 

Yes, this is definitely going to be the trickiest part, and probably 
deserves its own RFC. However, I want to note that in the past 
discussions, the consensus (between Jason and me, at least) has been to 
move away from this "rich" register information transfer. For one, 
because we have this information coded into the client anyway (as people 
want to communicate with gdb-like stubs).

So, the first, and hopefully not too hard, step towards that could be to 
get lldb-server to stop sending these extra fields (and fix anything 
that breaks as a result).

pl