[lldb-dev] gdb-remote to android gdbserver

[Virgile Bello]

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 <meeloo at gmail.com> 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 <gclayton at apple.com> 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 <meeloo at gmail.com> 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
> >> lldb-dev at cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> >
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20130827/282bf1fc/attachment.html>