<div dir="ltr">Greg,<div><br></div><div>First of all thanks for the highly informative answers!</div><div><br></div><div>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... </div>
<div><br></div><div>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:<div class="gmail_extra">
<font face="courier new, monospace"><lldb.process.gdb-remote.async> < 78> read packet: $T0b06:cce2f16cff7f0000;07:28df8e52ff7f0000;10:0000000000000000;thread:707;#15</font></div>
<div class="gmail_extra"><br></div><div class="gmail_extra" style>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. </div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>The command I didn't implement yet is "<span style="font-family:arial,sans-serif;font-size:13px">qThreadStopInfo", could this be the reason why the stack trace is not constructed or am I missing something else?</span></div>
<div class="gmail_extra" style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div class="gmail_extra" style><span style="font-family:arial,sans-serif;font-size:13px">Also, to implement the "</span>qShlibInfoAddr" packet I've used the following snippet:</div>
<div class="gmail_extra" style><pre style="color:rgb(0,0,0)"><span class="" style="font-weight:bold;color:rgb(34,139,34)">struct</span> dyld_all_image_infos* <span class="" style="font-weight:bold;color:rgb(0,0,255)">getImageInfosFromKernel</span>()
{
task_dyld_info_data_t task_dyld_info;
mach_msg_type_number_t count = TASK_DYLD_INFO_COUNT;
<span class="" style="font-weight:bold;color:rgb(160,32,240)">if</span> ( task_info(mach_task_self(), TASK_DYLD_INFO, (task_info_t)&task_dyld_info, &count) ) {
FAIL(<span class="" style="font-weight:bold;color:rgb(188,143,143)">"all_image_infos: task_info() failed"</span>);
exit(0);
}
<span class="" style="font-weight:bold;color:rgb(160,32,240)">return</span> (<span class="" style="font-weight:bold;color:rgb(34,139,34)">struct</span> dyld_all_image_infos*)(uintptr_t)task_dyld_info.all_image_info_addr;
}
</pre><div style>Does it get the required address for the result packet?</div><div style><br></div><div style>Thanks in advance,</div><div style>Benjamin.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Mon, Feb 11, 2013 at 8:33 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5"><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>
</div></div>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>
<div class="im"><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>
</div>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>
<div class="im"><br>
><br>
><br>
> On Sun, Feb 10, <a href="tel:2013" value="+9722013">2013</a> 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>
</div>> _______________________________________________<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>
</blockquote></div><br></div></div></div>