[lldb-dev] lldb patches for OpenBSD
devlists at shadowlab.org
Fri Apr 1 11:50:27 PDT 2011
Le 1 avr. 2011 à 20:33, Greg Clayton a écrit :
>> 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
> It looks like this function is incorrect for non Apple variants:
> #if defined (__APPLE__)
> return ::mach_thread_self();
> return lldb::tid_t(pthread_self());
> 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?
The LLVM CMake build system is maintained and up to date. This is the one used to compile clang/llvm on Windows for instance (by generating Visual Studio projects), and it can also be used to generate a working llvm/clang Xcode projects (the Xcode projects files included in svn are not up-to date and I don't think it is possible to build something useful using these files).
More information about the lldb-dev