[lldb-dev] lldb patches for OpenBSD

[Stephen Wilson]

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
identifier.


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?

-- 
steve