maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/MC/AArch64/seh.s

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

190 lines
5.7 KiB
ArmAsm
Raw Normal View History

[AArch64] Generate and parse SEH assembly directives This ensures that you get the same output regardless if generating code directly to an object file or if generating assembly and assembling that. Add implementations of the EmitARM64WinCFI*() methods in AArch64TargetAsmStreamer, and fill in one blank in MCAsmStreamer. Add corresponding directive handlers in AArch64AsmParser and COFFAsmParser. Some SEH directive names have been picked to match the prior art for SEH assembly directives for x86_64, e.g. the spelling of ".seh_startepilogue" matching the preexisting ".seh_endprologue". For the directives for saving registers, the exact spelling from the arm64 documentation is picked, e.g. ".seh_save_reg" (to follow that naming for all the other ones, e.g. ".seh_save_fregp_x"), while the corresponding one for x86_64 is plain ".seh_savereg" without the second underscore. Directives in the epilogues have the same names as in prologues, e.g. .seh_savereg, even though the registers are restored, not saved, at that point. Differential Revision: https://reviews.llvm.org/D86529
2020-08-07 17:44:48 +08:00
// This test checks that the SEH directives emit the correct unwind data.
[AArch64] Avoid crashing on .seh directives in assembly Differential Revision: https://reviews.llvm.org/D55670 llvm-svn: 349549
2018-12-19 06:10:17 +08:00
[MC] [Win64EH] Avoid producing malformed xdata records If there's no unwinding opcodes, omit writing the xdata/pdata records. Previously, this generated truncated xdata records, and llvm-readobj would error out when trying to print them. If writing of an xdata record is forced via the .seh_handlerdata directive, skip it if there's no info to make a sensible unwind info structure out of, and clearly error out if such info appeared later in the process. Differential Revision: https://reviews.llvm.org/D86527
2020-08-20 15:38:17 +08:00
// RUN: llvm-mc -triple aarch64-pc-win32 -filetype=obj %s | llvm-readobj -S -r -u - | FileCheck %s
[AArch64] Avoid crashing on .seh directives in assembly Differential Revision: https://reviews.llvm.org/D55670 llvm-svn: 349549
2018-12-19 06:10:17 +08:00
[AArch64] Generate and parse SEH assembly directives This ensures that you get the same output regardless if generating code directly to an object file or if generating assembly and assembling that. Add implementations of the EmitARM64WinCFI*() methods in AArch64TargetAsmStreamer, and fill in one blank in MCAsmStreamer. Add corresponding directive handlers in AArch64AsmParser and COFFAsmParser. Some SEH directive names have been picked to match the prior art for SEH assembly directives for x86_64, e.g. the spelling of ".seh_startepilogue" matching the preexisting ".seh_endprologue". For the directives for saving registers, the exact spelling from the arm64 documentation is picked, e.g. ".seh_save_reg" (to follow that naming for all the other ones, e.g. ".seh_save_fregp_x"), while the corresponding one for x86_64 is plain ".seh_savereg" without the second underscore. Directives in the epilogues have the same names as in prologues, e.g. .seh_savereg, even though the registers are restored, not saved, at that point. Differential Revision: https://reviews.llvm.org/D86529
2020-08-07 17:44:48 +08:00
// Check that the output assembler directives also can be parsed, and
// that they produce equivalent output:
// RUN: llvm-mc -triple aarch64-pc-win32 -filetype=asm %s | llvm-mc -triple aarch64-pc-win32 -filetype=obj - | llvm-readobj -S -r -u - | FileCheck %s
[AArch64] Avoid crashing on .seh directives in assembly Differential Revision: https://reviews.llvm.org/D55670 llvm-svn: 349549
2018-12-19 06:10:17 +08:00
// CHECK: Sections [
// CHECK: Section {
// CHECK: Name: .text
// CHECK: RelocationCount: 0
// CHECK: Characteristics [
// CHECK-NEXT: ALIGN_4BYTES
// CHECK-NEXT: CNT_CODE
// CHECK-NEXT: MEM_EXECUTE
// CHECK-NEXT: MEM_READ
// CHECK-NEXT: ]
// CHECK-NEXT: }
// CHECK: Section {
// CHECK: Name: .xdata
[MC] [Win64EH] Write packed ARM64 epilogues if possible This gives a pretty substantial size reduction; for a 6.5 MB DLL with 300 KB .xdata, the .xdata shrinks by 66 KB. Differential Revision: https://reviews.llvm.org/D87369
2020-09-08 05:00:07 +08:00
// CHECK: RawDataSize: 52
[AArch64] Avoid crashing on .seh directives in assembly Differential Revision: https://reviews.llvm.org/D55670 llvm-svn: 349549
2018-12-19 06:10:17 +08:00
// CHECK: RelocationCount: 1
// CHECK: Characteristics [
// CHECK-NEXT: ALIGN_4BYTES
// CHECK-NEXT: CNT_INITIALIZED_DATA
// CHECK-NEXT: MEM_READ
// CHECK-NEXT: ]
// CHECK-NEXT: }
// CHECK: Section {
// CHECK: Name: .pdata
[MC] [Win64EH] Avoid producing malformed xdata records If there's no unwinding opcodes, omit writing the xdata/pdata records. Previously, this generated truncated xdata records, and llvm-readobj would error out when trying to print them. If writing of an xdata record is forced via the .seh_handlerdata directive, skip it if there's no info to make a sensible unwind info structure out of, and clearly error out if such info appeared later in the process. Differential Revision: https://reviews.llvm.org/D86527
2020-08-20 15:38:17 +08:00
// CHECK: RelocationCount: 2
[AArch64] Avoid crashing on .seh directives in assembly Differential Revision: https://reviews.llvm.org/D55670 llvm-svn: 349549
2018-12-19 06:10:17 +08:00
// CHECK: Characteristics [
// CHECK-NEXT: ALIGN_4BYTES
// CHECK-NEXT: CNT_INITIALIZED_DATA
// CHECK-NEXT: MEM_READ
// CHECK-NEXT: ]
// CHECK-NEXT: }
// CHECK-NEXT: ]
// CHECK-NEXT: Relocations [
// CHECK-NEXT: Section (4) .xdata {
[MC] [Win64EH] Write packed ARM64 epilogues if possible This gives a pretty substantial size reduction; for a 6.5 MB DLL with 300 KB .xdata, the .xdata shrinks by 66 KB. Differential Revision: https://reviews.llvm.org/D87369
2020-09-08 05:00:07 +08:00
// CHECK-NEXT: 0x28 IMAGE_REL_ARM64_ADDR32NB __C_specific_handler
[AArch64] Avoid crashing on .seh directives in assembly Differential Revision: https://reviews.llvm.org/D55670 llvm-svn: 349549
2018-12-19 06:10:17 +08:00
// CHECK-NEXT: }
// CHECK-NEXT: Section (5) .pdata {
[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
2021-09-07 19:56:43 +08:00
// CHECK-NEXT: 0x0 IMAGE_REL_ARM64_ADDR32NB .text
[AArch64] Avoid crashing on .seh directives in assembly Differential Revision: https://reviews.llvm.org/D55670 llvm-svn: 349549
2018-12-19 06:10:17 +08:00
// CHECK-NEXT: 0x4 IMAGE_REL_ARM64_ADDR32NB .xdata
// CHECK-NEXT: }
// CHECK-NEXT: ]
[MC] [Win64EH] Fill in FuncletOrFuncEnd if missing This can happen e.g. for code that declare .seh_proc/.seh_endproc in assembly, or for code that use .seh_handlerdata (which triggers the unwind info to be emitted before the end of the function). The TextSection field must be made non-const to be able to use it with Streamer.SwitchSection(). Differential Revision: https://reviews.llvm.org/D86528
2020-08-20 16:39:25 +08:00
// CHECK-NEXT: UnwindInformation [
// CHECK-NEXT: RuntimeFunction {
// CHECK-NEXT: Function: func
// CHECK-NEXT: ExceptionRecord: .xdata
// CHECK-NEXT: ExceptionData {
[AArch64] Add asm directives for the remaining SEH unwind codes Add support in llvm-readobj for displaying them and support in the asm parsser, AArch64TargetStreamer and MCWin64EH for emitting them. The directives for the remaining basic opcodes have names that match the opcode in the documentation. The directives for custom stack cases, that are named MSFT_OP_TRAP_FRAME, MSFT_OP_MACHINE_FRAME, MSFT_OP_CONTEXT and MSFT_OP_CLEAR_UNWOUND_TO_CALL, are given matching assembler directive names that fit into the rest of the opcode naming; .seh_trap_frame, .seh_context, .seh_clear_unwound_to_call The opcode MSFT_OP_MACHINE_FRAME is mapped to the existing opecode enum UOP_PushMachFrame that is used on x86_64, and also uses the corresponding existing x86_64 directive name .seh_pushframe. Differential Revision: https://reviews.llvm.org/D86889
2020-08-16 05:26:24 +08:00
// CHECK-NEXT: FunctionLength: 100
[AArch64] Generate and parse SEH assembly directives This ensures that you get the same output regardless if generating code directly to an object file or if generating assembly and assembling that. Add implementations of the EmitARM64WinCFI*() methods in AArch64TargetAsmStreamer, and fill in one blank in MCAsmStreamer. Add corresponding directive handlers in AArch64AsmParser and COFFAsmParser. Some SEH directive names have been picked to match the prior art for SEH assembly directives for x86_64, e.g. the spelling of ".seh_startepilogue" matching the preexisting ".seh_endprologue". For the directives for saving registers, the exact spelling from the arm64 documentation is picked, e.g. ".seh_save_reg" (to follow that naming for all the other ones, e.g. ".seh_save_fregp_x"), while the corresponding one for x86_64 is plain ".seh_savereg" without the second underscore. Directives in the epilogues have the same names as in prologues, e.g. .seh_savereg, even though the registers are restored, not saved, at that point. Differential Revision: https://reviews.llvm.org/D86529
2020-08-07 17:44:48 +08:00
// CHECK: Prologue [
[AArch64] Add asm directives for the remaining SEH unwind codes Add support in llvm-readobj for displaying them and support in the asm parsser, AArch64TargetStreamer and MCWin64EH for emitting them. The directives for the remaining basic opcodes have names that match the opcode in the documentation. The directives for custom stack cases, that are named MSFT_OP_TRAP_FRAME, MSFT_OP_MACHINE_FRAME, MSFT_OP_CONTEXT and MSFT_OP_CLEAR_UNWOUND_TO_CALL, are given matching assembler directive names that fit into the rest of the opcode naming; .seh_trap_frame, .seh_context, .seh_clear_unwound_to_call The opcode MSFT_OP_MACHINE_FRAME is mapped to the existing opecode enum UOP_PushMachFrame that is used on x86_64, and also uses the corresponding existing x86_64 directive name .seh_pushframe. Differential Revision: https://reviews.llvm.org/D86889
2020-08-16 05:26:24 +08:00
// CHECK-NEXT: 0xec ; clear unwound to call
// CHECK-NEXT: 0xea ; context
// CHECK-NEXT: 0xe9 ; machine frame
// CHECK-NEXT: 0xe8 ; trap frame
[AArch64] Generate and parse SEH assembly directives This ensures that you get the same output regardless if generating code directly to an object file or if generating assembly and assembling that. Add implementations of the EmitARM64WinCFI*() methods in AArch64TargetAsmStreamer, and fill in one blank in MCAsmStreamer. Add corresponding directive handlers in AArch64AsmParser and COFFAsmParser. Some SEH directive names have been picked to match the prior art for SEH assembly directives for x86_64, e.g. the spelling of ".seh_startepilogue" matching the preexisting ".seh_endprologue". For the directives for saving registers, the exact spelling from the arm64 documentation is picked, e.g. ".seh_save_reg" (to follow that naming for all the other ones, e.g. ".seh_save_fregp_x"), while the corresponding one for x86_64 is plain ".seh_savereg" without the second underscore. Directives in the epilogues have the same names as in prologues, e.g. .seh_savereg, even though the registers are restored, not saved, at that point. Differential Revision: https://reviews.llvm.org/D86529
2020-08-07 17:44:48 +08:00
// CHECK-NEXT: 0xe3 ; nop
// CHECK-NEXT: 0xe202 ; add fp, sp, #16
// CHECK-NEXT: 0xdd41 ; str d13, [sp, #8]
// CHECK-NEXT: 0xde83 ; str d12, [sp, #-32]!
[MC] [Win64EH] Canonicalize ARM64 unwind opcodes Convert 2-byte opcodes to equivalent 1-byte ones. Adjust the existing exhaustive testcase to avoid being altered by the simplification rules (to keep that test exercising all individual opcodes). Fix the assembler parser limits for register pairs; for .seh_save_regp and .seh_save_regp_x, we can allow up to x29, for a x29+x30 pair (which gets remapped to the UOP_SaveFPLR(X) opcodes), for .seh_save_fregp and .seh_save_fregpx, allow up to d14+d15. Not creating .seh_save_next for float register pairs, as the actual unwinder implementation in current versions of Windows is buggy for that case. This gives a minimal but measurable size reduction. (For a 6.5 MB DLL with 300 KB .xdata, the .xdata shrinks by 48 bytes. The opcode sequences are padded to a 4 byte boundary, so very small improvements might not end up mattering directly.) Differential Revision: https://reviews.llvm.org/D87367
2020-09-07 19:45:37 +08:00
// CHECK-NEXT: 0xd884 ; stp d10, d11, [sp, #32]
// CHECK-NEXT: 0xda05 ; stp d8, d9, [sp, #-48]!
[AArch64] Generate and parse SEH assembly directives This ensures that you get the same output regardless if generating code directly to an object file or if generating assembly and assembling that. Add implementations of the EmitARM64WinCFI*() methods in AArch64TargetAsmStreamer, and fill in one blank in MCAsmStreamer. Add corresponding directive handlers in AArch64AsmParser and COFFAsmParser. Some SEH directive names have been picked to match the prior art for SEH assembly directives for x86_64, e.g. the spelling of ".seh_startepilogue" matching the preexisting ".seh_endprologue". For the directives for saving registers, the exact spelling from the arm64 documentation is picked, e.g. ".seh_save_reg" (to follow that naming for all the other ones, e.g. ".seh_save_fregp_x"), while the corresponding one for x86_64 is plain ".seh_savereg" without the second underscore. Directives in the epilogues have the same names as in prologues, e.g. .seh_savereg, even though the registers are restored, not saved, at that point. Differential Revision: https://reviews.llvm.org/D86529
2020-08-07 17:44:48 +08:00
// CHECK-NEXT: 0x83 ; stp x29, x30, [sp, #-32]!
// CHECK-NEXT: 0x46 ; stp x29, x30, [sp, #48]
// CHECK-NEXT: 0xd141 ; str x24, [sp, #8]
// CHECK-NEXT: 0xd483 ; str x23, [sp, #-32]!
[AArch64] Add asm directives for the remaining SEH unwind codes Add support in llvm-readobj for displaying them and support in the asm parsser, AArch64TargetStreamer and MCWin64EH for emitting them. The directives for the remaining basic opcodes have names that match the opcode in the documentation. The directives for custom stack cases, that are named MSFT_OP_TRAP_FRAME, MSFT_OP_MACHINE_FRAME, MSFT_OP_CONTEXT and MSFT_OP_CLEAR_UNWOUND_TO_CALL, are given matching assembler directive names that fit into the rest of the opcode naming; .seh_trap_frame, .seh_context, .seh_clear_unwound_to_call The opcode MSFT_OP_MACHINE_FRAME is mapped to the existing opecode enum UOP_PushMachFrame that is used on x86_64, and also uses the corresponding existing x86_64 directive name .seh_pushframe. Differential Revision: https://reviews.llvm.org/D86889
2020-08-16 05:26:24 +08:00
// CHECK-NEXT: 0xe6 ; save next
[AArch64] Generate and parse SEH assembly directives This ensures that you get the same output regardless if generating code directly to an object file or if generating assembly and assembling that. Add implementations of the EmitARM64WinCFI*() methods in AArch64TargetAsmStreamer, and fill in one blank in MCAsmStreamer. Add corresponding directive handlers in AArch64AsmParser and COFFAsmParser. Some SEH directive names have been picked to match the prior art for SEH assembly directives for x86_64, e.g. the spelling of ".seh_startepilogue" matching the preexisting ".seh_endprologue". For the directives for saving registers, the exact spelling from the arm64 documentation is picked, e.g. ".seh_save_reg" (to follow that naming for all the other ones, e.g. ".seh_save_fregp_x"), while the corresponding one for x86_64 is plain ".seh_savereg" without the second underscore. Directives in the epilogues have the same names as in prologues, e.g. .seh_savereg, even though the registers are restored, not saved, at that point. Differential Revision: https://reviews.llvm.org/D86529
2020-08-07 17:44:48 +08:00
// CHECK-NEXT: 0xc882 ; stp x21, x22, [sp, #16]
[AArch64] Add asm directives for the remaining SEH unwind codes Add support in llvm-readobj for displaying them and support in the asm parsser, AArch64TargetStreamer and MCWin64EH for emitting them. The directives for the remaining basic opcodes have names that match the opcode in the documentation. The directives for custom stack cases, that are named MSFT_OP_TRAP_FRAME, MSFT_OP_MACHINE_FRAME, MSFT_OP_CONTEXT and MSFT_OP_CLEAR_UNWOUND_TO_CALL, are given matching assembler directive names that fit into the rest of the opcode naming; .seh_trap_frame, .seh_context, .seh_clear_unwound_to_call The opcode MSFT_OP_MACHINE_FRAME is mapped to the existing opecode enum UOP_PushMachFrame that is used on x86_64, and also uses the corresponding existing x86_64 directive name .seh_pushframe. Differential Revision: https://reviews.llvm.org/D86889
2020-08-16 05:26:24 +08:00
// CHECK-NEXT: 0xd6c2 ; stp x25, lr, [sp, #16]
// CHECK-NEXT: 0x24 ; stp x19, x20, [sp, #-32]!
[MC] [Win64EH] Canonicalize ARM64 unwind opcodes Convert 2-byte opcodes to equivalent 1-byte ones. Adjust the existing exhaustive testcase to avoid being altered by the simplification rules (to keep that test exercising all individual opcodes). Fix the assembler parser limits for register pairs; for .seh_save_regp and .seh_save_regp_x, we can allow up to x29, for a x29+x30 pair (which gets remapped to the UOP_SaveFPLR(X) opcodes), for .seh_save_fregp and .seh_save_fregpx, allow up to d14+d15. Not creating .seh_save_next for float register pairs, as the actual unwinder implementation in current versions of Windows is buggy for that case. This gives a minimal but measurable size reduction. (For a 6.5 MB DLL with 300 KB .xdata, the .xdata shrinks by 48 bytes. The opcode sequences are padded to a 4 byte boundary, so very small improvements might not end up mattering directly.) Differential Revision: https://reviews.llvm.org/D87367
2020-09-07 19:45:37 +08:00
// CHECK-NEXT: 0xcc83 ; stp x21, x22, [sp, #-32]!
[AArch64] Generate and parse SEH assembly directives This ensures that you get the same output regardless if generating code directly to an object file or if generating assembly and assembling that. Add implementations of the EmitARM64WinCFI*() methods in AArch64TargetAsmStreamer, and fill in one blank in MCAsmStreamer. Add corresponding directive handlers in AArch64AsmParser and COFFAsmParser. Some SEH directive names have been picked to match the prior art for SEH assembly directives for x86_64, e.g. the spelling of ".seh_startepilogue" matching the preexisting ".seh_endprologue". For the directives for saving registers, the exact spelling from the arm64 documentation is picked, e.g. ".seh_save_reg" (to follow that naming for all the other ones, e.g. ".seh_save_fregp_x"), while the corresponding one for x86_64 is plain ".seh_savereg" without the second underscore. Directives in the epilogues have the same names as in prologues, e.g. .seh_savereg, even though the registers are restored, not saved, at that point. Differential Revision: https://reviews.llvm.org/D86529
2020-08-07 17:44:48 +08:00
// CHECK-NEXT: 0x83 ; stp x29, x30, [sp, #-32]!
// CHECK-NEXT: 0xe1 ; mov fp, sp
// CHECK-NEXT: 0x01 ; sub sp, #16
// CHECK-NEXT: 0xe4 ; end
// CHECK-NEXT: ]
[MC] [Win64EH] Write packed ARM64 epilogues if possible This gives a pretty substantial size reduction; for a 6.5 MB DLL with 300 KB .xdata, the .xdata shrinks by 66 KB. Differential Revision: https://reviews.llvm.org/D87369
2020-09-08 05:00:07 +08:00
// CHECK-NEXT: Epilogue [
// CHECK-NEXT: 0x01 ; add sp, #16
// CHECK-NEXT: 0xe4 ; end
[AArch64] Generate and parse SEH assembly directives This ensures that you get the same output regardless if generating code directly to an object file or if generating assembly and assembling that. Add implementations of the EmitARM64WinCFI*() methods in AArch64TargetAsmStreamer, and fill in one blank in MCAsmStreamer. Add corresponding directive handlers in AArch64AsmParser and COFFAsmParser. Some SEH directive names have been picked to match the prior art for SEH assembly directives for x86_64, e.g. the spelling of ".seh_startepilogue" matching the preexisting ".seh_endprologue". For the directives for saving registers, the exact spelling from the arm64 documentation is picked, e.g. ".seh_save_reg" (to follow that naming for all the other ones, e.g. ".seh_save_fregp_x"), while the corresponding one for x86_64 is plain ".seh_savereg" without the second underscore. Directives in the epilogues have the same names as in prologues, e.g. .seh_savereg, even though the registers are restored, not saved, at that point. Differential Revision: https://reviews.llvm.org/D86529
2020-08-07 17:44:48 +08:00
// CHECK-NEXT: ]
// CHECK-NEXT: ExceptionHandler [
// CHECK-NEXT: Routine: __C_specific_handler (0x0)
// CHECK-NEXT: Parameter: 0x0
// CHECK-NEXT: ]
// CHECK-NEXT: }
// CHECK-NEXT: }
// CHECK-NEXT: ]
[AArch64] Avoid crashing on .seh directives in assembly Differential Revision: https://reviews.llvm.org/D55670 llvm-svn: 349549
2018-12-19 06:10:17 +08:00
.text
.globl func
.def func
.scl 2
.type 32
.endef
.seh_proc func
func:
sub sp, sp, #24
.seh_stackalloc 24
mov x29, sp
[AArch64] Generate and parse SEH assembly directives This ensures that you get the same output regardless if generating code directly to an object file or if generating assembly and assembling that. Add implementations of the EmitARM64WinCFI*() methods in AArch64TargetAsmStreamer, and fill in one blank in MCAsmStreamer. Add corresponding directive handlers in AArch64AsmParser and COFFAsmParser. Some SEH directive names have been picked to match the prior art for SEH assembly directives for x86_64, e.g. the spelling of ".seh_startepilogue" matching the preexisting ".seh_endprologue". For the directives for saving registers, the exact spelling from the arm64 documentation is picked, e.g. ".seh_save_reg" (to follow that naming for all the other ones, e.g. ".seh_save_fregp_x"), while the corresponding one for x86_64 is plain ".seh_savereg" without the second underscore. Directives in the epilogues have the same names as in prologues, e.g. .seh_savereg, even though the registers are restored, not saved, at that point. Differential Revision: https://reviews.llvm.org/D86529
2020-08-07 17:44:48 +08:00
.seh_set_fp
stp x29, x30, [sp, #-32]!
.seh_save_fplr_x 32
[MC] [Win64EH] Canonicalize ARM64 unwind opcodes Convert 2-byte opcodes to equivalent 1-byte ones. Adjust the existing exhaustive testcase to avoid being altered by the simplification rules (to keep that test exercising all individual opcodes). Fix the assembler parser limits for register pairs; for .seh_save_regp and .seh_save_regp_x, we can allow up to x29, for a x29+x30 pair (which gets remapped to the UOP_SaveFPLR(X) opcodes), for .seh_save_fregp and .seh_save_fregpx, allow up to d14+d15. Not creating .seh_save_next for float register pairs, as the actual unwinder implementation in current versions of Windows is buggy for that case. This gives a minimal but measurable size reduction. (For a 6.5 MB DLL with 300 KB .xdata, the .xdata shrinks by 48 bytes. The opcode sequences are padded to a 4 byte boundary, so very small improvements might not end up mattering directly.) Differential Revision: https://reviews.llvm.org/D87367
2020-09-07 19:45:37 +08:00
stp x21, x22, [sp, #-32]!
.seh_save_regp_x x21, 32
[AArch64] Add asm directives for the remaining SEH unwind codes Add support in llvm-readobj for displaying them and support in the asm parsser, AArch64TargetStreamer and MCWin64EH for emitting them. The directives for the remaining basic opcodes have names that match the opcode in the documentation. The directives for custom stack cases, that are named MSFT_OP_TRAP_FRAME, MSFT_OP_MACHINE_FRAME, MSFT_OP_CONTEXT and MSFT_OP_CLEAR_UNWOUND_TO_CALL, are given matching assembler directive names that fit into the rest of the opcode naming; .seh_trap_frame, .seh_context, .seh_clear_unwound_to_call The opcode MSFT_OP_MACHINE_FRAME is mapped to the existing opecode enum UOP_PushMachFrame that is used on x86_64, and also uses the corresponding existing x86_64 directive name .seh_pushframe. Differential Revision: https://reviews.llvm.org/D86889
2020-08-16 05:26:24 +08:00
stp x19, x20, [sp, #-32]!
.seh_save_r19r20_x 32
stp x25, x30, [sp, #16]
.seh_save_lrpair x25, 16
[AArch64] Generate and parse SEH assembly directives This ensures that you get the same output regardless if generating code directly to an object file or if generating assembly and assembling that. Add implementations of the EmitARM64WinCFI*() methods in AArch64TargetAsmStreamer, and fill in one blank in MCAsmStreamer. Add corresponding directive handlers in AArch64AsmParser and COFFAsmParser. Some SEH directive names have been picked to match the prior art for SEH assembly directives for x86_64, e.g. the spelling of ".seh_startepilogue" matching the preexisting ".seh_endprologue". For the directives for saving registers, the exact spelling from the arm64 documentation is picked, e.g. ".seh_save_reg" (to follow that naming for all the other ones, e.g. ".seh_save_fregp_x"), while the corresponding one for x86_64 is plain ".seh_savereg" without the second underscore. Directives in the epilogues have the same names as in prologues, e.g. .seh_savereg, even though the registers are restored, not saved, at that point. Differential Revision: https://reviews.llvm.org/D86529
2020-08-07 17:44:48 +08:00
stp x21, x22, [sp, #16]
.seh_save_regp x21, 16
[AArch64] Add asm directives for the remaining SEH unwind codes Add support in llvm-readobj for displaying them and support in the asm parsser, AArch64TargetStreamer and MCWin64EH for emitting them. The directives for the remaining basic opcodes have names that match the opcode in the documentation. The directives for custom stack cases, that are named MSFT_OP_TRAP_FRAME, MSFT_OP_MACHINE_FRAME, MSFT_OP_CONTEXT and MSFT_OP_CLEAR_UNWOUND_TO_CALL, are given matching assembler directive names that fit into the rest of the opcode naming; .seh_trap_frame, .seh_context, .seh_clear_unwound_to_call The opcode MSFT_OP_MACHINE_FRAME is mapped to the existing opecode enum UOP_PushMachFrame that is used on x86_64, and also uses the corresponding existing x86_64 directive name .seh_pushframe. Differential Revision: https://reviews.llvm.org/D86889
2020-08-16 05:26:24 +08:00
stp x23, x24, [sp, #32]
.seh_save_next
[AArch64] Generate and parse SEH assembly directives This ensures that you get the same output regardless if generating code directly to an object file or if generating assembly and assembling that. Add implementations of the EmitARM64WinCFI*() methods in AArch64TargetAsmStreamer, and fill in one blank in MCAsmStreamer. Add corresponding directive handlers in AArch64AsmParser and COFFAsmParser. Some SEH directive names have been picked to match the prior art for SEH assembly directives for x86_64, e.g. the spelling of ".seh_startepilogue" matching the preexisting ".seh_endprologue". For the directives for saving registers, the exact spelling from the arm64 documentation is picked, e.g. ".seh_save_reg" (to follow that naming for all the other ones, e.g. ".seh_save_fregp_x"), while the corresponding one for x86_64 is plain ".seh_savereg" without the second underscore. Directives in the epilogues have the same names as in prologues, e.g. .seh_savereg, even though the registers are restored, not saved, at that point. Differential Revision: https://reviews.llvm.org/D86529
2020-08-07 17:44:48 +08:00
str x23, [sp, #-32]!
.seh_save_reg_x x23, 32
str x24, [sp, #8]
.seh_save_reg x24, 8
stp x29, x30, [sp, #48]
.seh_save_fplr 48
stp x29, x30, [sp, #-32]!
.seh_save_fplr_x 32
[MC] [Win64EH] Canonicalize ARM64 unwind opcodes Convert 2-byte opcodes to equivalent 1-byte ones. Adjust the existing exhaustive testcase to avoid being altered by the simplification rules (to keep that test exercising all individual opcodes). Fix the assembler parser limits for register pairs; for .seh_save_regp and .seh_save_regp_x, we can allow up to x29, for a x29+x30 pair (which gets remapped to the UOP_SaveFPLR(X) opcodes), for .seh_save_fregp and .seh_save_fregpx, allow up to d14+d15. Not creating .seh_save_next for float register pairs, as the actual unwinder implementation in current versions of Windows is buggy for that case. This gives a minimal but measurable size reduction. (For a 6.5 MB DLL with 300 KB .xdata, the .xdata shrinks by 48 bytes. The opcode sequences are padded to a 4 byte boundary, so very small improvements might not end up mattering directly.) Differential Revision: https://reviews.llvm.org/D87367
2020-09-07 19:45:37 +08:00
stp d8, d9, [sp, #-48]!
.seh_save_fregp_x d8, 48
stp d10, d11, [sp, #32]
.seh_save_fregp d10, 32
[AArch64] Generate and parse SEH assembly directives This ensures that you get the same output regardless if generating code directly to an object file or if generating assembly and assembling that. Add implementations of the EmitARM64WinCFI*() methods in AArch64TargetAsmStreamer, and fill in one blank in MCAsmStreamer. Add corresponding directive handlers in AArch64AsmParser and COFFAsmParser. Some SEH directive names have been picked to match the prior art for SEH assembly directives for x86_64, e.g. the spelling of ".seh_startepilogue" matching the preexisting ".seh_endprologue". For the directives for saving registers, the exact spelling from the arm64 documentation is picked, e.g. ".seh_save_reg" (to follow that naming for all the other ones, e.g. ".seh_save_fregp_x"), while the corresponding one for x86_64 is plain ".seh_savereg" without the second underscore. Directives in the epilogues have the same names as in prologues, e.g. .seh_savereg, even though the registers are restored, not saved, at that point. Differential Revision: https://reviews.llvm.org/D86529
2020-08-07 17:44:48 +08:00
str d12, [sp, #-32]!
.seh_save_freg_x d12, 32
str d13, [sp, #8]
.seh_save_freg d13, 8
add x29, sp, #16
.seh_add_fp 16
nop
.seh_nop
[AArch64] Add asm directives for the remaining SEH unwind codes Add support in llvm-readobj for displaying them and support in the asm parsser, AArch64TargetStreamer and MCWin64EH for emitting them. The directives for the remaining basic opcodes have names that match the opcode in the documentation. The directives for custom stack cases, that are named MSFT_OP_TRAP_FRAME, MSFT_OP_MACHINE_FRAME, MSFT_OP_CONTEXT and MSFT_OP_CLEAR_UNWOUND_TO_CALL, are given matching assembler directive names that fit into the rest of the opcode naming; .seh_trap_frame, .seh_context, .seh_clear_unwound_to_call The opcode MSFT_OP_MACHINE_FRAME is mapped to the existing opecode enum UOP_PushMachFrame that is used on x86_64, and also uses the corresponding existing x86_64 directive name .seh_pushframe. Differential Revision: https://reviews.llvm.org/D86889
2020-08-16 05:26:24 +08:00
nop
.seh_trap_frame
nop
.seh_pushframe
nop
.seh_context
nop
.seh_clear_unwound_to_call
[AArch64] Avoid crashing on .seh directives in assembly Differential Revision: https://reviews.llvm.org/D55670 llvm-svn: 349549
2018-12-19 06:10:17 +08:00
.seh_endprologue
[AArch64] Generate and parse SEH assembly directives This ensures that you get the same output regardless if generating code directly to an object file or if generating assembly and assembling that. Add implementations of the EmitARM64WinCFI*() methods in AArch64TargetAsmStreamer, and fill in one blank in MCAsmStreamer. Add corresponding directive handlers in AArch64AsmParser and COFFAsmParser. Some SEH directive names have been picked to match the prior art for SEH assembly directives for x86_64, e.g. the spelling of ".seh_startepilogue" matching the preexisting ".seh_endprologue". For the directives for saving registers, the exact spelling from the arm64 documentation is picked, e.g. ".seh_save_reg" (to follow that naming for all the other ones, e.g. ".seh_save_fregp_x"), while the corresponding one for x86_64 is plain ".seh_savereg" without the second underscore. Directives in the epilogues have the same names as in prologues, e.g. .seh_savereg, even though the registers are restored, not saved, at that point. Differential Revision: https://reviews.llvm.org/D86529
2020-08-07 17:44:48 +08:00
nop
.seh_startepilogue
add sp, sp, #24
.seh_stackalloc 24
.seh_endepilogue
ret
[AArch64] Avoid crashing on .seh directives in assembly Differential Revision: https://reviews.llvm.org/D55670 llvm-svn: 349549
2018-12-19 06:10:17 +08:00
.seh_handler __C_specific_handler, @except
.seh_handlerdata
.long 0
.text
.seh_endproc
[MC] [Win64EH] Avoid producing malformed xdata records If there's no unwinding opcodes, omit writing the xdata/pdata records. Previously, this generated truncated xdata records, and llvm-readobj would error out when trying to print them. If writing of an xdata record is forced via the .seh_handlerdata directive, skip it if there's no info to make a sensible unwind info structure out of, and clearly error out if such info appeared later in the process. Differential Revision: https://reviews.llvm.org/D86527
2020-08-20 15:38:17 +08:00
// Function with no .seh directives; no pdata/xdata entries are
// generated.
[AArch64] Avoid crashing on .seh directives in assembly Differential Revision: https://reviews.llvm.org/D55670 llvm-svn: 349549
2018-12-19 06:10:17 +08:00
.globl smallFunc
.def smallFunc
.scl 2
.type 32
.endef
.seh_proc smallFunc
smallFunc:
ret
.seh_endproc
[MC] [Win64EH] Avoid producing malformed xdata records If there's no unwinding opcodes, omit writing the xdata/pdata records. Previously, this generated truncated xdata records, and llvm-readobj would error out when trying to print them. If writing of an xdata record is forced via the .seh_handlerdata directive, skip it if there's no info to make a sensible unwind info structure out of, and clearly error out if such info appeared later in the process. Differential Revision: https://reviews.llvm.org/D86527
2020-08-20 15:38:17 +08:00
// Function with no .seh directives, but with .seh_handlerdata.
// No xdata/pdata entries are generated, but the custom handler data
// (the .long after .seh_handlerdata) is left orphaned in the xdata
// section.
.globl handlerFunc
.def handlerFunc
.scl 2
.type 32
.endef
.seh_proc handlerFunc
handlerFunc:
ret
.seh_handler __C_specific_handler, @except
.seh_handlerdata
.long 0
.text
.seh_endproc