[lldb-dev] thread format evaluation in lldb

Todd Fiala todd.fiala at gmail.com
Wed Jun 18 20:23:58 PDT 2014


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.

I think that'll take care of it.


On Wed, Jun 18, 2014 at 8:19 PM, Todd Fiala <todd.fiala at gmail.com> wrote:

> Hey all,
>
> How exactly does a line like the following excerpted from an LLDB session
> get printed in lldb?
>
> Process 21522 stopped
>
> * thread #1: tid = 21522, 0x00007f289477f070 libc.so.6`nanosleep + 16 at
> syscall-template.S:82, name = 'hello', stop reason = signal SIGCONT
>
>
> 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.
>
> 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:
>
>     "{, stop reason = ${thread.stop-reason}}"\
> It's not clear to me how that gets evaluated, or if I'm even looking in
> the right spot.
>
> 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.
>
> Thanks!
> --
> -Todd
>



-- 
-Todd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140618/dff83f16/attachment.html>


More information about the lldb-dev mailing list