The problem appears while linking liblldb.so. The class Address contain atomic variable m_offset. The loading and storing of variable is access via atomic_load_8 and atomic_store_8 functions. Some target fail to implicitly link libatomic, which cause undefine reference to atomic_store_8/atomic_load_8. This patch uses http://reviews.llvm.org/D20896 to check if libatomic need to be explicitly link.
This sounds like an issue that either has already been solved in LLVM's
CMake, or should be solved in LLVM's CMake. Can you find out how they
decide whether to use -latomic and piggyback off that?
So I don't really know much about this, but it seems wrong to me to be duplicating this code. As far as I can tell, the only difference between the one in llvm is that it allows for checking of 64 bit atomics. Why not fold that logic into LLVM's CheckAtomic though? Or at the very least, why not make a separate CheckAtomic64 in LLVM that both libcxx and now LLDB could both use? The code here and in libcxx is almost the same, it doesn't make much sense to me to be duplicating it.
|7 ↗||(On Diff #57909)|
This isn't going to work with MSVC. If the compiler is MSVC we should simply set the variable to true, since it is known to support atomics.
From what I remember it boils down to the fact that we don't want to have atomics whose width isn't natively supported on our targets. Take a look at the comments from this thread: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160125/328321.html.
Or at the very least, why not make a separate CheckAtomic64 in LLVM that both libcxx and now LLDB could both use? The code here and in libcxx is almost the same, it doesn't make much sense to me to be duplicating it.
That's an option too. I wasn't aware that LLDB needs the same type of check at the time.
In general, the idea sounds reasonable.
I think you should be able to achieve the same effect by adding the library to LLDB_SYSTEM_LIBS in LLDBDependencies.cmake. This should be a much cleaner (and definitely more consistent) way of doing things.