[lldb-dev] lldb patches for OpenBSD

[Greg Clayton]

On Apr 1, 2011, at 1:39 PM, Stephen Wilson wrote:

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

We do track some thread info already in LLDB for any thread that is launched through the Host::ThreadCreate() function (thread name for platforms that don't support it). If you have any ideas on extra stuff you would want to track, let me know.

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

Agreed.

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

Yep. In our case we have functions that can use the thread ID to do thread type calls in the debugger, so we like to show the IDs that could be used to make calls if possible. Also if there are crash loggers or sample tools that show a list of threads, it is nice to be able to see the same IDs in all places. 

> 
> 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?

We currently don't use the thread IDs for the host threads in the current process for anything. If we do, we would use the thread handle which is already a pthread_t for all of us unix based OS's so we could add a:

static lldb::thread_t Host::GetCurrentThread();

call for those situations.

So this is currently functional and there is no immediate need for change unless there are other debug related tools where you would want to correlate the threads IDs with.

Greg Clayton


Greg Clayton