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

[Martin Storsjö via Phabricator via libcxx-commits]

mstorsjo added inline comments.


================
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;
----------------
phosek wrote:
> mstorsjo wrote:
> > rnk wrote:
> > > 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.
> > I don't think there's anything particularly tricky at all on the C level so far, so I would expect it to build with MSVC just fine. But the assembly files require a gas style assembler.
> We're only concerned with ELF for our case, but I'd prefer to keep all platforms as similar as possible unless there's technical reason why it cannot be done. It seems like in this case it's still feasible to use the same approach for ELF, COFF and Mach-O.
Ok. It's probably simplest to proceed with this using alternatename then, and if someone has a concrete need of libunwind built with gcc/ld.bfd, they can propose patches to make it into non-weak aliases for that target, or see if the gcc/mingw/ld.bfd weak aliases really work for their case.


Repository:
  rUNW libunwind

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59921/new/

https://reviews.llvm.org/D59921