[lldb-dev] Is qRegisterInfo required

[Keno Fischer]

Thanks again Greg, really appreciate you taking the time to answer my
questions.

I'll commit some clarification to lldb-for-gdb-remote.txt later.

To play devil's advocate, one last question. Why does the ABI plugin have
to have register information at all? If we agree hardcoding this is a bad
idea, shouldn't it always ask the process for this information?

On Mon, Feb 23, 2015 at 6:20 PM, Greg Clayton <gclayton at apple.com> wrote:

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