[all-commits] [llvm/llvm-project] 61f22f: [runtimes] Initialize LLVM_DEFAULT_TARGET_TRIPLE i...

[Martin Storsjö via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 61f22f70caf80a44d2528e82e5511d5413b8cf70
      https://github.com/llvm/llvm-project/commit/61f22f70caf80a44d2528e82e5511d5413b8cf70
  Author: Martin Storsjö <martin at martin.st>
  Date:   2021-09-14 (Tue, 14 Sep 2021)

  Changed paths:
    M runtimes/CMakeLists.txt

  Log Message:
  -----------
  [runtimes] Initialize LLVM_DEFAULT_TARGET_TRIPLE if not set by the caller

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


  Commit: 5b007f2c94667b360fcf2009952cd227945ab9e5
      https://github.com/llvm/llvm-project/commit/5b007f2c94667b360fcf2009952cd227945ab9e5
  Author: Martin Storsjö <martin at martin.st>
  Date:   2021-09-14 (Tue, 14 Sep 2021)

  Changed paths:
    M runtimes/CMakeLists.txt

  Log Message:
  -----------
  [runtimes] Calculate the path to the llvm directory without the LLVM cmake package

If building by pointing cmake directly at the llvm-project/runtimes
directory, the llvm cmake package files (that provide e.g.
LLVM_BUILD_MAIN_SRC_DIR) aren't necessarily available. Instead just
use a path relative to the current source dir.

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


  Commit: 197084fcee268fa7fbbc96df0900785766f55a69
      https://github.com/llvm/llvm-project/commit/197084fcee268fa7fbbc96df0900785766f55a69
  Author: Martin Storsjö <martin at martin.st>
  Date:   2021-09-14 (Tue, 14 Sep 2021)

  Changed paths:
    A llvm/test/tools/llvm-readobj/COFF/x86_64-unwind-preferred-symbol-gcc.yaml
    A llvm/test/tools/llvm-readobj/COFF/x86_64-unwind-preferred-symbol-msvc.yaml
    M llvm/tools/llvm-readobj/Win64EHDumper.cpp

  Log Message:
  -----------
  [llvm-readobj] [COFF] Try to resolve symbols in unwind info on x86

This is the same as we do on arm64 already for the MSVC style label
symbols, but also handle the way GCC produces it - with all relocations
pointing at the .text section symbol, with various offsets.

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


  Commit: 63784b9a75eb959a65c8cf644af9565764d8322c
      https://github.com/llvm/llvm-project/commit/63784b9a75eb959a65c8cf644af9565764d8322c
  Author: Martin Storsjö <martin at martin.st>
  Date:   2021-09-14 (Tue, 14 Sep 2021)

  Changed paths:
    A llvm/test/tools/llvm-readobj/COFF/arm64-unwind-preferred-symbol2.yaml
    M llvm/tools/llvm-readobj/ARMWinEHPrinter.cpp
    M llvm/tools/llvm-readobj/ARMWinEHPrinter.h

  Log Message:
  -----------
  [llvm-readobj] [COFF] Resolve relocations pointing at section symbols for arm64 too

This syncs parts from the x86 implementation to the ARMWinEH
implementation.

Currently, neither of the compilers targeting COFF/arm64 (MSVC, LLVM)
produce such relocations, but LLVM might after a later patch.

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


  Commit: ac3edc4c97ae9de62cdaec5d1acfa627a9a4b6ca
      https://github.com/llvm/llvm-project/commit/ac3edc4c97ae9de62cdaec5d1acfa627a9a4b6ca
  Author: Martin Storsjö <martin at martin.st>
  Date:   2021-09-14 (Tue, 14 Sep 2021)

  Changed paths:
    M llvm/lib/MC/MCWin64EH.cpp
    M llvm/test/MC/AArch64/seh.s
    M llvm/test/MC/COFF/seh-align1.s
    M llvm/test/MC/COFF/seh-align2.s
    M llvm/test/MC/COFF/seh-align3.s
    M llvm/test/MC/COFF/seh.s

  Log Message:
  -----------
  [Win64EH] Write .pdata symbol relocations relative to the temporary begin symbol

Previously the relocations pointed at the public user facing,
possibly external symbol.

When the function itself is weak, that symbol may be overridden at
link time, pointing at another strong implementation of the same
function instead. In that case, there's two conflicting pdata entries
pointing at the same address, and the wrong unwind info might end up
used.

Both GCC/binutils and MSVC produce pdata pointing at internal static
symbols. (GCC/binutils point at the .text section just as LLVM does
after this change, MSVC points at special label type symbols with the
type IMAGE_SYM_CLASS_LABEL and names like '$LN4'.)

This fixes unwinding through an overridden "operator new" with a
statically linked C++ library in MinGW mode. (Building libc++ with
-ffunction-sections and linking with --gc-sections might avoid the
issue too.)

This makes the produced object files a little less user friendly
to debug, but with other recent improvements for llvm-readobj, the
unwind info debugging experience should be pretty much the same.

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


Compare: https://github.com/llvm/llvm-project/compare/9aeecdfa8e91...ac3edc4c97ae