Great, thanks for testing/cleaning it!
On Wed, Aug 28, 2013 at 7:37 PM, Abid, Hafiz <[email protected]> wrote: > I committed part of your patch that handles the RLE after cleaning it a > bit and testing. I noticed though that expanding RLE at this point has a > little problem. Packet log shows the un-expanded packet. I will fix it > separately.**** > > ** ** > > Regards,**** > > Abid**** > > ** ** > > *From:* Virgile Bello [mailto:[email protected]] > *Sent:* 27 August 2013 18:17 > > *To:* Abid, Hafiz > *Cc:* Sebastien Metrot; lldb-dev > *Subject:* Re: [lldb-dev] gdb-remote to android gdbserver**** > > ** ** > > Great, thanks!**** > > ** ** > > Hope it will work out, esp. the escaping at encoding time that has never > been tested (but well, if there is no special characters it should be fine). > **** > > If special characters proves to be useless or causing issues, I have a > much smaller version just doing the RLE part (basically, encoding part > disappear and decoding just test for "*").**** > > ** ** > > Virgile**** > > ** ** > > On Wed, Aug 28, 2013 at 2:08 AM, Abid, Hafiz <[email protected]> > wrote:**** > > Virgile,**** > > Thanks for the patch. You choose a better place to decode the RLE. I am > not sure about escape character though as gdbserver does not seem to use > them for normal packets. The data byte is encoded in as 2-digit asci > character. For example, this is a response to a g packet request.**** > > **** > > putpkt ("$2a0*}0*)40e2f*"7f0*S20*hb0b6ddf7ff7f0*"020* 330*"2b0*}0*}0* > 7f030*(f* 0*}0*}0*}0*}0*}0*c801f0* 3b0*}0*}0*}0*}0*}0*E#c8"); [noack mode] > **** > > **** > > and initial part of how gdb decoded it.**** > > > 2a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000040e2 > **** > > **** > > I will test the RLE part of your patch. If that is ok then I will merge it. > **** > > **** > > Thanks,**** > > Abid**** > > **** > > *From:* Virgile Bello [mailto:[email protected]] > *Sent:* 27 August 2013 16:29 > *To:* Abid, Hafiz > *Cc:* Sebastien Metrot; lldb-dev**** > > > *Subject:* Re: [lldb-dev] gdb-remote to android gdbserver**** > > **** > > Hello,**** > > **** > > Sorry, since I also had a RLE patch pending, here it is in case it is > useful (before it's too late).**** > > Hope we can merge both of them together maybe?**** > > **** > > This one also tries to handle escaped characters (#, $ and }), when > receiving and sending.**** > > Did it from http://sourceware.org/gdb/onlinedocs/gdb/Overview.html**** > > Also, it converts everything where the packet copy was happening, to avoid > extra copy and O(n) insertion.**** > > **** > > Not sure if checksum is supposed to work on the escaped version or not. > Need to check how GDB is working (spec doesn't say anything).**** > > **** > > I didn't have a chance to test it again since I added character escaping, > so I should probably do that again in case there is real interest in it.** > ** > > Also couldn't polish it as I intended, but thought it would still be more > useful as is before the other one get merged than after.**** > > **** > > Sincerely,**** > > Virgile**** > > **** > > On Tue, Aug 27, 2013 at 6:51 PM, Abid, Hafiz <[email protected]> > wrote:**** > > I have been working in the last few weeks on making LLDB working with > gdbserver on Linux host. Some of the things that I noted missing are.**** > > **** > > 1. Run length encoding as already mentioned. I have a patch for it > that I will submit shortly.**** > > 2. I had to hardcode the registers for x86_64 as gdbserver does not > support qRegisterInfo.**** > > 3. Make sure to use g/G packets for registers.**** > > **** > > After that I had a working connection. But then I noticed the following 2 > problem.**** > > PC is not decremented by length of breakpoint instruction after target > stops.**** > > LLDB failing to recognize a breakpoint is for stepping and stopping before > a source level step was really complete.**** > > **** > > I am working on these 2 issues.**** > > **** > > Regards,**** > > Abid **** > > **** > > *From:* [email protected] [mailto:[email protected]] > *On Behalf Of *Virgile Bello > *Sent:* 27 August 2013 02:34 > *To:* Sebastien Metrot > *Cc:* lldb-dev > *Subject:* Re: [lldb-dev] gdb-remote to android gdbserver**** > > **** > > 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
