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 <[email protected]> wrote: > > > On Feb 23, 2015, at 2:45 PM, Keno Fischer <[email protected]> > 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 > >
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
