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]<mailto:[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]>
[mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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<http://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]<mailto:[email protected]>
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
_______________________________________________
lldb-dev mailing list
[email protected]<mailto:[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
