<div dir="ltr">Everything works! It was the "generic:<reg>" pair that was missing... I missed it somehow when implementing the "qRegisterInfo" packet response.<div><br></div><div>I have two last questions (hopefully...):</div>
<div>1. In our backend we currently place the initial breakpoint at:</div><div><div><font face="courier new, monospace">* thread #1: tid = 0x0707, 0x00007fff679ae028 dyld`_dyld_start, stop reason = signal SIGINT</font></div>
<div><font face="courier new, monospace"> frame #0: 0x00007fff679ae028 dyld`_dyld_start</font></div></div><div><div><br></div><div style>Which doesn't seem right on OSX since when I try to continue it stops again at:</div>
</div><div style><div><font face="courier new, monospace">* thread #1: tid = 0x0707, 0x00007fff679ba6e6 dyld`gdb_image_notifier(dyld_image_mode, unsigned int, dyld_image_info const*) + 1, stop reason = signal SIGTRAP</font></div>
<div><font face="courier new, monospace"> frame #0: 0x00007fff679ba6e6 dyld`gdb_image_notifier(dyld_image_mode, unsigned int, dyld_image_info const*) + 1</font></div><div><br></div><div style>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?</div>
<div style><br></div><div style>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?</div>
<div style><br></div><div style>Thanks again for all the great assistance,</div><div style>Benjamin.</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 12, 2013 at 7:58 PM, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On Feb 12, <a href="tel:2013" value="+9722013">2013</a>, at 7:19 AM, Benjamin Kemper <<a href="mailto:kemperbenny@gmail.com">kemperbenny@gmail.com</a>> wrote:<br>
<br>
> Greg,<br>
><br>
> First of all thanks for the highly informative answers!<br>
><br>
> 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...<br>
><br>
> 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:<br>
> <lldb.process.gdb-remote.async> < 78> read packet: $T0b06:cce2f16cff7f0000;07:28df8e52ff7f0000;10:0000000000000000;thread:707;#15<br>
><br>
> 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.<br>
<br>
</div>Have you implemented the qHostInfo packet?<br>
<br>
send packet: $qHostInfo#00<br>
read packet: $cputype:16777223;cpusubtype:3;ostype:macosx;watchpoint_exceptions_received:after;vendor:apple;endian:little;ptrsize:8;#00<br>
<br>
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:<br>
<br>
(lldb) target create --arch x86_64-apple-macosx <EXE><br>
<br>
But it is always better to specify it exactly through the qHostInfo if you can.<br>
<div class="im"><br>
><br>
> 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?<br>
<br>
</div>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.<br>
<div class="im"><br>
> Also, to implement the "qShlibInfoAddr" packet I've used the following snippet:<br>
> struct dyld_all_image_infos* getImageInfosFromKernel<br>
> ()<br>
> {<br>
> task_dyld_info_data_t task_dyld_info;<br>
> mach_msg_type_number_t count = TASK_DYLD_INFO_COUNT;<br>
><br>
><br>
> if<br>
> ( task_info(mach_task_self(), TASK_DYLD_INFO, (task_info_t)&task_dyld_info, &count) ) {<br>
> FAIL(<br>
> "all_image_infos: task_info() failed"<br>
> );<br>
> exit(0);<br>
> }<br>
><br>
> return (struct<br>
> dyld_all_image_infos*)(uintptr_t)task_dyld_info.all_image_info_addr;<br>
> }<br>
><br>
> Does it get the required address for the result packet?<br>
<br>
</div>Yes, but you wouldn't want to exit(0) if you failed to get the info right? Just return an invalid address.<br>
<br>
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.<br>
<div class="HOEnZb"><div class="h5">><br>
> Thanks in advance,<br>
> Benjamin.<br>
><br>
><br>
> On Mon, Feb 11, <a href="tel:2013" value="+9722013">2013</a> at 8:33 PM, Greg Clayton <<a href="mailto:gclayton@apple.com">gclayton@apple.com</a>> wrote:<br>
><br>
> On Feb 10, <a href="tel:2013" value="+9722013">2013</a>, at 6:58 AM, Benjamin Kemper <<a href="mailto:kemperbenny@gmail.com">kemperbenny@gmail.com</a>> wrote:<br>
><br>
> > 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:<br>
> > <lldb.driver.main-thread> < 18> send packet: $m1039ede00,200#86<br>
> > 1 <lldb.driver.main-thread> < 1> read packet: +<br>
> > 0 <lldb.driver.main-thread> <1028> read packet: $4b4c5752000000000000000000000000c04e0000014e0000004e000000000000000000000000000010de9e030100000014de9e030100000018de9e030100000020<br>
> > 1 <lldb.driver.main-thread> < 1> send packet: +<br>
> > 2 <lldb.driver.main-thread> < 18> send packet: $m1038d4200,200#21<br>
> > 3 <lldb.driver.main-thread> < 1> read packet: +<br>
> > 4 <lldb.driver.main-thread> <1028> read packet: $e97bf4ffff6666666666662e0f1f8400000000009090909090909090909090909090909090909090909090909090909090909090909090909090909090909090e9<br>
> > 5 <lldb.driver.main-thread> < 1> send packet: +<br>
> > 6 <lldb.driver.main-thread> < 21> send packet: $Z0,7fff5fc0d6e5,1#de<br>
> > 7 <lldb.driver.main-thread> < 1> read packet: +<br>
> > 8 <lldb.driver.main-thread> < 6> read packet: $OK#9a<br>
> > 9 <lldb.driver.main-thread> < 1> send packet: +<br>
> > 10 <lldb.driver.main-thread> < 16> send packet: $qfThreadInfo#bb<br>
> > 11 <lldb.driver.main-thread> < 1> read packet: +<br>
> > 12 <lldb.driver.main-thread> < 8> read packet: $m707#0b<br>
> > 13 <lldb.driver.main-thread> < 1> send packet: +<br>
> > 14 <lldb.driver.main-thread> < 16> send packet: $qsThreadInfo#c8<br>
> > 15 <lldb.driver.main-thread> < 1> read packet: +<br>
> > 16 <lldb.driver.main-thread> < 5> read packet: $l#6c<br>
> > 17 <lldb.driver.main-thread> < 1> send packet: +<br>
> > 18 <lldb.driver.main-thread> < 18> send packet: $z0,1005f00d7,1#5a<br>
> > 19 <lldb.driver.main-thread> < 1> read packet: +<br>
> > 20 <lldb.driver.main-thread> < 6> read packet: $OK#9a<br>
> > 21 <lldb.driver.main-thread> < 1> send packet: +<br>
> > 22 <lldb.driver.main-thread> < 21> send packet: $z0,7fff5fc0d6e5,1#fe<br>
> > 23 <lldb.driver.main-thread> < 1> read packet: +<br>
> > 24 <lldb.driver.main-thread> < 6> read packet: $OK#9a<br>
> > 25 <lldb.driver.main-thread> < 1> send packet: +<br>
> > 26 <lldb.driver.main-thread> < 5> send packet: $k#6b<br>
> > 27 <lldb.driver.main-thread> < 1> read packet: +<br>
> > 28 <lldb.driver.main-thread> < 6> read packet: $OK#9a<br>
> > 29 <lldb.driver.main-thread> < 1> send packet: +<br>
> > 30 6> send packet: $p2#a2<br>
> > 31 <lldb.driver.main-thread> < 1> read packet: +<br>
> > 32 <lldb.driver.main-thread> < 4> read packet: $#00<br>
> > 33 <lldb.driver.main-thread> < 1> send packet: +<br>
> > 34 <lldb.driver.main-thread> < 6> send packet: $p3#a3<br>
> ><br>
> > Here are my commands in the lldb console:<br>
> > ➜ build lldb /bin/ls<br>
> > Current executable set to '/bin/ls' (x86_64).<br>
> > (lldb) log enable -f /tmp/packets.txt gdb-remote packets<br>
> > (lldb) process connect -p gdb-remote connect://localhost:58985<br>
> > Process 1799 stopped<br>
> > * thread #1: tid = 0x0707, , stop reason = signal SIGINT<br>
> > frame #0:<br>
> > (lldb)<br>
> ><br>
> > Why might LLDB send the 'kill' command without "permission"?<br>
><br>
> 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.<br>
><br>
> ><br>
> > The weird thing is that after it sends the kill command, it then start requesting for register values using the '$p' commands...<br>
> ><br>
> > Any ideas why this is happening?<br>
> ><br>
><br>
> No, none at all. You will need to debug this. The only place the "k" packet is sent is from inside:<br>
><br>
> ProcessGDBRemote::DoDestroy ()<br>
><br>
> 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:<br>
><br>
> (lldb) log enable --stack -f /tmp/process.txt gdb-remote process<br>
><br>
> You should then see a stack backtrace to see who is calling DoDestroy()...<br>
><br>
> ><br>
> ><br>
> > On Sun, Feb 10, 2013 at 3:19 PM, Benjamin Kemper <<a href="mailto:kemperbenny@gmail.com">kemperbenny@gmail.com</a>> wrote:<br>
> > Hi,<br>
> ><br>
> > I'm implementing a debugger backend that implements the gdb remote protocol and adding extensions to support LLDB also.<br>
> ><br>
> > 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.<br>
> ><br>
> > Is there a special reason why it uses multiple packets instead of one?<br>
> ><br>
> > 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?<br>
> ><br>
> > Thanks,<br>
> > Benjamin.<br>
> ><br>
> > _______________________________________________<br>
> > lldb-dev mailing list<br>
> > <a href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a><br>
> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div>