<div dir="ltr">Oh I think I get it.  Looks like Process has a virtual method on it that I need to override in ProcessGdbRemote with an appropriate set for whatever the remote target is.<div><br></div><div>I think that'll take care of it.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 18, 2014 at 8:19 PM, Todd Fiala <span dir="ltr"><<a href="mailto:todd.fiala@gmail.com" target="_blank">todd.fiala@gmail.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">Hey all,<div><br></div><div>How exactly does a line like the following excerpted from an LLDB session get printed in lldb?</div>
<div><br></div><div>







<p>Process 21522 stopped</p>
<p>* thread #1: tid = 21522, 0x00007f289477f070 libc.so.6`nanosleep + 16 at syscall-template.S:82, name = 'hello', stop reason = signal SIGCONT</p><p><br></p><p>Grepping around, it looks like the thread format might get controlled by the thread-format property, defaulting to the DEFAULT_THREAD_FORMAT in Debugger.cpp.</p>

<p>The issue I'm trying to figure out is how the stop reason is turned into text.  The thread format lists a line like this:</p><p>    "{, stop reason = ${thread.stop-reason}}"\</p><div>It's not clear to me how that gets evaluated, or if I'm even looking in the right spot.</div>

<div><br></div><div>The reason I care: right now in llgs I'm seeing the Linux x86_64 pass along the Linux SIGSTOP value as a stop notification (hex 0x13 on Linux) but the lldb side (also running on Linux) is printing SIGCONT.  That would make sense if it was using a straight-up UnixSignals instead of LinuxSignals, where the signal numbers are different.  I'm hoping to track that down by figuring out how it is getting printed.</div>

<div><br></div><div>Thanks!</div><span class="HOEnZb"><font color="#888888">-- <br><div dir="ltr">-Todd</div>
</font></span></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">-Todd</div>
</div>