[all-commits] [llvm/llvm-project] bedf65: [runtimes] Default LIB*_HERMETIC_STATIC_LIBRARY to...

[Martin Storsjö via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: bedf657d0f4c54ffe9ef4303382657a74296b544
      https://github.com/llvm/llvm-project/commit/bedf657d0f4c54ffe9ef4303382657a74296b544
  Author: Martin Storsjö <martin at martin.st>
  Date:   2022-05-18 (Wed, 18 May 2022)

  Changed paths:
    M libcxx/CMakeLists.txt
    M libcxx/src/CMakeLists.txt
    M libcxx/test/libcxx/vendor/clang-cl/static-lib-exports.sh.cpp
    M libcxx/test/libcxx/vendor/mingw/static-lib-exports.sh.cpp
    M libcxxabi/CMakeLists.txt
    M libcxxabi/src/CMakeLists.txt
    M libunwind/CMakeLists.txt

  Log Message:
  -----------
  [runtimes] Default LIB*_HERMETIC_STATIC_LIBRARY to ON on Windows

(In the case of libunwind, the cmake option is called
LIBUNWIND_HIDE_SYMBOLS, but it has the same effect as
LIBCXX_HERMETIC_STATIC_LIBRARY and
LIBCXXABI_HERMETIC_STATIC_LIBRARY.)

Previously, the same issue was dealt with by setting a project wide
define (_LIBUNWIND_HIDE_SYMBOLS,
_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS and
_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS) if only building a static
library.  If building both static and shared at the same time, this
wasn't set, and the static library would contain dllexport directives.

The LIB*_HERMETIC_STATIC_LIBRARY and LIBUNWIND_HIDE_SYMBOLS cmake
options only apply the defines to the static library in the build,
even if building both static and shared at the same time.

(This could only be done use after the object libraries were
enabled, as a shared libcxx needs libcxxabi object files built
with dllexports included.)

This allows removing inelegant code for deciding how to build the
libcxxabi static library and a TODO comment that suggested that
users should need to start setting an option, which they shouldn't
need to. Finally, this gets rid of two XFAILs in tests.

Differential Revision: https://reviews.llvm.org/D125715


  Commit: 091a55c16ad4e87aa67a3c003fade1a226698734
      https://github.com/llvm/llvm-project/commit/091a55c16ad4e87aa67a3c003fade1a226698734
  Author: Martin Storsjö <martin at martin.st>
  Date:   2022-05-18 (Wed, 18 May 2022)

  Changed paths:
    M llvm/lib/MC/MCWin64EH.cpp

  Log Message:
  -----------
  [MC] [Win64EH] Remove an unused parameter to ARM64EmitUnwindCode. NFC.

Differential Revision: https://reviews.llvm.org/D125878


  Commit: 924defada9bc0e3c89b0c0e288d7cb4dd654e7d4
      https://github.com/llvm/llvm-project/commit/924defada9bc0e3c89b0c0e288d7cb4dd654e7d4
  Author: Martin Storsjö <martin at martin.st>
  Date:   2022-05-18 (Wed, 18 May 2022)

  Changed paths:
    M llvm/lib/MC/MCWin64EH.cpp
    M llvm/test/MC/AArch64/seh-packed-unwind.s

  Log Message:
  -----------
  [MC] [Win64EH] Don't produce packed ARM64 unwind info with homed parameters

There's an inconsistency regarding the epilogs of packed ARM64
unwind info with homed parameters; according to the documentation
(and according to common sense), the epilog wouldn't have a series
of nop instructions matching the stp x0-x7 in the prolog - however
in practice, RtlVirtualUnwind still seems to behave as if the epilog
does have the mirrored nops from the prolog.

In practice, MSVC doesn't seem to produce packed unwind info with
homed parameters, which might be why this inconsistency hasn't
been noticed.

Thus, to play it safe, avoid creating such packed unwind info with
homed parameters. (LLVM's current behaviour matches the current
runtime behaviour of RtlVirtualUnwind, but if it later is bug fixed
to match the documentation, such unwind information would be
incorrect.)

See https://github.com/llvm/llvm-project/issues/54879 for further
discussion on the matter.

Differential Revision: https://reviews.llvm.org/D125876


Compare: https://github.com/llvm/llvm-project/compare/86f7d7074a01...924defada9bc