> On Feb 23, 2015, at 1:35 PM, Greg Clayton <[email protected]> wrote: > >> >> On Feb 23, 2015, at 12:37 PM, Keno Fischer <[email protected]> >> wrote: >> >> Hi Greg, >> >> thank you so much for your detailed explanation, much appreciated. That >> makes a lot of sense. >> I'm still confused why the register definitions are duplicated in so many >> places though (in the non gdb-remote case, I guess). >> The ABI has a copy, the Process has a copy and even in Process/Utility there >> seems to be some confusion about how things are organized (some platforms >> have a RegisterInfoInterface, some just fold that into the RegisterContext). >> Is this just historical? > > There are many register numbers. One kind is DWARF register numbers for when > a variable says "my value is in register 12". Each ABI usually specifies what > the DWARF register numbers are for each registers. So the ABI can in fact > answer "what is the DWARF register number for 'rax'". It just can't answer > what order the registers are in and in what groupings they come in (GPR, FPU, > Exception?, or all registers in one big buffer). > >> If so what's the preferred way to do these things now. > > I would still like to have things specified manually.
What I meant here is have the GDB server specify things so LLDB can dynamically get the info from the GBD server. > This way you could ship a compiler + lldb that all works together. Then you > modify the compiler and it changes the DWARF register numbers, but when you > ship the tools they all go together. 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. > >> Second, in the gdb-remote case, wouldn't it make sense to give the >> GDBRemoteRegisterContext an optional RegisterInfoInterface that it could use >> if the dynamic info is not available. Given that we have to do this for the >> old iOS case anyway, wouldn't that be a cleaner abstraction? > > Not really. We have dealt with changing ARM registers over the years with iOS > and by far the best thing we did was have the "debugserver" binary on the > device tell us what registers are available since it makes things really > simple. If not, we have to get the CPUID from the chip and try to figure out > which generation it was and then figure out what registers were available > with kernel version 1.2.3. So we let the low level software that runs on a > device figure it out as it often has access to sysctl() and many other local > functions that help it to determine what registers are available. Otherwise > you must allow the code on the remote side of this (LLDB) figure it out by > calling down through the GDB remote interface and possibly having to add > packets to return the results of a sysctl() call, or call any other system > functions. It just makes more sense to determine this on the device in the > GDB server since it it always on the device in question. > > Greg Clayton > >> >> Thanks, >> Keno >> >> On Mon, Feb 23, 2015 at 2:13 PM, Greg Clayton <[email protected]> wrote: >> >>> 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 reg! i! > sters 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 _______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
