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

[Michał Górny via lldb-dev]

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.

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.

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.

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. 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?

-- 
Best regards,
Michał Górny



___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Hiding local variables not defined yet

[Greg Clayton via lldb-dev]

> On Apr 12, 2021, at 4:44 PM, Emre Kultursay  wrote:
> 
> Looking at Android Studio implementation a little deeper, it actually does 
> the filtering the way I described in my first email, by comparing line 
> numbers.  It does not use the location expressions.

Interesting if they are doing more to hide variables. Most people debug with 
debug builds without optimizations, so most of the time this will be ok. If you 
end up debugging optimized code, I guess your variables could end up being 
hidden even though they are available and could have valid values.

lldb command line, Xcode and lldb-vscode will do what I describe below when 
showing variables.

> 
> Do you have a pointer to another implementation (e.g., lldb-vscode) that 
> filters based on location expressions, for comparison?

We always show variables that are in scope. The debug information contains 
descriptions of functions and lexical blocks within functions. So when we have 
a PC address, we find the deepest lexical block and show its variables and all 
variables from all parent lexical blocks all the way back to the function. When 
there is a location expression for a variable, you will still see the variable, 
but the value might show an error saying that the variable is not available.

> 
>  
> 
> On Mon, Apr 12, 2021 at 12:31 PM Emre Kultursay  > wrote:
> LLDB does only show variables that are in lexical scope in ...
> Ah, yes, I got confused because I thought this filter was implemented inside 
> LLDB, yet the `frame variable` command was returning me all local variables; 
> I now notice that it's a filter that's implemented inside the IDE (I'm 
> looking at Android Studio). 
>  
> Thanks for the explanation and also the details about the compiler provided 
> info.
> 
> 
> On Fri, Apr 9, 2021 at 10:15 PM Greg Clayton  > wrote:
> 
> 
>> On Apr 9, 2021, at 11:39 AM, Emre Kultursay via lldb-dev 
>> mailto:lldb-dev@lists.llvm.org>> wrote:
>> 
>> When debugging C/C++ (statically scoped languages), does LLDB recognize (or 
>> does it have a setting for it) that a local variable is not defined yet at 
>> the current program address (i.e., DW_AT_decl_line is less than the source 
>> line for the address), and thus, not include it in the list of locals (i.e., 
>> frame variable)? 
>> 
>> Does it make sense to have such a setting?  The goal is to reduce the 
>> clutter in locals list.
> 
> LLDB does not. We show exactly what the compiler emits. DWARF, the debug 
> information, is powerful enough to say from [0x1000-0x1010) the variable is 
> here, and from [0x1020-0x1100) the variable is there, these are called 
> location expressions. But the compiler, for non optimized code, always just 
> emits the variable's location on the stack and doesn't correctly limit it to 
> when the variable has been initialized.
> 
> So this could easily be fixed in the compiler. LLDB really needs to listen to 
> what the compiler says because once you enable optimizations, the compiler 
> can end up moving all sorts of code around and the variable _could_ become 
> initialized before the DW_AT_decl_line. 
> 
> So we don't want to pretend we know better than the compiler when displaying 
> debug information. But even if the compiler does emit better debug 
> information that does give correct location expressions, we would still show 
> the variable because it is in scope. LLDB does only show variables that are 
> in lexical scope currently in Xcode, lldb-vscode, lldb, and Android Studio 
> AFAIK. What debugger are you using?
> 
> Greg
>> 
>> ___
>> 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

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

[Greg Clayton via lldb-dev]

> On Apr 19, 2021, at 12:59 AM, Michał Górny via lldb-dev 
>  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