[lldb-dev] Is qRegisterInfo required

[Keno Fischer]

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?

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?

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