[lldb-dev] LLDB use of G/g packets
Benjamin Kemper
kemperbenny at gmail.com
Wed Feb 13 07:06:59 PST 2013
Everything works! It was the "generic:<reg>" pair that was missing... I
missed it somehow when implementing the "qRegisterInfo" packet response.
I have two last questions (hopefully...):
1. In our backend we currently place the initial breakpoint at:
* thread #1: tid = 0x0707, 0x00007fff679ae028 dyld`_dyld_start, stop reason
= signal SIGINT
frame #0: 0x00007fff679ae028 dyld`_dyld_start
Which doesn't seem right on OSX since when I try to continue it stops again
at:
* thread #1: tid = 0x0707, 0x00007fff679ba6e6
dyld`gdb_image_notifier(dyld_image_mode, unsigned int, dyld_image_info
const*) + 1, stop reason = signal SIGTRAP
frame #0: 0x00007fff679ba6e6 dyld`gdb_image_notifier(dyld_image_mode,
unsigned int, dyld_image_info const*) + 1
And on the next continue it crashes. We have encountered something similar
on Windows where it has a "safe" point from which the debugger is allowed
to connect and I'm guessing that this is also the case in OSX. Where does
LLDB inserts it's first breakpoint?
2. It seems as if LLDB doesn't find the correct PID of the process it
connects to, I always get PID 1799 which doesn't seem right. I didn't see
any packet where this information is communicated in so how does LLDB get
the target process PID?
Thanks again for all the great assistance,
Benjamin.
On Tue, Feb 12, 2013 at 7:58 PM, Greg Clayton <gclayton at apple.com> wrote:
>
> On Feb 12, 2013, at 7:19 AM, Benjamin Kemper <kemperbenny at gmail.com>
> wrote:
>
> > Greg,
> >
> > First of all thanks for the highly informative answers!
> >
> > Regarding the 'kill' command that was sent, I have no idea also why it
> happend, but somewhere during the work day (after a few hours of going
> through LLDB code) it stopped happening...
> >
> > So now LLDB reads all the register values correctly using the `p
> packets, and regarding the expedited registers I believe I already pass
> them with the stop reply, see example:
> > <lldb.process.gdb-remote.async> < 78> read packet:
> $T0b06:cce2f16cff7f0000;07:28df8e52ff7f0000;10:0000000000000000;thread:707;#15
> >
> > I hoped that once LLDB will get all the registers it will be able to
> construct the stack frame but it fails to do so. I thought maybe I'm
> missing the qShlibInfoAddr so I implemented it also but that didn't help
> also.
>
> Have you implemented the qHostInfo packet?
>
> send packet: $qHostInfo#00
> read packet:
> $cputype:16777223;cpusubtype:3;ostype:macosx;watchpoint_exceptions_received:after;vendor:apple;endian:little;ptrsize:8;#00
>
> Maybe we just don't know the target triple (specified by "ostype",
> "vendor" and here the cpu type + subtype) that we are debugging? You can
> get around this by specifying a full triple when you make your target:
>
> (lldb) target create --arch x86_64-apple-macosx <EXE>
>
> But it is always better to specify it exactly through the qHostInfo if you
> can.
>
> >
> > The command I didn't implement yet is "qThreadStopInfo", could this be
> the reason why the stack trace is not constructed or am I missing something
> else?
>
> No, that wouldn't do it. It could be because you didn't fully specify your
> generic registers in the responses to the qRegisterInfo packets. It could
> be due to an unknown target triple that made no dynamic loader plug-in be
> selected. If you can send me a full transcript of all gdb-remote packets
> offline, I will take a look and see what I can figure out.
>
> > Also, to implement the "qShlibInfoAddr" packet I've used the following
> snippet:
> > struct dyld_all_image_infos* getImageInfosFromKernel
> > ()
> > {
> > task_dyld_info_data_t task_dyld_info;
> > mach_msg_type_number_t count = TASK_DYLD_INFO_COUNT;
> >
> >
> > if
> > ( task_info(mach_task_self(), TASK_DYLD_INFO,
> (task_info_t)&task_dyld_info, &count) ) {
> > FAIL(
> > "all_image_infos: task_info() failed"
> > );
> > exit(0);
> > }
> >
> > return (struct
> > dyld_all_image_infos*)(uintptr_t)task_dyld_info.all_image_info_addr;
> > }
> >
> > Does it get the required address for the result packet?
>
> Yes, but you wouldn't want to exit(0) if you failed to get the info right?
> Just return an invalid address.
>
> A few questions for you: what are you trying to debug? What arch? It
> sounds like this is for a user space MacOSX program? The triple specified
> when creating the target and/or from the qHostInfo will help determine
> which shared libraries are loaded and where they are loaded. This will then
> allow LLDB to resolve "load" addresses back into "file" relative addresses
> so we can backtrace.
> >
> > Thanks in advance,
> > Benjamin.
> >
> >
> > On Mon, Feb 11, 2013 at 8:33 PM, Greg Clayton <gclayton at apple.com>
> wrote:
> >
> > On Feb 10, 2013, at 6:58 AM, Benjamin Kemper <kemperbenny at gmail.com>
> wrote:
> >
> > > I noticed something that I've missed when sending the previous Email.
> Looking at the logs, I see LLDB sending "kill" command for no reason:
> > > <lldb.driver.main-thread> < 18> send packet: $m1039ede00,200#86
> > > 1 <lldb.driver.main-thread> < 1> read packet: +
> > > 0 <lldb.driver.main-thread> <1028> read packet:
> $4b4c5752000000000000000000000000c04e0000014e0000004e000000000000000000000000000010de9e030100000014de9e030100000018de9e030100000020
> > > 1 <lldb.driver.main-thread> < 1> send packet: +
> > > 2 <lldb.driver.main-thread> < 18> send packet: $m1038d4200,200#21
> > > 3 <lldb.driver.main-thread> < 1> read packet: +
> > > 4 <lldb.driver.main-thread> <1028> read packet:
> $e97bf4ffff6666666666662e0f1f8400000000009090909090909090909090909090909090909090909090909090909090909090909090909090909090909090e9
> > > 5 <lldb.driver.main-thread> < 1> send packet: +
> > > 6 <lldb.driver.main-thread> < 21> send packet: $Z0,7fff5fc0d6e5,1#de
> > > 7 <lldb.driver.main-thread> < 1> read packet: +
> > > 8 <lldb.driver.main-thread> < 6> read packet: $OK#9a
> > > 9 <lldb.driver.main-thread> < 1> send packet: +
> > > 10 <lldb.driver.main-thread> < 16> send packet: $qfThreadInfo#bb
> > > 11 <lldb.driver.main-thread> < 1> read packet: +
> > > 12 <lldb.driver.main-thread> < 8> read packet: $m707#0b
> > > 13 <lldb.driver.main-thread> < 1> send packet: +
> > > 14 <lldb.driver.main-thread> < 16> send packet: $qsThreadInfo#c8
> > > 15 <lldb.driver.main-thread> < 1> read packet: +
> > > 16 <lldb.driver.main-thread> < 5> read packet: $l#6c
> > > 17 <lldb.driver.main-thread> < 1> send packet: +
> > > 18 <lldb.driver.main-thread> < 18> send packet: $z0,1005f00d7,1#5a
> > > 19 <lldb.driver.main-thread> < 1> read packet: +
> > > 20 <lldb.driver.main-thread> < 6> read packet: $OK#9a
> > > 21 <lldb.driver.main-thread> < 1> send packet: +
> > > 22 <lldb.driver.main-thread> < 21> send packet: $z0,7fff5fc0d6e5,1#fe
> > > 23 <lldb.driver.main-thread> < 1> read packet: +
> > > 24 <lldb.driver.main-thread> < 6> read packet: $OK#9a
> > > 25 <lldb.driver.main-thread> < 1> send packet: +
> > > 26 <lldb.driver.main-thread> < 5> send packet: $k#6b
> > > 27 <lldb.driver.main-thread> < 1> read packet: +
> > > 28 <lldb.driver.main-thread> < 6> read packet: $OK#9a
> > > 29 <lldb.driver.main-thread> < 1> send packet: +
> > > 30 6> send packet: $p2#a2
> > > 31 <lldb.driver.main-thread> < 1> read packet: +
> > > 32 <lldb.driver.main-thread> < 4> read packet: $#00
> > > 33 <lldb.driver.main-thread> < 1> send packet: +
> > > 34 <lldb.driver.main-thread> < 6> send packet: $p3#a3
> > >
> > > Here are my commands in the lldb console:
> > > ➜ build lldb /bin/ls
> > > Current executable set to '/bin/ls' (x86_64).
> > > (lldb) log enable -f /tmp/packets.txt gdb-remote packets
> > > (lldb) process connect -p gdb-remote connect://localhost:58985
> > > Process 1799 stopped
> > > * thread #1: tid = 0x0707, , stop reason = signal SIGINT
> > > frame #0:
> > > (lldb)
> > >
> > > Why might LLDB send the 'kill' command without "permission"?
> >
> > You will need to debug the LLDB sources to see why this isn't being
> sent. I know of no reason why this should be happening, so this is probably
> a bug.
> >
> > >
> > > The weird thing is that after it sends the kill command, it then start
> requesting for register values using the '$p' commands...
> > >
> > > Any ideas why this is happening?
> > >
> >
> > No, none at all. You will need to debug this. The only place the "k"
> packet is sent is from inside:
> >
> > ProcessGDBRemote::DoDestroy ()
> >
> > There is logging that can be enabled. Add the "process" category to the
> "gdb-remote" logging and use the "--stack" option to print out a backtrace:
> >
> > (lldb) log enable --stack -f /tmp/process.txt gdb-remote process
> >
> > You should then see a stack backtrace to see who is calling
> DoDestroy()...
> >
> > >
> > >
> > > On Sun, Feb 10, 2013 at 3:19 PM, Benjamin Kemper <
> kemperbenny at gmail.com> wrote:
> > > Hi,
> > >
> > > I'm implementing a debugger backend that implements the gdb remote
> protocol and adding extensions to support LLDB also.
> > >
> > > I've added support for the qRegisterInfo packet and I've noticed in
> the logs that LLDB uses the p/P packets instead of the G/g packets.
> > >
> > > Is there a special reason why it uses multiple packets instead of one?
> > >
> > > Maybe I didn't implement enough "information" packets and LLDB doesn't
> know how to read g/G packets? If so, what packets are missing?
> > >
> > > Thanks,
> > > Benjamin.
> > >
> > > _______________________________________________
> > > 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/20130213/2ac194ae/attachment.html>
More information about the lldb-dev
mailing list