maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lld/test/COFF/gfids-gc.s

132 lines
3.8 KiB
ArmAsm
Raw Normal View History

[lld] Add REQUIRES: x86 where needed to tests If building lld without x86 support, tests that require that support should be treated as unsupported, not errors. Tested using: 1. cmake '-DLLVM_TARGETS_TO_BUILD=AArch64;X86' make check-lld => Expected Passes : 1406 Unsupported Tests : 287 2. cmake '-DLLVM_TARGETS_TO_BUILD=AArch64' make check-lld => Expected Passes : 410 Unsupported Tests : 1283 Patch by Joel Jones Differential Revision: https://reviews.llvm.org/D47748 llvm-svn: 334095
2018-06-06 21:56:51 +08:00
# REQUIRES: x86
[COFF] Add minimal support for /guard:cf Summary: This patch adds some initial support for Windows control flow guard. At the end of the day, the linker needs to synthesize a table of RVAs very similar to the structured exception handler table (/safeseh). Both /safeseh and /guard:cf take sections of symbol table indices (.sxdata and .gfids$y) and turn them into RVA tables referenced by the load config struct in the CRT through special symbols. Reviewers: ruiu, amccarth Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42592 llvm-svn: 324306
2018-02-06 09:58:26 +08:00
# RUN: llvm-mc -triple x86_64-windows-msvc %s -filetype=obj -o %t.obj
[LLD] Implement /guard:[no]longjmp Summary: This protects calls to longjmp from transferring control to arbitrary program points. Instead, longjmp calls are limited to the set of registered setjmp return addresses. This also implements /guard:nolongjmp to allow users to link in object files that call setjmp that weren't compiled with /guard:cf. In this case, the linker will approximate the set of address taken functions, but it will leave longjmp unprotected. I used the following program to test, compiling it with different -guard flags: $ cl -c t.c -guard:cf $ lld-link t.obj -guard:cf #include <setjmp.h> #include <stdio.h> jmp_buf buf; void g() { printf("before longjmp\n"); fflush(stdout); longjmp(buf, 1); } void f() { if (setjmp(buf)) { printf("setjmp returned non-zero\n"); return; } g(); } int main() { f(); printf("hello world\n"); } In particular, the program aborts when the code is compiled *without* -guard:cf and linked with -guard:cf. That indicates that longjmps are protected. Reviewers: ruiu, inglorion, amccarth Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D43217 llvm-svn: 325047
2018-02-14 04:32:53 +08:00
# RUN: lld-link %t.obj -guard:nolongjmp -out:%t.exe -opt:noref -entry:main
[COFF] Add minimal support for /guard:cf Summary: This patch adds some initial support for Windows control flow guard. At the end of the day, the linker needs to synthesize a table of RVAs very similar to the structured exception handler table (/safeseh). Both /safeseh and /guard:cf take sections of symbol table indices (.sxdata and .gfids$y) and turn them into RVA tables referenced by the load config struct in the CRT through special symbols. Reviewers: ruiu, amccarth Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42592 llvm-svn: 324306
2018-02-06 09:58:26 +08:00
# RUN: llvm-readobj -file-headers -coff-load-config %t.exe | FileCheck %s --check-prefix=CHECK-NOGC
[COFF] Simplify symbol table output section computation Rather than using a loop to compare symbol RVAs to the starting RVAs of sections to determine which section a symbol belongs to, just get the output section of a symbol directly via its chunk, and bail if the symbol doesn't have an output section, which avoids having to hardcode logic for handling dead symbols, CodeView symbols, etc. This was suggested by Reid Kleckner; thank you. This also fixes writing out symbol tables in the presence of RVA table input sections (e.g. .sxdata and .gfids). Such sections aren't written to the output file directly, so their RVA is 0, and the loop would thus fail to find an output section for them, resulting in a segfault. Extend some existing tests to cover this case. Fixes PR37584. Differential Revision: https://reviews.llvm.org/D47391 llvm-svn: 333450
2018-05-30 03:07:47 +08:00
# RUN: lld-link %t.obj -guard:nolongjmp -out:%t.exe -opt:noref -entry:main -debug:dwarf
# RUN: llvm-readobj -file-headers -coff-load-config %t.exe | FileCheck %s --check-prefix=CHECK-NOGC
[LLD] Implement /guard:[no]longjmp Summary: This protects calls to longjmp from transferring control to arbitrary program points. Instead, longjmp calls are limited to the set of registered setjmp return addresses. This also implements /guard:nolongjmp to allow users to link in object files that call setjmp that weren't compiled with /guard:cf. In this case, the linker will approximate the set of address taken functions, but it will leave longjmp unprotected. I used the following program to test, compiling it with different -guard flags: $ cl -c t.c -guard:cf $ lld-link t.obj -guard:cf #include <setjmp.h> #include <stdio.h> jmp_buf buf; void g() { printf("before longjmp\n"); fflush(stdout); longjmp(buf, 1); } void f() { if (setjmp(buf)) { printf("setjmp returned non-zero\n"); return; } g(); } int main() { f(); printf("hello world\n"); } In particular, the program aborts when the code is compiled *without* -guard:cf and linked with -guard:cf. That indicates that longjmps are protected. Reviewers: ruiu, inglorion, amccarth Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D43217 llvm-svn: 325047
2018-02-14 04:32:53 +08:00
# RUN: lld-link %t.obj -guard:nolongjmp -out:%t.exe -opt:ref -entry:main
[COFF] Add minimal support for /guard:cf Summary: This patch adds some initial support for Windows control flow guard. At the end of the day, the linker needs to synthesize a table of RVAs very similar to the structured exception handler table (/safeseh). Both /safeseh and /guard:cf take sections of symbol table indices (.sxdata and .gfids$y) and turn them into RVA tables referenced by the load config struct in the CRT through special symbols. Reviewers: ruiu, amccarth Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42592 llvm-svn: 324306
2018-02-06 09:58:26 +08:00
# RUN: llvm-readobj -file-headers -coff-load-config %t.exe | FileCheck %s --check-prefix=CHECK-GC
# This assembly is meant to mimic what CL emits for this kind of C code when
# /Gw (-fdata-sections) is enabled:
# int f() { return 42; }
# int g() { return 13; }
# int (*fp1)() = &f;
# int (*fp2)() = &g;
# int main() {
# return fp1();
# }
# Compile with 'cl -c -guard:cf -Gw -O1' and note the two associative .gfids$y
# sections.
# Expect 3 entries: main, f, and g.
# CHECK-NOGC: ImageBase: 0x140000000
# CHECK-NOGC: LoadConfig [
# CHECK-NOGC: SEHandlerTable: 0x0
# CHECK-NOGC: SEHandlerCount: 0
# CHECK-NOGC: GuardCFCheckFunction: 0x0
# CHECK-NOGC: GuardCFCheckDispatch: 0x0
# CHECK-NOGC: GuardCFFunctionTable: 0x14000{{.*}}
# CHECK-NOGC: GuardCFFunctionCount: 3
# CHECK-NOGC: GuardFlags: 0x500
# CHECK-NOGC: GuardAddressTakenIatEntryTable: 0x0
# CHECK-NOGC: GuardAddressTakenIatEntryCount: 0
# CHECK-NOGC: GuardLongJumpTargetTable: 0x0
# CHECK-NOGC: GuardLongJumpTargetCount: 0
# CHECK-NOGC: ]
# CHECK-NOGC: GuardFidTable [
# CHECK-NOGC-NEXT: 0x14000{{.*}}
# CHECK-NOGC-NEXT: 0x14000{{.*}}
# CHECK-NOGC-NEXT: 0x14000{{.*}}
# CHECK-NOGC-NEXT: ]
# Expect 2 entries: main and f. fp2 was discarded, so g was only used as a
# direct call target.
# CHECK-GC: ImageBase: 0x140000000
# CHECK-GC: LoadConfig [
# CHECK-GC: SEHandlerTable: 0x0
# CHECK-GC: SEHandlerCount: 0
# CHECK-GC: GuardCFCheckFunction: 0x0
# CHECK-GC: GuardCFCheckDispatch: 0x0
# CHECK-GC: GuardCFFunctionTable: 0x14000{{.*}}
# CHECK-GC: GuardCFFunctionCount: 2
# CHECK-GC: GuardFlags: 0x500
# CHECK-GC: GuardAddressTakenIatEntryTable: 0x0
# CHECK-GC: GuardAddressTakenIatEntryCount: 0
# CHECK-GC: GuardLongJumpTargetTable: 0x0
# CHECK-GC: GuardLongJumpTargetCount: 0
# CHECK-GC: ]
# CHECK-GC: GuardFidTable [
# CHECK-GC-NEXT: 0x14000{{.*}}
# CHECK-GC-NEXT: 0x14000{{.*}}
# CHECK-GC-NEXT: ]
# We need @feat.00 to have 0x800 to indicate .gfids are present.
.def @feat.00;
.scl 3;
.type 0;
.endef
.globl @feat.00
@feat.00 = 0x801
.def main;
.scl 2;
.type 32;
.endef
.section .text,"xr",one_only,main
.globl main
main:
# Call g directly so that it is not dead stripped.
callq g
rex64 jmpq *fp1(%rip)
.def f;
.scl 3;
.type 32;
.endef
.section .text,"xr",one_only,f
f:
movl $42, %eax
retq
.section .data,"dw",one_only,fp1
.globl fp1
fp1:
.quad f
.section .gfids$y,"dr",associative,fp1
.symidx f
# Section GC will remove the following, so 'g' should not be present in the
# guard fid table.
.def g;
.scl 3;
.type 32;
.endef
.section .text,"xr",one_only,g
g:
movl $13, %eax
retq
.section .data,"dw",one_only,fp2
.globl fp2
fp2:
.quad g
.section .gfids$y,"dr",associative,fp2
.symidx g
.section .rdata,"dr"
.globl _load_config_used
_load_config_used:
.long 256
.fill 124, 1, 0
.quad __guard_fids_table
.quad __guard_fids_count
.long __guard_flags
.fill 128, 1, 0