If I understand correctly 1 and 3 implies modifying the android gdbserver while 2 could be done entirely in lldb? 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, until 1 is finally implemented in both projects and lldb is able to detect the register mapping.
Is that correct? S. 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
