[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