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?
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
