[lldb-dev] Win64 lldb build broken, llvm::call_once and _mm_mfence

[Kamil Rytarowski via lldb-dev]

It looks fine:

diff --git a/source/Host/windows/HostInfoWindows.cpp
b/source/Host/windows/HostInfoWindows.cpp
index a965ec0ea..5b38e6021 100644
--- a/source/Host/windows/HostInfoWindows.cpp
+++ b/source/Host/windows/HostInfoWindows.cpp
@@ -18,6 +18,7 @@
 #include "llvm/Support/ConvertUTF.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Path.h"
+#include "llvm/Support/Threading.h"
 #include "llvm/Support/raw_ostream.h"

 using namespace lldb_private;
@@ -90,8 +91,8 @@ bool HostInfoWindows::GetHostname(std::string &s) {
 }

 FileSpec HostInfoWindows::GetProgramFileSpec() {
-  static std::once_flag g_once_flag;
-  std::call_once(g_once_flag, []() {
+  static llvm::once_flag g_once_flag;
+  llvm::call_once(g_once_flag, []() {
     std::vector<wchar_t> buffer(PATH_MAX);
     ::GetModuleFileNameW(NULL, buffer.data(), buffer.size());
     std::string path;

and this looks suspicious

// std::call_once from libc++ is used on all Unix platforms. Other
// implementations like libstdc++ are known to have problems on NetBSD,
// OpenBSD and PowerPC.
#if defined(LLVM_ON_UNIX) && (defined(_LIBCPP_VERSION) ||
      \
    !(defined(__NetBSD__) || defined(__OpenBSD__) || defined(__ppc__)))
#define LLVM_THREADING_USE_STD_CALL_ONCE 1
#else
#define LLVM_THREADING_USE_STD_CALL_ONCE 0
#endif

This check defined(LLVM_ON_UNIX) looks wrong it assumes that Windows
needs call_once walkaround.

On 08.02.2017 22:00, Zachary Turner wrote:
> Why doesn't llvm::call_once() just use std::call_once on Windows?
> 
> On Wed, Feb 8, 2017 at 12:40 PM Hans Wennborg <hans at chromium.org
> <mailto:hans at chromium.org>> wrote:
> 
>     The Win64 lldb build seems broken (at 294367).
> 
>     I ran into this when trying to build the weekly snapshot
>     (http://www.llvm.org/builds/) which includes LLDB these days.
> 
>     I suspect this might be related to Kamil's changes a few days ago. I
>     see Pavel committed something to fix Darwin afterwards.
> 
>     Zach, do you know what's going on here? Do we have any buildbot
>     coverage for this?
> 
>        Creating library lib\liblldb.lib and object lib\liblldb.exp
>     lldbHost.lib(HostInfoWindows.cpp.obj) : error LNK2019: unresolved
>     external symbo
>     l "void __cdecl llvm::sys::_mm_mfence(void)"
>     (?_mm_mfence at sys@llvm@@YAXXZ) refer
>     enced in function "void __cdecl llvm::call_once<class
>     <lambda_e212a11f7f891e804e
>     713e15728a6adc> >(struct llvm::once_flag &,class
>     <lambda_e212a11f7f891e804e713e1
>     5728a6adc> &&)"
>     (??$call_once at V<lambda_e212a11f7f891e804e713e15728a6adc>@@$$V at ll
>     vm@@YAXAEAUonce_flag at 0@$$QEAV<lambda_e212a11f7f891e804e713e15728a6adc>@@@Z)
>     bin\liblldb.dll : fatal error LNK1120: 1 unresolved externals
>     LINK failed. with 1120
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20170208/bf4d72fc/attachment-0001.sig>