[libcxx-commits] [PATCH] D59921: [libunwind] Export the unw_* symbols as weak symbols

Reid Kleckner via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Thu Mar 28 13:58:05 PDT 2019

rnk added a subscriber: compnerd.
rnk added inline comments.
Herald added a subscriber: dexonsmith.

Comment at: libunwind/src/config.h:77
+#define _LIBUNWIND_WEAK_ALIAS(name, aliasname)                                 \
+  __pragma(comment(linker, "/alternatename:" #aliasname "=" #name))            \
+      _LIBUNWIND_EXPORT extern "C" __typeof(name) aliasname;
mstorsjo wrote:
> This kind of pragma requires building with `-fms-extensions` for mingw mode (which is the only windows configuration where there's any need to use libunwind at all, as far as I know), which breaks building with gcc (and the directive is only supported by lld, not by ld.bfd). This requires adding `unwind_append_if(LIBUNWIND_COMPILE_FLAGS MINGW -fms-extensions)` to the main `CMakeLists.txt`.
> That's not a blocker for this change by any means, but I'll just let it be noted that it's a change from how things were before.
> The `__attribute__((weak, alias()))` form does work in both gcc and clang actually though, so that might almost also be an option, but it's a bit messy (both clang and ld.bfd seem to have a bit of gotchas relating to it), so perhaps we shouldn't.
> Alternatively, we could also just postpone making them properly weak on mingw (as it's not strictly necessary contrary to e.g. sanitizers), and just do this with a plain `__attribute__((alias(#name)))` as above, without the weak.
> Also, I'm pretty sure that `/alternatename` requires using `__USER_LABEL_PREFIX__` here (judging from how it's used in sanitizers).
Re: `__USER_LABEL_PREFIX__`, I think that's true. It's a pretty big drawback to /alternatename.

I guess @phosek wants to make llvm libunwind consistently not provide strong definitions of unw_* across all platforms, otherwise I would say just make this whole thing ELF-only, and provide strong aliases of unw_* = _unw_* for non-ELF platforms.

Does libunwind build with MSVC on Windows? I have no idea, personally. I feel like it's only ever brought in if Itanium-style EH is in use, which usually means mingw, or @compnerd's emergent *-windows-itanium ABI, so theoretically, it might build with MSVC.

  rUNW libunwind



More information about the libcxx-commits mailing list