Yes, I suppose a lldb-only change would be much more easier for now. >From what I remember when I tested, hard-coding the ARM registers temporarily + the runtime-length encoding patch (that I will commit soon) was enough to to have a simple address breakpoint working. Backtrace didn't, but I didn't bother investigate further.
On Tue, Aug 27, 2013 at 10:09 AM, 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? 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 >
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
