<div dir="ltr">On a related note, we might want to think about the following:<div><br></div><div><ul><li>Windows will eventually need something to handle the gdb-remote stop notification signal numbers. Maybe UnixSignals isn't the best name for this concept.</li>
<li>Having the MacOSX signals as the base class UnixSignals, while having derived LinuxSignals and FreeBSDSignals for those platforms, is perhaps a bit misleading. (This probably evolved since the UnixSignals class handles all the data management and the derived classes are really class-based factories --- maybe we are abstracting the wrong thing by deriving, and maybe just need to work directly with a UnixSignals struct, better handling the construction).</li>
</ul><div>Just some thoughts. This will eventually need to be dealt with if we do llgs over to Windows. (If not, maybe we can postpone this for a while).</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Mon, Aug 25, 2014 at 12:45 PM, Todd Fiala <span dir="ltr"><<a href="mailto:tfiala@google.com" target="_blank">tfiala@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Yeah, we could consider doing that.<div><br></div><div>I've actually got a change in my public dev-llgs-local branch that adds a UnixSignalsSP as a constructor arg to Process, defaulting to a new Host::GetUnixSignals() if not specified. It's here:<br>
</div><div><div><br><div><a href="https://github.com/tfiala/lldb/commit/f85a1b1bad570fe9a9703118c6522d28eea3e202" target="_blank">https://github.com/tfiala/lldb/commit/f85a1b1bad570fe9a9703118c6522d28eea3e202</a><br></div>
<div><br></div>
</div><div>I'm going to rework it a bit to use HostInfo rather than Host before I upstream that part.</div></div><div><br></div><div>I was handling it right for a true llgs remote setup (like via (lldb) gdb-remote {host}:{port}), but when doing llgs local where we emulate local MacOSX debugging, it was getting the default UnixSignals, which are only good for MacOSX.</div>
</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 25, 2014 at 10:56 AM, 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">We probably should add some new packets to discover then via GDB remote packets kind of like the qRegisterInfo packets...<br>
<div><div><br>
> On Aug 22, 2014, at 4:04 PM, Todd Fiala <<a href="mailto:tfiala@google.com" target="_blank">tfiala@google.com</a>> wrote:<br>
><br>
> Ok looks like I'm not getting ProcessGDBRemote's concept of UnixSignals correct for Linux on the lldb-launch, llgs-attach mode for local debugging. This is causing mismatches in signal numbers --- LinuxSignals differ in some important ways from the default UnixSignals.<br>
><br>
><br>
> On Fri, Aug 22, 2014 at 3:13 PM, Todd Fiala <<a href="mailto:tfiala@google.com" target="_blank">tfiala@google.com</a>> wrote:<br>
><br>
><br>
><br>
> On Fri, Aug 22, 2014 at 2:59 PM, Todd Fiala <<a href="mailto:tfiala@google.com" target="_blank">tfiala@google.com</a>> wrote:<br>
> Hey Greg,<br>
><br>
> Where is the code in lldb that does the final 'resume' when we get the inferior stopped at the entry point with eLaunchFlagDebug?<br>
><br>
> I've got my local Linux debugging working with llgs with a band-aid fix to address the race condition, but I do consistently stop at the entry point to the program (the exec stop for the final exec into the true inferior process).<br>
><br>
> Another symptom I'm seeing (maybe it is related) is that lldb doesn't seem to know what the target is. IOW, I see this kind of behavior:<br>
><br>
> tfiala@tfiala2:/mnt/ssd/work/macosx.sync/mp-git/build-debug$ bin/lldb -- ~/play/loops/loops<br>
> (lldb) target create "/usr/local/google/home/tfiala/play/loops/loops"<br>
> Current executable set to '/usr/local/google/home/tfiala/play/loops/loops' (x86_64).<br>
> (lldb) run<br>
> Process 20363 launched: '/usr/local/google/home/tfiala/play/loops/loops' (x86_64)<br>
> Process 20363 stopped<br>
> * thread #1: tid = 20363, 0x00007f9b806f02d0, name = 'loops', stop reason = exec<br>
> frame #0: 0x00007f9b806f02d0<br>
> -> 0x7f9b806f02d0: movq %rsp, %rdi<br>
> 0x7f9b806f02d3: callq 0x7f9b806f3a70<br>
> 0x7f9b806f02d8: movq %rax, %r12<br>
> 0x7f9b806f02db: movl 0x221b17(%rip), %eax<br>
><br>
> // ^= here you see the behavior where I stop at the final exec (as I'd expect at the private level, but I'd expect lldb to want to continue it at the public level).<br>
><br>
> (lldb) c<br>
> Process 20363 resuming<br>
> i = 0<br>
> i = 1<br>
> i = 2<br>
> i = 3<br>
> i = 4<br>
> i = 5<br>
> i = 6<br>
> i = 7<br>
> i = 8<br>
> i = 9<br>
> Process 20363 exited with status = 0 (0x00000000)<br>
> (lldb) run<br>
> error: no file in target, create a debug target using the 'target create' command<br>
><br>
> // ^= Huh? I should be able to re-run :-)<br>
><br>
> (lldb)<br>
><br>
> On this part, I think I may not be clearing out everything that needs to be cleared out on an exec. I'm going to trace what debugserver/lldb does on MacOSX when an exec is detected to see if I'm missing anything on the Linux llgs/lldb side.<br>
><br>
><br>
> --<br>
> Todd Fiala | Software Engineer | <a href="mailto:tfiala@google.com" target="_blank">tfiala@google.com</a> | <a href="tel:650-943-3180" value="+16509433180" target="_blank">650-943-3180</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Todd Fiala | Software Engineer | <a href="mailto:tfiala@google.com" target="_blank">tfiala@google.com</a> | <a href="tel:650-943-3180" value="+16509433180" target="_blank">650-943-3180</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Todd Fiala | Software Engineer | <a href="mailto:tfiala@google.com" target="_blank">tfiala@google.com</a> | <a href="tel:650-943-3180" value="+16509433180" target="_blank">650-943-3180</a><br>
><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><table cellspacing="0" cellpadding="0" style="color:rgb(136,136,136);font-family:'Times New Roman'"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small">
<td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Todd Fiala |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Software Engineer |</td>
<td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:tfiala@google.com" style="color:rgb(17,85,204)" target="_blank"><span style="background-color:rgb(255,255,204);color:rgb(34,34,34);background-repeat:initial initial">tfiala@google.com</span></a> |</td>
<td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"><font color="#1155cc"> <a>650-943-3180</a></font></td></tr></tbody></table><br></div>
</div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><table cellspacing="0" cellpadding="0" style="color:rgb(136,136,136);font-family:'Times New Roman'"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small">
<td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Todd Fiala |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Software Engineer |</td>
<td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:tfiala@google.com" style="color:rgb(17,85,204)" target="_blank"><span style="background-color:rgb(255,255,204);color:rgb(34,34,34);background-repeat:initial initial">tfiala@google.com</span></a> |</td>
<td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"><font color="#1155cc"> <a>650-943-3180</a></font></td></tr></tbody></table><br></div>
</div>