[lldb-dev] lldb patches for OpenBSD

Greg Clayton gclayton at apple.com
Fri Apr 1 11:33:35 PDT 2011


> 4) return (uint64_t) (pthread_self()); is a poor hack for getting
> thread id in Host.cpp. I hope to correct that in with feedback from
> more knowledgeable people here on this board. I privately sent a email
> to an OpenBSD developer, Matt Dempsky who wrote.
> 
>> llvm/tools/lldb/source/Host/common/Host.cpp:410: error: cast from
>> 'pthread*' to 'lldb::tid_t' loses precision
> 
> "That's because tid_t is a uint32_t, but on 64-bit arches pthread_t is
> a pointer, and so it's a 64-bit value.  It would probably be better to
> change tid_t to a uint64_t.  I don't imagine that would be a
> controversial change, and it affects all 64-bit non-Apple platforms, I
> believe."


Yikes,

It looks like this function is incorrect for non Apple variants:


lldb::tid_t
Host::GetCurrentThreadID()
{
#if defined (__APPLE__)
    return ::mach_thread_self();
#else
    return lldb::tid_t(pthread_self());
#endif
}

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?

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


> Also, is there any interest in convert the Makefiles into CMakeLists.txt?

Is the LLVM build able to use CMakeLists.txt? What are the advantages of using CMakeLists.txt?


> 
> Thanks,
> amit
> 




More information about the lldb-dev mailing list