[lldb-dev] lldb patches for OpenBSD

Stephen Wilson wilsons at start.ca
Fri Apr 1 13:39:32 PDT 2011

On Fri, Apr 01, 2011 at 11:33:35AM -0700, Greg Clayton wrote:
> A "lldb::tid_t" is a thread ID, not a thread opaque pointer. The
> "lldb::thread_t" is the already the correct type for the host system's
> "thread opaque pointer", but that isn't what this function is trying
> to return.
> Dooes linux or BSD have the notion of a thread ID for the current
> thread that isn't just a pthread_t?

Linux has gettid(2), so yes.

> This function is used mostly for logging when you want to log the
> current process ID and the current thread ID.

Just some thoughts:

Platforms that use user-space thread library implementations can provide
some Host code that maps pthread_t pointers (or whatever) via a hash to
useful 32-bit numeric id's.  We could do that in Host::ThreadCreate for
example.  It really then becomes an issue for the Host to figure out how
to make those ID's useful from a logging/user perspective.

But without a good way to map/log those ID's, doing a simple truncation
on a pointer is probably just fine *most* of the time since those last
bits are going to be the unique ones anyway.

So even though the lldb::tid_t(pthread_self()) is "wrong", it still
does what it needs to do in this case; give a per-thread-unique integer

So I think the main question is:  does having the full 64 bit pointer as
an ID give useful info to the developers using user-space threads?  I
mean, is there some tool (top, ps, etc) or function that one can use to
map those values into something meaningful, or is uniqueness the only
thing that matters?


More information about the lldb-dev mailing list