[lldb-dev] Is qRegisterInfo required

[Keno Fischer]

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? If so what's the preferred way
to do these things now. 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?

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 registers 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150223/a91c6922/attachment.html>