> On Feb 21, 2015, at 8:48 PM, Keno Fischer <[email protected]> > wrote: > > Hello everyone, > > I'm playing around with having lldb connect to a custom gdbserver (which > doesn't support the > qRegisterInfo query). I started out by writing a simple stub ABI plugin that > defines the register > table for my target, but reading further through the code, I'm somewhat > confused by the separation of concerns here. In particular, it seems like > having the gdbserver provide qRegisterInfo is required unless runnning on ARM > in which case GDBRemoteDynamicRegisterInfo::HardcodeARMRegisters will add it > using has a copy of the Register table from the ABI.
This was only for backward compatibility with older iOS devices whose debugserver didn't support the qRegisterInfo packet. > I was under the impression that supporting qRegisterInfo was a good idea if > registers ever change/get added but was not required and LLDB would fall back > on the ABI plugin. > Is that not the case? And if not, why not? How could the ABI tell you what registers are available through the interface? For example, on ARM, which registers will be available? R0-15, CPSR? Most probably. R8_fiq-R15_fiq? Only if you are debugging something that supports protected mode debugging like JTAG drivers. R13_sys and R14_sys and cpsr_sys? Again only if you have something that supports protected mode debugging. What order would those registers come in? R0 - R15 followed by CPSR? Maybe. Maybe CPSR, then R0-R15. Does R8_fiq-R15_fiq come next or does R13_sys and R14_sys and cpsr_sys? There is no way to tell. Each OS and interface always represents the registers contexts that are pushed differently. If you connect to newer ARM cores you might have BVR/BCR debug registers (JTAG), you might not (user space debugging sometimes doesn't expose these at a thread level because the OS doesn't support them in their thread contexts. So the ABI is absolutely no help is telling you how a OS or emulator will stores its regist! ers contexts. The old state of things was: custom build a GDB for your architecture with hard coded register contexts. Do the same for your GDB-remote binary which has the same hard coded notion of register. If the two do not match, you are hosed. The other problem is that as you were developing support for your binary, you compiler might change and use different register numbers for DWARF, EH frame and more. Allowing dynamic register info gets us out of all these issues. If your compiler numbers changes, you would need to go and change GDB and GDB-server and recompile and make sure to use the right copies of the binaries. The new state of things is: the GDB remote server should tell you what registers it can provide dynamically so we don't run into the above case. There is one section of hard coded registers that for ARM on iOS due to us not being able to ever change the debugserver for older iOS releases. Other than that you have two options: 1 - add support for the qRegisterInfo and dynamically tell LLDB about your registers 2 - make a target definition file that defines the registers your GDB remote binary supports and set the settings: See example target definition python files by doing: % svn cat http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/x86_64_linux_target_definition.py % svn cat http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/x86_64_qemu_target_definition.py % svn cat http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/x86_64_target_definition.py Then set your target definition file: (lldb) settings set plugin.process.gdb-remote.target-definition-file /tmp/my_target_definition.py Then attach and debug. If your GDB remote binary supports qRegisterInfo it will still use that, but if it doesn't, it will fall back to using the target-definition-file you specify in the setting. Let me know if you have more questions. Greg Clayton _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
