[all-commits] [llvm/llvm-project] e71b07: [MC] [Win64EH] Wrap the epilog instructions in a s...

Wed Jun 1 01:26:42 PDT 2022

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: e71b07e468b34b18519102a58c20e32ee716976b
      https://github.com/llvm/llvm-project/commit/e71b07e468b34b18519102a58c20e32ee716976b
  Author: Martin Storsjö <martin at martin.st>
  Date:   2022-06-01 (Wed, 01 Jun 2022)

  Changed paths:
    M llvm/include/llvm/MC/MCWinEH.h
    M llvm/lib/MC/MCWin64EH.cpp
    M llvm/lib/Target/AArch64/MCTargetDesc/AArch64WinCOFFStreamer.cpp

  Log Message:
  -----------
  [MC] [Win64EH] Wrap the epilog instructions in a struct. NFC.

For ARM SEH, the epilogs will need a little more associated data than
just the plain list of opcodes.

This is a preparatory refactoring for D125645.

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

  Commit: 6b75a3523ffd79bc03265469aeeedab26079026e
      https://github.com/llvm/llvm-project/commit/6b75a3523ffd79bc03265469aeeedab26079026e
  Author: Martin Storsjö <martin at martin.st>
  Date:   2022-06-01 (Wed, 01 Jun 2022)

  Changed paths:
    M llvm/include/llvm/MC/MCStreamer.h
    M llvm/include/llvm/MC/MCWin64EH.h
    M llvm/include/llvm/MC/MCWinEH.h
    M llvm/include/llvm/Support/Win64EH.h
    M llvm/lib/CodeGen/AsmPrinter/WinException.cpp
    M llvm/lib/MC/MCAsmStreamer.cpp
    M llvm/lib/MC/MCParser/COFFAsmParser.cpp
    M llvm/lib/MC/MCWin64EH.cpp
    M llvm/lib/Target/ARM/AsmParser/ARMAsmParser.cpp
    M llvm/lib/Target/ARM/MCTargetDesc/ARMELFStreamer.cpp
    M llvm/lib/Target/ARM/MCTargetDesc/ARMMCAsmInfo.cpp
    M llvm/lib/Target/ARM/MCTargetDesc/ARMMCTargetDesc.h
    M llvm/lib/Target/ARM/MCTargetDesc/ARMTargetStreamer.cpp
    M llvm/lib/Target/ARM/MCTargetDesc/ARMWinCOFFStreamer.cpp
    A llvm/test/MC/ARM/seh.s

  Log Message:
  -----------
  [ARM] [MC] Add support for writing ARM WinEH unwind info

This includes .seh_* directives for generating it from assembly.
It is designed fairly similarly to the ARM64 handling.

For .seh_handler directives, such as
".seh_handler __C_specific_handler, @except" (which is supported
on x86_64 and aarch64 so far), the "@except" bit doesn't work in
ARM assembly, as '@' is used as a comment character (on all current
platforms).

Allow using '%' instead of '@' for this purpose. This convention
is used by GAS in similar contexts already,
e.g. [1]:

    Note on targets where the @ character is the start of a comment
    (eg ARM) then another character is used instead. For example the
    ARM port uses the % character.

In practice, this unfortunately means that all such .seh_handler
directives will need ifdefs for ARM.

Contrary to ARM64, on ARM, it's quite common that we can't evaluate
e.g. the function length at this point, due to instructions whose
length is finalized later. (Also, inline jump tables end with
a ".p2align 1".)

If unable to to evaluate the function length immediately, emit
it as an MCExpr instead. If we'd implement splitting the unwind
info for a function (which isn't implemented for ARM64 yet either),
we wouldn't know whether we need to split it though.

Avoid calling getFrameIndexOffset() on an unset
FuncInfo.UnwindHelpFrameIdx, to avoid triggering asserts in the
preexisting testcase CodeGen/ARM/Windows/wineh-basic.ll. (Once
MSVC exception handling is fully implemented, those changes
can be reverted.)

[1] https://sourceware.org/binutils/docs/as/Section.html#Section

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

  Commit: d4022ff3310635f682e9937c8ffa4aeb0d2e2854
      https://github.com/llvm/llvm-project/commit/d4022ff3310635f682e9937c8ffa4aeb0d2e2854
  Author: Martin Storsjö <martin at martin.st>
  Date:   2022-06-01 (Wed, 01 Jun 2022)

  Changed paths:
    M llvm/lib/MC/MCWin64EH.cpp
    A llvm/test/MC/ARM/seh-epilog-packing.s
    A llvm/test/MC/ARM/seh-epilog-sharing.s
    A llvm/test/MC/ARM/seh-packed.s
    M llvm/test/MC/ARM/seh.s

  Log Message:
  -----------
  [MC] [Win64EH] Optimize the ARM unwind info

Use the packed unwind info format if possible; otherwise try to
create a packed epilog.

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

  Commit: 298e9cac9204b788dd6a18dba669b40acf2aaa3c
      https://github.com/llvm/llvm-project/commit/298e9cac9204b788dd6a18dba669b40acf2aaa3c
  Author: Martin Storsjö <martin at martin.st>
  Date:   2022-06-01 (Wed, 01 Jun 2022)

  Changed paths:
    M llvm/include/llvm/MC/MCWinEH.h
    M llvm/lib/MC/MCWin64EH.cpp
    M llvm/lib/MC/WinCOFFObjectWriter.cpp
    M llvm/lib/Target/ARM/MCTargetDesc/ARMWinCOFFStreamer.cpp
    A llvm/test/MC/ARM/seh-checks.s
    A llvm/test/MC/ARM/seh-checks2.s

  Log Message:
  -----------
  [MC] [Win64EH] Check that the SEH unwind opcodes match the actual instructions

It's a fairly common issue that the generating code incorrectly marks
instructions as narrow or wide; check that the instruction lengths
add up to the expected value, and error out if it doesn't. This allows
catching code generation bugs.

Also check that prologs and epilogs are properly terminated, to
catch other code generation issues.

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

  Commit: 7e2afe83e88d5d50c878492f27c69c6850e31582
      https://github.com/llvm/llvm-project/commit/7e2afe83e88d5d50c878492f27c69c6850e31582
  Author: Martin Storsjö <martin at martin.st>
  Date:   2022-06-01 (Wed, 01 Jun 2022)

  Changed paths:
    M llvm/lib/Support/Windows/Process.inc

  Log Message:
  -----------
  [Windows] Don't try to wildcard expand paths starting with \\?\

Paths that start with `\\?\` are absolute paths, and aren't expected
to be used with wildcard expressions.

Previously, the `?` at the start of the path triggered the condition
for a potential wildcard, which caused the path to be split and
reassembled. In builds with `LLVM_WINDOWS_PREFER_FORWARD_SLASH=ON`,
this caused a path like e.g. `\\?\D:\tmp\hello.cpp` to be reassembled
into `\\?\D:\tmp/hello.cpp` which isn't a valid path (as such
absolute paths must use backslashes consistently).

This fixes https://github.com/mstorsjo/llvm-mingw/issues/280.

I'm not sure if there's any straightforward way to add a test
for this case, unfortunately.

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

Compare: https://github.com/llvm/llvm-project/compare/a159128811ae...7e2afe83e88d