[lldb-dev] Is qRegisterInfo required

Mon Feb 23 13:46:56 PST 2015

> On Feb 23, 2015, at 1:35 PM, Greg Clayton <gclayton at apple.com> wrote:
> 
>> 
>> On Feb 23, 2015, at 12:37 PM, Keno Fischer <kfischer at college.harvard.edu> wrote:
>> 
>> Hi Greg,
>> 
>> thank you so much for your detailed explanation, much appreciated. That makes a lot of sense.
>> I'm still confused why the register definitions are duplicated in so many places though (in the non gdb-remote case, I guess).
>> The ABI has a copy, the Process has a copy and even in Process/Utility there seems to be some confusion about how things are organized (some platforms have a RegisterInfoInterface, some just fold that into the RegisterContext). Is this just historical?
> 
> There are many register numbers. One kind is DWARF register numbers for when a variable says "my value is in register 12". Each ABI usually specifies what the DWARF register numbers are for each registers. So the ABI can in fact answer "what is the DWARF register number for 'rax'". It just can't answer what order the registers are in and in what groupings they come in (GPR, FPU, Exception?, or all registers in one big buffer).
> 
>> If so what's the preferred way to do these things now.
> 
> I would still like to have things specified manually.

What I meant here is have the GDB server specify things so LLDB can dynamically get the info from the GBD server.

> This way you could ship a compiler + lldb that all works together. Then you modify the compiler and it changes the DWARF register numbers, but when you ship the tools they all go together. We could have a way to specify that the DWARF register number is "ABI", and we could then lookup the ABI register number by checking with the "ABI" plug-in. The main issue I see with that is when we connect to a remote GDB server, we often stop for the first time, then we run the qRegisterInfo packets. We might not have an ABI plug-in yet because we haven't been able to load the dynamic loader plug-in or run any other qHostInfo, qProcessInfo packets to tell us what we are debugging so we might not know. 
> 
>> Second, in the gdb-remote case, wouldn't it make sense to give the GDBRemoteRegisterContext an optional RegisterInfoInterface that it could use if the dynamic info is not available. Given that we have to do this for the old iOS case anyway, wouldn't that be a cleaner abstraction? 
> 
> Not really. We have dealt with changing ARM registers over the years with iOS and by far the best thing we did was have the "debugserver" binary on the device tell us what registers are available since it makes things really simple. If not, we have to get the CPUID from the chip and try to figure out which generation it was and then figure out what registers were available with kernel version 1.2.3. So we let the low level software that runs on a device figure it out as it often has access to sysctl() and many other local functions that help it to determine what registers are available. Otherwise you must allow the code on the remote side of this (LLDB) figure it out by calling down through the GDB remote interface and possibly having to add packets to return the results of a sysctl() call, or call any other system functions. It just makes more sense to determine this on the device in the GDB server since it it always on the device in question.
> 
> Greg Clayton
> 
>> 
>> Thanks,
>> Keno
>> 
>> On Mon, Feb 23, 2015 at 2:13 PM, Greg Clayton <gclayton at apple.com> wrote:
>> 
>>> On Feb 21, 2015, at 8:48 PM, Keno Fischer <kfischer at college.harvard.edu> wrote:
>>> 
>>> Hello everyone,
>>> 
>>> I'm playing around with having lldb connect to a custom gdbserver (which doesn't support the
>>> qRegisterInfo query). I started out by writing a simple stub ABI plugin that defines the register
>>> table for my target, but reading further through the code, I'm somewhat confused by the separation of concerns here. In particular, it seems like having the gdbserver provide qRegisterInfo is required unless runnning on ARM in which case GDBRemoteDynamicRegisterInfo::HardcodeARMRegisters will add it using has a copy of the Register table from the ABI.
>> 
>> This was only for backward compatibility with older iOS devices whose debugserver didn't support the qRegisterInfo packet.
>> 
>> 
>>> I was under the impression that supporting qRegisterInfo was a good idea if registers ever change/get added but was not required and LLDB would fall back on the ABI plugin.
>>> Is that not the case? And if not, why not?
>> 
>> How could the ABI tell you what registers are available through the interface? For example, on ARM, which registers will be available? R0-15, CPSR? Most probably. R8_fiq-R15_fiq? Only if you are debugging something that supports protected mode debugging like JTAG drivers. R13_sys and R14_sys and cpsr_sys? Again only if you have something that supports protected mode debugging. What order would those registers come in? R0 - R15 followed by CPSR? Maybe. Maybe CPSR, then R0-R15. Does R8_fiq-R15_fiq come next or does R13_sys and R14_sys and cpsr_sys? There is no way to tell. Each OS and interface always represents the registers contexts that are pushed differently. If you connect to newer ARM cores you might have BVR/BCR debug registers (JTAG), you might not (user space debugging sometimes doesn't expose these at a thread level because the OS doesn't support them in their thread contexts. So the ABI is absolutely no help is telling you how a OS or emulator will stores its regi!
> sters contexts.
>> 
>> The old state of things was: custom build a GDB for your architecture with hard coded register contexts. Do the same for your GDB-remote binary which has the same hard coded notion of register. If the two do not match, you are hosed. The other problem is that as you were developing support for your binary, you compiler might change and use different register numbers for DWARF, EH frame and more. Allowing dynamic register info gets us out of all these issues. If your compiler numbers changes, you would need to go and change GDB and GDB-server and recompile and make sure to use the right copies of the binaries.
>> 
>> The new state of things is: the GDB remote server should tell you what registers it can provide dynamically so we don't run into the above case. There is one section of hard coded registers that for ARM on iOS due to us not being able to ever change the debugserver for older iOS releases. Other than that you have two options:
>> 
>> 1 - add support for the qRegisterInfo and dynamically tell LLDB about your registers
>> 2 - make a target definition file that defines the registers your GDB remote binary supports and set the settings:
>> 
>> See example target definition python files by doing:
>> 
>> % svn cat http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/x86_64_linux_target_definition.py
>> % svn cat http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/x86_64_qemu_target_definition.py
>> % svn cat http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/x86_64_target_definition.py
>> 
>> 
>> Then set your target definition file:
>> 
>> (lldb) settings set plugin.process.gdb-remote.target-definition-file /tmp/my_target_definition.py
>> 
>> Then attach and debug. If your GDB remote binary supports qRegisterInfo it will still use that, but if it doesn't, it will fall back to using the target-definition-file you specify in the setting.
>> 
>> Let me know if you have more questions.
>> 
>> Greg Clayton
>> 
>> 
> 
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev