On Aug 26, 2013, at 6:09 PM, Sebastien Metrot <[email protected]> wrote:
> If I understand correctly 1 and 3 implies modifying the android gdbserver > while 2 could be done entirely in lldb? yes > Having gdbserver changes accepted by the maintainers and integrated in future > builds of android and/or the NDK looks like a hard path to walk. > Also I have looked at the gdbserver sources of the current android (found > here https://android.googlesource.com/toolchain/gdb/ ) and a couple of greps > seems to indicate that xmlRegisters is only supported on x86 although > register definition xmls exists for many arm/linux variants. > In this light 2 seems like a good short term solution to force a register > mapping on lldb by reading the xml from the gdb sources We will need an XML file with all the right data, which is more than what is in the GDB sources. We need compiler register numbers (for EH frame decoding) and DWARF register numbers for debug info parsing, and generic register info (which reg is the PC, SP, FP, etc). The compiler and DWARF register numbers don't always match (i386 has EBP and ESP different between the compiler and DWARF reg nuns). > , until 1 is finally implemented in both projects and lldb is able to detect > the register mapping. Sure. > > Is that correct? Yes. So the theory would be: 1 - Create an XML register definition file format (or modify the GDB one to include the data we need) 2 - set the setting in LLDB prior to connecting: (lldb) settings set plugin.process.gdb-remote.register-definition-file /tmp/registers.xml 3 - run and debug and LLDB would use the registers defined in "/tmp/registers.xml" if qRegisterInfo packet is not supported by the GDB server we connect to. This this means adding a setting and modifying GDBRemoteDynamicRegisterInfo to have a new method that can import register data from the XML file from step 1. Greg > > On 26 Aug 2013, at 19:34 , Greg Clayton <[email protected]> wrote: > >> The problem is we don't know the registers. GDB assumes that the GDB that is >> being used knows what registers are on the other side of the remote >> connection. New GDB binaries and GDBSERVER binaries are compiled for each >> target. LLDB has one binary for all systems. So LLDB expects to be able to >> query the GDBSERVER for the register information. LLDB has defined new >> packets to get this information. We have documented the packets we added: >> >> svn cat http://llvm.org/svn/llvm-project/lldb/trunk/docs/lldb-gdb-remote.txt >> >> I believe there is a way defined in the remote protocol to query for >> registers using the "qXfer" command with the "xmlRegisters" gdb feature. We >> haven't added support for this, but the "XML target description" format is >> missing information we need. The details on this are at: >> >> https://sourceware.org/gdb/onlinedocs/gdb/Target-Description-Format.html#Target-Description-Format >> >> It could also be easily extended to support giving us the information >> required. >> >> So, in order to get things going you will need to do one of the following: >> 1 - add support for the qRegisterInfo packet (easiest) >> 2 - add a new "settings set" setting for the "gdb-remote" plug-in that >> contains a path to a register description file. The file format should be >> something parseable like XML and you would need to write a parser for it and >> parse the contents by adding a method to the GDBRemoteDynamicRegisterInfo >> class (harder) >> 3 - If the current gdbserver for android does support the "XML target >> description", we would need to modify the GDBRemoteCommunicationClient class >> to be able to retrieve the information and parse the XML. You would then >> need to modify the gdbserver for android to add extra data we need to the >> register info (compiler register numbers for each register if one exists, >> DWARF register numbers, generic register info) (hardest) >> >> I think option 1 or 2 would be the easiest. >> >> Greg >> >> On Aug 25, 2013, at 10:53 AM, Sebastien Metrot <[email protected]> wrote: >> >>> Hi, >>> >>> I have started to investigate connecting lldb to gdbserver running on an >>> android device (arm). It connects correctly, I'm able to start the remote >>> program and interrupt it but lldb doesn't permit me to access any data as >>> it says the current frame is invalid: >>> >>> mbp:NativeTest meeloo$ lldb >>> ../../../ndk/samples/hello-gl2/libs/armeabi/libgl2jni.so >>> Current executable set to >>> '../../../ndk/samples/hello-gl2/libs/armeabi/libgl2jni.so' (arm). >>> (lldb) gdb-remote >>> error: gdb-remote [<hostname>:]<portnum> >>> (lldb) gdb-remote 127.0.0.1:5039 >>> Process 12260 stopped >>> * thread #1: tid = 0x2fe4, , stop reason = signal SIGTRAP >>> frame #0: >>> (lldb) frame variable >>> error: invalid frame >>> (lldb) continue >>> Process 12260 resuming >>> ---- Here I hit Ctrl+C >>> Process 12260 stopped >>> * thread #1: tid = 0x2fe4, , stop reason = signal SIGINT >>> frame #0: >>> (lldb) continue >>> Process 12260 resuming >>> (lldb) process interrupt >>> Process 12260 stopped >>> * thread #1: tid = 0x2fe4, , stop reason = signal SIGINT >>> frame #0: >>> (lldb) register read >>> error: invalid frame >>> (lldb) process status >>> Process 12260 stopped >>> * thread #1: tid = 0x2fe4, , stop reason = signal SIGINT >>> frame #0: >>> >>> >>> Does anyone have already tried to do this kind of things? I'm trying to get >>> it to work before moving to implementing android support in my program with >>> the C++ API... >>> >>> Thanks in advance, >>> >>> S. >>> >>> _______________________________________________ >>> 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
