[PATCH] D79995: [clang] [MinGW] Fix libunwind extension

[Martin Storsjö via Phabricator via cfe-commits]

mstorsjo added a reviewer: rnk.
mstorsjo added a subscriber: rnk.
mstorsjo added a comment.

So, using `-l:libunwind.dll.a` is definitely more correct than `-l:libunwind.so` on this platform, so in that sense this is good.

In my toolchains I don't use this option at all so far, because I have libunwind bundled into libc++.a/libc++.dll.a, but I guess it would be nice to move towards this setup and stop bundling them. But the toolchains can be configured to omit either the shared or the static version of the libraries, and if libunwind only exists in static form, this would fail.

If there's only a shared version, and building with `-static-libgcc`, I guess it's ok to look for explicitly `libunwind.a` and fail in that case, but for the default case, I think the normal library resolution logic would be best, i.e. just doing `-lunwind`.

The ideal version from my point of view would be this:

  case ToolChain::UNW_CompilerRT:
    if (LGT == LibGccType::StaticLibGcc)
      CmdArgs.push_back("-l:libunwind.a");
    else if (TC.getTriple().isOSCygMing()) {
      if (LGT == LibGccType::SharedLibGcc)
        CmdArgs.push_back("-l:libunwind.dll.a");
      else
        CmdArgs.push_back("-lunwind"); // Let the linker choose between libunwind.dll.a and libunwind.a depending on what's available, and depending on the -static flag
    } else
      CmdArgs.push_back("-l:libunwind.so");
    break;

That's rather different than the other, non-mingw cases though, but I'm not familiar with the reasoning behind those.

Adding @rnk if he'd happen to have opinions.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79995