RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-22 18:54:02 +01:00
Code Issues Projects Releases Wiki Activity
9770d34891
llvm-mirror/test/ThinLTO/X86/nossp.ll

71 lines
1.8 KiB
LLVM
Raw Normal View History

[Inline] prevent inlining on stack protector mismatch It's common for code that manipulates the stack via inline assembly or that has to set up its own stack canary (such as the Linux kernel) would like to avoid stack protectors in certain functions. In this case, we've been bitten by numerous bugs where a callee with a stack protector is inlined into an attribute((no_stack_protector)) caller, which generally breaks the caller's assumptions about not having a stack protector. LTO exacerbates the issue. While developers can avoid this by putting all no_stack_protector functions in one translation unit together and compiling those with -fno-stack-protector, it's generally not very ergonomic or as ergonomic as a function attribute, and still doesn't work for LTO. See also: https://lore.kernel.org/linux-pm/20200915172658.1432732-1-rkir@google.com/ https://lore.kernel.org/lkml/20200918201436.2932360-30-samitolvanen@google.com/T/#u SSP attributes can be ordered by strength. Weakest to strongest, they are: ssp, sspstrong, sspreq. Callees with differing SSP attributes may be inlined into each other, and the strongest attribute will be applied to the caller. (No change) After this change: * A callee with no SSP attributes will no longer be inlined into a caller with SSP attributes. * The reverse is also true: a callee with an SSP attribute will not be inlined into a caller with no SSP attributes. * The alwaysinline attribute overrides these rules. Functions that get synthesized by the compiler may not get inlined as a result if they are not created with the same stack protector function attribute as their callers. Alternative approach to https://reviews.llvm.org/D87956. Fixes pr/47479. Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed By: rnk, MaskRay Differential Revision: https://reviews.llvm.org/D91816
2020-12-02 19:44:35 +01:00
; RUN: split-file %s %t
[ThinLTO][test] Fix X86/nossp.ll after D91816
2020-12-02 22:13:58 +01:00
; RUN: opt -module-summary %t/a.ll -o %ta.bc
; RUN: opt -module-summary %t/b.ll -o %tb.bc
; RUN: llvm-lto2 run %ta.bc %tb.bc -o %tc.bc -save-temps \
; RUN: -r=%ta.bc,nossp_caller,px \
; RUN: -r=%ta.bc,ssp_caller,px \
; RUN: -r=%ta.bc,nossp_caller2,px \
; RUN: -r=%ta.bc,ssp_caller2,px \
; RUN: -r=%ta.bc,nossp_callee,x \
; RUN: -r=%ta.bc,ssp_callee,x \
; RUN: -r=%tb.bc,nossp_callee,px \
; RUN: -r=%tb.bc,ssp_callee,px \
; RUN: -r=%tb.bc,foo
; RUN: llvm-dis %tc.bc.1.4.opt.bc -o - | FileCheck %s
[Inline] prevent inlining on stack protector mismatch It's common for code that manipulates the stack via inline assembly or that has to set up its own stack canary (such as the Linux kernel) would like to avoid stack protectors in certain functions. In this case, we've been bitten by numerous bugs where a callee with a stack protector is inlined into an attribute((no_stack_protector)) caller, which generally breaks the caller's assumptions about not having a stack protector. LTO exacerbates the issue. While developers can avoid this by putting all no_stack_protector functions in one translation unit together and compiling those with -fno-stack-protector, it's generally not very ergonomic or as ergonomic as a function attribute, and still doesn't work for LTO. See also: https://lore.kernel.org/linux-pm/20200915172658.1432732-1-rkir@google.com/ https://lore.kernel.org/lkml/20200918201436.2932360-30-samitolvanen@google.com/T/#u SSP attributes can be ordered by strength. Weakest to strongest, they are: ssp, sspstrong, sspreq. Callees with differing SSP attributes may be inlined into each other, and the strongest attribute will be applied to the caller. (No change) After this change: * A callee with no SSP attributes will no longer be inlined into a caller with SSP attributes. * The reverse is also true: a callee with an SSP attribute will not be inlined into a caller with no SSP attributes. * The alwaysinline attribute overrides these rules. Functions that get synthesized by the compiler may not get inlined as a result if they are not created with the same stack protector function attribute as their callers. Alternative approach to https://reviews.llvm.org/D87956. Fixes pr/47479. Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed By: rnk, MaskRay Differential Revision: https://reviews.llvm.org/D91816
2020-12-02 19:44:35 +01:00
;--- a.ll
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-pc-linux-gnu"
declare void @nossp_callee()
declare void @ssp_callee() ssp
; nossp caller should be able to inline nossp callee.
define void @nossp_caller() {
; CHECK-LABEL: @nossp_caller
; CHECK-NEXT: tail call void @foo
tail call void @nossp_callee()
ret void
}
; ssp caller should be able to inline ssp callee.
define void @ssp_caller() ssp {
; CHECK-LABEL: @ssp_caller
; CHECK-NEXT: tail call void @foo
tail call void @ssp_callee()
ret void
}
; nossp caller should *NOT* be able to inline ssp callee.
define void @nossp_caller2() {
; CHECK-LABEL: @nossp_caller2
; CHECK-NEXT: tail call void @ssp_callee
tail call void @ssp_callee()
ret void
}
; ssp caller should *NOT* be able to inline nossp callee.
define void @ssp_caller2() ssp {
; CHECK-LABEL: @ssp_caller2
; CHECK-NEXT: tail call void @nossp_callee
tail call void @nossp_callee()
ret void
}
;--- b.ll
target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-pc-linux-gnu"
declare void @foo()
define void @nossp_callee() {
call void @foo()
ret void
}
define void @ssp_callee() ssp {
call void @foo()
ret void
}
Reference in New Issue Copy Permalink