[lldb-dev] LLDB use of G/g packets
Benjamin Kemper
kemperbenny at gmail.com
Tue Feb 12 07:19:11 PST 2013
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.
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?
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?
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/20130212/93d80bc3/attachment.html>
More information about the lldb-dev
mailing list