[lldb-dev] Is qRegisterInfo required

[Greg Clayton]

> On Feb 23, 2015, at 2:45 PM, Keno Fischer <kfischer at college.harvard.edu> wrote:
> 
> Ok, having registers vary between different core versions is an understandable concern and I think the solution is good - I guess I'm lucky in that my targets all have one set of registers that I'm interested in ;). I guess my confusion stemmed from the fact that it seems like adding a new target requires so many things that the register table seemed minor (I understand now that it is not). Would it make sense to edit the lldb-for-gdb-remote.txt, which currently says
> 
> //----------------------------------------------------------------------
> // "qRegisterInfo<hex-reg-id>"
> //
> // BRIEF
> //  Discover register information from the remote GDB server.
> //
> // PRIORITY TO IMPLEMENT
> //  High. Any target that can self describe its registers, should do so.
> //  This means if new registers are ever added to a remote target, they
> //  will get picked up automatically, and allows registers to change
> //  depending on the actual CPU type that is used.
> //----------------------------------------------------------------------
> 
> to indicate that this is indeed required in order for LLDB to do any debugging with this target? 

Yes, other one must reply to the qRegisterInfo packets, or they must create a target definition python file and specify it using the "settings set".

> 
> Also, I still think that some of this stuff is more duplicated than it needs to be. For example, grepping for gcc_dwarf_ymm in the current tree gives three different locations where this is declared, shouldn't that be somehow factored out?

Depends if they are all the same or not. They might differ for some targets. If they are the same, we can centralize them into a single file.
> 
> >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.
> 
> Sorry, I didn't understand this suggestion. What exactly does the ABI register number define?

Your ABI specifies for your target what registers numbers will be used by the compiler for the DWARF register numbers and also the compiler register numbers (which might differ). We have "ABI" plug-ins that help us to determine things like calling conventions when calling functions with multiple arguments (where to put arg1, arg2, arg3, etc), where return values will be (in which registers and if too large for registers where on the stack), and many other aspects of general calling conventions. In order to get an ABI plug-in that could answer the question of "what is the DWARF register number for 'rax'", we need to first find an ABI plug-in using a target triple "x86_64-apple-macosx". When we first connect to a target via GDB remote, we might not know this right away, so we have a chicken/egg problem: "I can't find out about my registers unless you can give me a target triple", or "I can't get my target triple unless I can check if register 'version' is available".


> Is it the one used by the compiler for e.g. eh_frame? Are you suggesting, the ABI plugin specify a mapping from the dwarf to the compiler register numbers but not the full register info table?

DWARF register numbers can differ from EH frame registers numbers. An ABI plug-in for a given triple can usually answer the DWARF and compiler registers numbers, but again, if you hardcode this in the ABI, and if you change your ABI as you are developing it, you would not be able to change things around to test a new compiler with new register numbers without modifying the debugger itself. That sounds like a bad idea to me.

So this all leads to: lets discover the registers dynamically because you don't want to change the debugger if you can avoid it. 

Greg