<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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</div><div><br></div><div><div>//----------------------------------------------------------------------</div><div>// "qRegisterInfo<hex-reg-id>"</div><div>//</div><div>// BRIEF</div><div>//  Discover register information from the remote GDB server.</div><div>//</div><div>// PRIORITY TO IMPLEMENT</div><div>//  High. Any target that can self describe its registers, should do so.</div><div>//  This means if new registers are ever added to a remote target, they</div><div>//  will get picked up automatically, and allows registers to change</div><div>//  depending on the actual CPU type that is used.</div><div>//----------------------------------------------------------------------</div></div><div><br></div><div>to indicate that this is indeed required in order for LLDB to do any debugging with this target? </div><div><br></div><div>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?</div><div><br></div><div>><span style="font-size:12.8000001907349px">We could have a way to specify that the DWARF register number is "ABI", and we could then lookup the ABI register number</span></div><div><span style="font-size:12.8000001907349px">> 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</span></div><div><span style="font-size:12.8000001907349px">> 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</span></div><div><span style="font-size:12.8000001907349px">> to load the dynamic loader plug-in or run any other qHostInfo, qProcessInfo packets to tell us what we are debugging so we </span></div><div><span style="font-size:12.8000001907349px">> might not know.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">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?</span></div></div></div></div>