2015-05-06 01:44:16 +08:00
|
|
|
//===-- X86WinEHState - Insert EH state updates for win32 exceptions ------===//
|
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2015-05-06 01:44:16 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// All functions using an MSVC EH personality use an explicitly updated state
|
|
|
|
// number stored in an exception registration stack object. The registration
|
|
|
|
// object is linked into a thread-local chain of registrations stored at fs:00.
|
|
|
|
// This pass adds the registration object and EH state updates.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "X86.h"
|
2016-02-18 02:37:11 +08:00
|
|
|
#include "llvm/ADT/PostOrderIterator.h"
|
|
|
|
#include "llvm/Analysis/CFG.h"
|
2015-12-03 07:06:39 +08:00
|
|
|
#include "llvm/Analysis/EHPersonalities.h"
|
2015-05-29 06:00:24 +08:00
|
|
|
#include "llvm/CodeGen/MachineModuleInfo.h"
|
2015-05-06 01:44:16 +08:00
|
|
|
#include "llvm/CodeGen/WinEHFuncInfo.h"
|
2016-02-18 02:37:11 +08:00
|
|
|
#include "llvm/IR/CallSite.h"
|
|
|
|
#include "llvm/IR/Function.h"
|
2017-06-06 19:49:48 +08:00
|
|
|
#include "llvm/IR/IRBuilder.h"
|
2015-05-06 01:44:16 +08:00
|
|
|
#include "llvm/IR/Instructions.h"
|
|
|
|
#include "llvm/IR/IntrinsicInst.h"
|
|
|
|
#include "llvm/IR/Module.h"
|
|
|
|
#include "llvm/Pass.h"
|
2016-02-18 02:37:11 +08:00
|
|
|
#include "llvm/Support/Debug.h"
|
|
|
|
#include <deque>
|
2015-05-06 01:44:16 +08:00
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
|
|
|
|
#define DEBUG_TYPE "winehstate"
|
|
|
|
|
|
|
|
namespace {
|
2016-02-18 02:37:11 +08:00
|
|
|
const int OverdefinedState = INT_MIN;
|
|
|
|
|
2015-05-06 01:44:16 +08:00
|
|
|
class WinEHStatePass : public FunctionPass {
|
|
|
|
public:
|
|
|
|
static char ID; // Pass identification, replacement for typeid.
|
|
|
|
|
2019-06-13 10:09:32 +08:00
|
|
|
WinEHStatePass() : FunctionPass(ID) { }
|
2015-05-06 01:44:16 +08:00
|
|
|
|
|
|
|
bool runOnFunction(Function &Fn) override;
|
|
|
|
|
|
|
|
bool doInitialization(Module &M) override;
|
|
|
|
|
|
|
|
bool doFinalization(Module &M) override;
|
|
|
|
|
|
|
|
void getAnalysisUsage(AnalysisUsage &AU) const override;
|
|
|
|
|
2016-10-01 10:56:57 +08:00
|
|
|
StringRef getPassName() const override {
|
2015-05-06 01:44:16 +08:00
|
|
|
return "Windows 32-bit x86 EH state insertion";
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
void emitExceptionRegistrationRecord(Function *F);
|
|
|
|
|
2015-06-10 09:02:30 +08:00
|
|
|
void linkExceptionRegistration(IRBuilder<> &Builder, Function *Handler);
|
2015-05-29 06:00:24 +08:00
|
|
|
void unlinkExceptionRegistration(IRBuilder<> &Builder);
|
2015-11-18 05:10:25 +08:00
|
|
|
void addStateStores(Function &F, WinEHFuncInfo &FuncInfo);
|
2016-02-01 12:28:59 +08:00
|
|
|
void insertStateNumberStore(Instruction *IP, int State);
|
2015-05-06 01:44:16 +08:00
|
|
|
|
2015-05-21 07:08:04 +08:00
|
|
|
Value *emitEHLSDA(IRBuilder<> &Builder, Function *F);
|
|
|
|
|
|
|
|
Function *generateLSDAInEAXThunk(Function *ParentFunc);
|
|
|
|
|
2016-03-01 03:16:03 +08:00
|
|
|
bool isStateStoreNeeded(EHPersonality Personality, CallSite CS);
|
|
|
|
void rewriteSetJmpCallSite(IRBuilder<> &Builder, Function &F, CallSite CS,
|
|
|
|
Value *State);
|
|
|
|
int getBaseStateForBB(DenseMap<BasicBlock *, ColorVector> &BlockColors,
|
|
|
|
WinEHFuncInfo &FuncInfo, BasicBlock *BB);
|
|
|
|
int getStateForCallSite(DenseMap<BasicBlock *, ColorVector> &BlockColors,
|
|
|
|
WinEHFuncInfo &FuncInfo, CallSite CS);
|
|
|
|
|
2015-05-06 01:44:16 +08:00
|
|
|
// Module-level type getters.
|
2015-05-30 06:57:46 +08:00
|
|
|
Type *getEHLinkRegistrationType();
|
|
|
|
Type *getSEHRegistrationType();
|
|
|
|
Type *getCXXEHRegistrationType();
|
2015-05-06 01:44:16 +08:00
|
|
|
|
|
|
|
// Per-module data.
|
|
|
|
Module *TheModule = nullptr;
|
2015-05-30 06:57:46 +08:00
|
|
|
StructType *EHLinkRegistrationTy = nullptr;
|
|
|
|
StructType *CXXEHRegistrationTy = nullptr;
|
|
|
|
StructType *SEHRegistrationTy = nullptr;
|
[opaque pointer types] Add a FunctionCallee wrapper type, and use it.
Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.
Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.
Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.
One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.
However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)
Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.
Differential Revision: https://reviews.llvm.org/D57315
llvm-svn: 352827
2019-02-01 10:28:03 +08:00
|
|
|
FunctionCallee SetJmp3 = nullptr;
|
|
|
|
FunctionCallee CxxLongjmpUnwind = nullptr;
|
2015-05-06 01:44:16 +08:00
|
|
|
|
|
|
|
// Per-function state
|
|
|
|
EHPersonality Personality = EHPersonality::Unknown;
|
|
|
|
Function *PersonalityFn = nullptr;
|
2016-02-18 02:37:11 +08:00
|
|
|
bool UseStackGuard = false;
|
|
|
|
int ParentBaseState;
|
[opaque pointer types] Add a FunctionCallee wrapper type, and use it.
Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.
Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.
Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.
One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.
However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)
Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.
Differential Revision: https://reviews.llvm.org/D57315
llvm-svn: 352827
2019-02-01 10:28:03 +08:00
|
|
|
FunctionCallee SehLongjmpUnwind = nullptr;
|
2016-03-01 03:16:03 +08:00
|
|
|
Constant *Cookie = nullptr;
|
2015-05-29 06:00:24 +08:00
|
|
|
|
|
|
|
/// The stack allocation containing all EH data, including the link in the
|
|
|
|
/// fs:00 chain and the current state.
|
|
|
|
AllocaInst *RegNode = nullptr;
|
|
|
|
|
[StackProtector] Fix computation of GSCookieOffset and EHCookieOffset with SEH4
Summary:
Fix the computation of the offsets present in the scopetable when using the
SEH (__except_handler4).
This patch added an intrinsic to track the position of the allocation on the
stack of the EHGuard. This position is needed when producing the ScopeTable.
```
struct _EH4_SCOPETABLE {
DWORD GSCookieOffset;
DWORD GSCookieXOROffset;
DWORD EHCookieOffset;
DWORD EHCookieXOROffset;
_EH4_SCOPETABLE_RECORD ScopeRecord[1];
};
struct _EH4_SCOPETABLE_RECORD {
DWORD EnclosingLevel;
long (*FilterFunc)();
union {
void (*HandlerAddress)();
void (*FinallyFunc)();
};
};
```
The code to generate the EHCookie is added in `X86WinEHState.cpp`.
Which is adding these instructions when using SEH4.
```
Lfunc_begin0:
# BB#0: # %entry
pushl %ebp
movl %esp, %ebp
pushl %ebx
pushl %edi
pushl %esi
subl $28, %esp
movl %ebp, %eax <<-- Loading FramePtr
movl %esp, -36(%ebp)
movl $-2, -16(%ebp)
movl $L__ehtable$use_except_handler4_ssp, %ecx
xorl ___security_cookie, %ecx
movl %ecx, -20(%ebp)
xorl ___security_cookie, %eax <<-- XOR FramePtr and Cookie
movl %eax, -40(%ebp) <<-- Storing EHGuard
leal -28(%ebp), %eax
movl $__except_handler4, -24(%ebp)
movl %fs:0, %ecx
movl %ecx, -28(%ebp)
movl %eax, %fs:0
movl $0, -16(%ebp)
calll _may_throw_or_crash
LBB1_1: # %cont
movl -28(%ebp), %eax
movl %eax, %fs:0
addl $28, %esp
popl %esi
popl %edi
popl %ebx
popl %ebp
retl
```
And the corresponding offset is computed:
```
Luse_except_handler4_ssp$parent_frame_offset = -36
.p2align 2
L__ehtable$use_except_handler4_ssp:
.long -2 # GSCookieOffset
.long 0 # GSCookieXOROffset
.long -40 # EHCookieOffset <<----
.long 0 # EHCookieXOROffset
.long -2 # ToState
.long _catchall_filt # FilterFunction
.long LBB1_2 # ExceptionHandler
```
Clang is not yet producing function using SEH4, but it's a work in progress.
This patch is a step toward having a valid implementation of SEH4.
Unfortunately, it is not yet fully working. The EH registration block is not
allocated at the right offset on the stack.
Reviewers: rnk, majnemer
Subscribers: llvm-commits, chrisha
Differential Revision: http://reviews.llvm.org/D21231
llvm-svn: 273281
2016-06-21 23:58:55 +08:00
|
|
|
// The allocation containing the EH security guard.
|
|
|
|
AllocaInst *EHGuardNode = nullptr;
|
|
|
|
|
2015-05-29 06:00:24 +08:00
|
|
|
/// The index of the state field of RegNode.
|
|
|
|
int StateFieldIndex = ~0U;
|
|
|
|
|
|
|
|
/// The linked list node subobject inside of RegNode.
|
|
|
|
Value *Link = nullptr;
|
2015-05-06 01:44:16 +08:00
|
|
|
};
|
2015-06-23 17:49:53 +08:00
|
|
|
}
|
2015-05-06 01:44:16 +08:00
|
|
|
|
|
|
|
FunctionPass *llvm::createX86WinEHStatePass() { return new WinEHStatePass(); }
|
|
|
|
|
|
|
|
char WinEHStatePass::ID = 0;
|
|
|
|
|
2015-08-19 03:07:12 +08:00
|
|
|
INITIALIZE_PASS(WinEHStatePass, "x86-winehstate",
|
|
|
|
"Insert stores for EH state numbers", false, false)
|
|
|
|
|
2015-05-06 01:44:16 +08:00
|
|
|
bool WinEHStatePass::doInitialization(Module &M) {
|
|
|
|
TheModule = &M;
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool WinEHStatePass::doFinalization(Module &M) {
|
|
|
|
assert(TheModule == &M);
|
|
|
|
TheModule = nullptr;
|
2015-05-30 06:57:46 +08:00
|
|
|
EHLinkRegistrationTy = nullptr;
|
|
|
|
CXXEHRegistrationTy = nullptr;
|
|
|
|
SEHRegistrationTy = nullptr;
|
2016-03-01 03:16:03 +08:00
|
|
|
SetJmp3 = nullptr;
|
|
|
|
CxxLongjmpUnwind = nullptr;
|
|
|
|
SehLongjmpUnwind = nullptr;
|
|
|
|
Cookie = nullptr;
|
2015-05-06 01:44:16 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
void WinEHStatePass::getAnalysisUsage(AnalysisUsage &AU) const {
|
|
|
|
// This pass should only insert a stack allocation, memory accesses, and
|
Rename llvm.frameescape and llvm.framerecover to localescape and localrecover
Summary:
Initially, these intrinsics seemed like part of a family of "frame"
related intrinsics, but now I think that's more confusing than helpful.
Initially, the LangRef specified that this would create a new kind of
allocation that would be allocated at a fixed offset from the frame
pointer (EBP/RBP). We ended up dropping that design, and leaving the
stack frame layout alone.
These intrinsics are really about sharing local stack allocations, not
frame pointers. I intend to go further and add an `llvm.localaddress()`
intrinsic that returns whatever register (EBP, ESI, ESP, RBX) is being
used to address locals, which should not be confused with the frame
pointer.
Naming suggestions at this point are welcome, I'm happy to re-run sed.
Reviewers: majnemer, nicholas
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11011
llvm-svn: 241633
2015-07-08 06:25:32 +08:00
|
|
|
// localrecovers.
|
2015-05-06 01:44:16 +08:00
|
|
|
AU.setPreservesCFG();
|
|
|
|
}
|
|
|
|
|
|
|
|
bool WinEHStatePass::runOnFunction(Function &F) {
|
2017-12-29 02:41:31 +08:00
|
|
|
// Don't insert state stores or exception handler thunks for
|
|
|
|
// available_externally functions. The handler needs to reference the LSDA,
|
|
|
|
// which will not be emitted in this case.
|
|
|
|
if (F.hasAvailableExternallyLinkage())
|
|
|
|
return false;
|
|
|
|
|
2015-10-07 04:28:16 +08:00
|
|
|
// Check the personality. Do nothing if this personality doesn't use funclets.
|
2015-06-18 04:52:32 +08:00
|
|
|
if (!F.hasPersonalityFn())
|
2015-05-06 01:44:16 +08:00
|
|
|
return false;
|
|
|
|
PersonalityFn =
|
2015-06-18 04:52:32 +08:00
|
|
|
dyn_cast<Function>(F.getPersonalityFn()->stripPointerCasts());
|
2015-05-06 01:44:16 +08:00
|
|
|
if (!PersonalityFn)
|
|
|
|
return false;
|
|
|
|
Personality = classifyEHPersonality(PersonalityFn);
|
2015-10-07 04:28:16 +08:00
|
|
|
if (!isFuncletEHPersonality(Personality))
|
2015-05-06 01:44:16 +08:00
|
|
|
return false;
|
|
|
|
|
2015-09-17 01:19:44 +08:00
|
|
|
// Skip this function if there are no EH pads and we aren't using IR-level
|
|
|
|
// outlining.
|
2015-10-10 08:04:29 +08:00
|
|
|
bool HasPads = false;
|
|
|
|
for (BasicBlock &BB : F) {
|
|
|
|
if (BB.isEHPad()) {
|
|
|
|
HasPads = true;
|
|
|
|
break;
|
2015-09-17 01:19:44 +08:00
|
|
|
}
|
|
|
|
}
|
2015-10-10 08:04:29 +08:00
|
|
|
if (!HasPads)
|
|
|
|
return false;
|
2015-09-17 01:19:44 +08:00
|
|
|
|
2016-03-01 03:16:03 +08:00
|
|
|
Type *Int8PtrType = Type::getInt8PtrTy(TheModule->getContext());
|
|
|
|
SetJmp3 = TheModule->getOrInsertFunction(
|
|
|
|
"_setjmp3", FunctionType::get(
|
|
|
|
Type::getInt32Ty(TheModule->getContext()),
|
|
|
|
{Int8PtrType, Type::getInt32Ty(TheModule->getContext())},
|
|
|
|
/*isVarArg=*/true));
|
2016-02-20 15:34:21 +08:00
|
|
|
|
2015-05-30 05:58:11 +08:00
|
|
|
// Disable frame pointer elimination in this function.
|
|
|
|
// FIXME: Do the nested handlers need to keep the parent ebp in ebp, or can we
|
|
|
|
// use an arbitrary register?
|
|
|
|
F.addFnAttr("no-frame-pointer-elim", "true");
|
|
|
|
|
2015-05-06 01:44:16 +08:00
|
|
|
emitExceptionRegistrationRecord(&F);
|
2015-05-29 06:00:24 +08:00
|
|
|
|
2015-11-18 05:10:25 +08:00
|
|
|
// The state numbers calculated here in IR must agree with what we calculate
|
|
|
|
// later on for the MachineFunction. In particular, if an IR pass deletes an
|
|
|
|
// unreachable EH pad after this point before machine CFG construction, we
|
|
|
|
// will be in trouble. If this assumption is ever broken, we should turn the
|
|
|
|
// numbers into an immutable analysis pass.
|
|
|
|
WinEHFuncInfo FuncInfo;
|
|
|
|
addStateStores(F, FuncInfo);
|
2015-05-06 01:44:16 +08:00
|
|
|
|
|
|
|
// Reset per-function state.
|
|
|
|
PersonalityFn = nullptr;
|
|
|
|
Personality = EHPersonality::Unknown;
|
2016-02-18 02:37:11 +08:00
|
|
|
UseStackGuard = false;
|
[StackProtector] Fix computation of GSCookieOffset and EHCookieOffset with SEH4
Summary:
Fix the computation of the offsets present in the scopetable when using the
SEH (__except_handler4).
This patch added an intrinsic to track the position of the allocation on the
stack of the EHGuard. This position is needed when producing the ScopeTable.
```
struct _EH4_SCOPETABLE {
DWORD GSCookieOffset;
DWORD GSCookieXOROffset;
DWORD EHCookieOffset;
DWORD EHCookieXOROffset;
_EH4_SCOPETABLE_RECORD ScopeRecord[1];
};
struct _EH4_SCOPETABLE_RECORD {
DWORD EnclosingLevel;
long (*FilterFunc)();
union {
void (*HandlerAddress)();
void (*FinallyFunc)();
};
};
```
The code to generate the EHCookie is added in `X86WinEHState.cpp`.
Which is adding these instructions when using SEH4.
```
Lfunc_begin0:
# BB#0: # %entry
pushl %ebp
movl %esp, %ebp
pushl %ebx
pushl %edi
pushl %esi
subl $28, %esp
movl %ebp, %eax <<-- Loading FramePtr
movl %esp, -36(%ebp)
movl $-2, -16(%ebp)
movl $L__ehtable$use_except_handler4_ssp, %ecx
xorl ___security_cookie, %ecx
movl %ecx, -20(%ebp)
xorl ___security_cookie, %eax <<-- XOR FramePtr and Cookie
movl %eax, -40(%ebp) <<-- Storing EHGuard
leal -28(%ebp), %eax
movl $__except_handler4, -24(%ebp)
movl %fs:0, %ecx
movl %ecx, -28(%ebp)
movl %eax, %fs:0
movl $0, -16(%ebp)
calll _may_throw_or_crash
LBB1_1: # %cont
movl -28(%ebp), %eax
movl %eax, %fs:0
addl $28, %esp
popl %esi
popl %edi
popl %ebx
popl %ebp
retl
```
And the corresponding offset is computed:
```
Luse_except_handler4_ssp$parent_frame_offset = -36
.p2align 2
L__ehtable$use_except_handler4_ssp:
.long -2 # GSCookieOffset
.long 0 # GSCookieXOROffset
.long -40 # EHCookieOffset <<----
.long 0 # EHCookieXOROffset
.long -2 # ToState
.long _catchall_filt # FilterFunction
.long LBB1_2 # ExceptionHandler
```
Clang is not yet producing function using SEH4, but it's a work in progress.
This patch is a step toward having a valid implementation of SEH4.
Unfortunately, it is not yet fully working. The EH registration block is not
allocated at the right offset on the stack.
Reviewers: rnk, majnemer
Subscribers: llvm-commits, chrisha
Differential Revision: http://reviews.llvm.org/D21231
llvm-svn: 273281
2016-06-21 23:58:55 +08:00
|
|
|
RegNode = nullptr;
|
|
|
|
EHGuardNode = nullptr;
|
|
|
|
|
2015-05-06 01:44:16 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Get the common EH registration subobject:
|
2015-05-21 07:08:04 +08:00
|
|
|
/// typedef _EXCEPTION_DISPOSITION (*PEXCEPTION_ROUTINE)(
|
|
|
|
/// _EXCEPTION_RECORD *, void *, _CONTEXT *, void *);
|
2015-05-06 01:44:16 +08:00
|
|
|
/// struct EHRegistrationNode {
|
|
|
|
/// EHRegistrationNode *Next;
|
2015-05-21 07:08:04 +08:00
|
|
|
/// PEXCEPTION_ROUTINE Handler;
|
2015-05-06 01:44:16 +08:00
|
|
|
/// };
|
2015-05-30 06:57:46 +08:00
|
|
|
Type *WinEHStatePass::getEHLinkRegistrationType() {
|
|
|
|
if (EHLinkRegistrationTy)
|
|
|
|
return EHLinkRegistrationTy;
|
2015-05-06 01:44:16 +08:00
|
|
|
LLVMContext &Context = TheModule->getContext();
|
2015-05-30 06:57:46 +08:00
|
|
|
EHLinkRegistrationTy = StructType::create(Context, "EHRegistrationNode");
|
2015-05-06 01:44:16 +08:00
|
|
|
Type *FieldTys[] = {
|
2015-05-30 06:57:46 +08:00
|
|
|
EHLinkRegistrationTy->getPointerTo(0), // EHRegistrationNode *Next
|
2015-05-06 01:44:16 +08:00
|
|
|
Type::getInt8PtrTy(Context) // EXCEPTION_DISPOSITION (*Handler)(...)
|
|
|
|
};
|
2015-05-30 06:57:46 +08:00
|
|
|
EHLinkRegistrationTy->setBody(FieldTys, false);
|
|
|
|
return EHLinkRegistrationTy;
|
2015-05-06 01:44:16 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/// The __CxxFrameHandler3 registration node:
|
|
|
|
/// struct CXXExceptionRegistration {
|
|
|
|
/// void *SavedESP;
|
|
|
|
/// EHRegistrationNode SubRecord;
|
|
|
|
/// int32_t TryLevel;
|
|
|
|
/// };
|
2015-05-30 06:57:46 +08:00
|
|
|
Type *WinEHStatePass::getCXXEHRegistrationType() {
|
|
|
|
if (CXXEHRegistrationTy)
|
|
|
|
return CXXEHRegistrationTy;
|
2015-05-06 01:44:16 +08:00
|
|
|
LLVMContext &Context = TheModule->getContext();
|
|
|
|
Type *FieldTys[] = {
|
|
|
|
Type::getInt8PtrTy(Context), // void *SavedESP
|
2015-05-30 06:57:46 +08:00
|
|
|
getEHLinkRegistrationType(), // EHRegistrationNode SubRecord
|
2015-05-06 01:44:16 +08:00
|
|
|
Type::getInt32Ty(Context) // int32_t TryLevel
|
|
|
|
};
|
2015-05-30 06:57:46 +08:00
|
|
|
CXXEHRegistrationTy =
|
2015-05-06 01:44:16 +08:00
|
|
|
StructType::create(FieldTys, "CXXExceptionRegistration");
|
2015-05-30 06:57:46 +08:00
|
|
|
return CXXEHRegistrationTy;
|
2015-05-06 01:44:16 +08:00
|
|
|
}
|
|
|
|
|
2015-05-30 06:57:46 +08:00
|
|
|
/// The _except_handler3/4 registration node:
|
2015-05-06 01:44:16 +08:00
|
|
|
/// struct EH4ExceptionRegistration {
|
|
|
|
/// void *SavedESP;
|
|
|
|
/// _EXCEPTION_POINTERS *ExceptionPointers;
|
|
|
|
/// EHRegistrationNode SubRecord;
|
|
|
|
/// int32_t EncodedScopeTable;
|
|
|
|
/// int32_t TryLevel;
|
|
|
|
/// };
|
2015-05-30 06:57:46 +08:00
|
|
|
Type *WinEHStatePass::getSEHRegistrationType() {
|
|
|
|
if (SEHRegistrationTy)
|
|
|
|
return SEHRegistrationTy;
|
2015-05-06 01:44:16 +08:00
|
|
|
LLVMContext &Context = TheModule->getContext();
|
|
|
|
Type *FieldTys[] = {
|
|
|
|
Type::getInt8PtrTy(Context), // void *SavedESP
|
|
|
|
Type::getInt8PtrTy(Context), // void *ExceptionPointers
|
2015-05-30 06:57:46 +08:00
|
|
|
getEHLinkRegistrationType(), // EHRegistrationNode SubRecord
|
2015-05-06 01:44:16 +08:00
|
|
|
Type::getInt32Ty(Context), // int32_t EncodedScopeTable
|
|
|
|
Type::getInt32Ty(Context) // int32_t TryLevel
|
|
|
|
};
|
2015-05-30 06:57:46 +08:00
|
|
|
SEHRegistrationTy = StructType::create(FieldTys, "SEHExceptionRegistration");
|
|
|
|
return SEHRegistrationTy;
|
2015-05-06 01:44:16 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Emit an exception registration record. These are stack allocations with the
|
|
|
|
// common subobject of two pointers: the previous registration record (the old
|
|
|
|
// fs:00) and the personality function for the current frame. The data before
|
|
|
|
// and after that is personality function specific.
|
|
|
|
void WinEHStatePass::emitExceptionRegistrationRecord(Function *F) {
|
|
|
|
assert(Personality == EHPersonality::MSVC_CXX ||
|
|
|
|
Personality == EHPersonality::MSVC_X86SEH);
|
|
|
|
|
2016-02-01 12:28:59 +08:00
|
|
|
// Struct type of RegNode. Used for GEPing.
|
|
|
|
Type *RegNodeTy;
|
|
|
|
|
2015-05-06 01:44:16 +08:00
|
|
|
IRBuilder<> Builder(&F->getEntryBlock(), F->getEntryBlock().begin());
|
|
|
|
Type *Int8PtrType = Builder.getInt8PtrTy();
|
[StackProtector] Fix computation of GSCookieOffset and EHCookieOffset with SEH4
Summary:
Fix the computation of the offsets present in the scopetable when using the
SEH (__except_handler4).
This patch added an intrinsic to track the position of the allocation on the
stack of the EHGuard. This position is needed when producing the ScopeTable.
```
struct _EH4_SCOPETABLE {
DWORD GSCookieOffset;
DWORD GSCookieXOROffset;
DWORD EHCookieOffset;
DWORD EHCookieXOROffset;
_EH4_SCOPETABLE_RECORD ScopeRecord[1];
};
struct _EH4_SCOPETABLE_RECORD {
DWORD EnclosingLevel;
long (*FilterFunc)();
union {
void (*HandlerAddress)();
void (*FinallyFunc)();
};
};
```
The code to generate the EHCookie is added in `X86WinEHState.cpp`.
Which is adding these instructions when using SEH4.
```
Lfunc_begin0:
# BB#0: # %entry
pushl %ebp
movl %esp, %ebp
pushl %ebx
pushl %edi
pushl %esi
subl $28, %esp
movl %ebp, %eax <<-- Loading FramePtr
movl %esp, -36(%ebp)
movl $-2, -16(%ebp)
movl $L__ehtable$use_except_handler4_ssp, %ecx
xorl ___security_cookie, %ecx
movl %ecx, -20(%ebp)
xorl ___security_cookie, %eax <<-- XOR FramePtr and Cookie
movl %eax, -40(%ebp) <<-- Storing EHGuard
leal -28(%ebp), %eax
movl $__except_handler4, -24(%ebp)
movl %fs:0, %ecx
movl %ecx, -28(%ebp)
movl %eax, %fs:0
movl $0, -16(%ebp)
calll _may_throw_or_crash
LBB1_1: # %cont
movl -28(%ebp), %eax
movl %eax, %fs:0
addl $28, %esp
popl %esi
popl %edi
popl %ebx
popl %ebp
retl
```
And the corresponding offset is computed:
```
Luse_except_handler4_ssp$parent_frame_offset = -36
.p2align 2
L__ehtable$use_except_handler4_ssp:
.long -2 # GSCookieOffset
.long 0 # GSCookieXOROffset
.long -40 # EHCookieOffset <<----
.long 0 # EHCookieXOROffset
.long -2 # ToState
.long _catchall_filt # FilterFunction
.long LBB1_2 # ExceptionHandler
```
Clang is not yet producing function using SEH4, but it's a work in progress.
This patch is a step toward having a valid implementation of SEH4.
Unfortunately, it is not yet fully working. The EH registration block is not
allocated at the right offset on the stack.
Reviewers: rnk, majnemer
Subscribers: llvm-commits, chrisha
Differential Revision: http://reviews.llvm.org/D21231
llvm-svn: 273281
2016-06-21 23:58:55 +08:00
|
|
|
Type *Int32Ty = Builder.getInt32Ty();
|
|
|
|
Type *VoidTy = Builder.getVoidTy();
|
|
|
|
|
2015-05-30 06:57:46 +08:00
|
|
|
if (Personality == EHPersonality::MSVC_CXX) {
|
|
|
|
RegNodeTy = getCXXEHRegistrationType();
|
2015-05-29 06:00:24 +08:00
|
|
|
RegNode = Builder.CreateAlloca(RegNodeTy);
|
2015-05-06 01:44:16 +08:00
|
|
|
// SavedESP = llvm.stacksave()
|
|
|
|
Value *SP = Builder.CreateCall(
|
2015-05-19 06:13:54 +08:00
|
|
|
Intrinsic::getDeclaration(TheModule, Intrinsic::stacksave), {});
|
2015-05-06 01:44:16 +08:00
|
|
|
Builder.CreateStore(SP, Builder.CreateStructGEP(RegNodeTy, RegNode, 0));
|
|
|
|
// TryLevel = -1
|
2015-05-29 06:00:24 +08:00
|
|
|
StateFieldIndex = 2;
|
2016-02-18 02:37:11 +08:00
|
|
|
ParentBaseState = -1;
|
|
|
|
insertStateNumberStore(&*Builder.GetInsertPoint(), ParentBaseState);
|
2015-05-21 07:08:04 +08:00
|
|
|
// Handler = __ehhandler$F
|
|
|
|
Function *Trampoline = generateLSDAInEAXThunk(F);
|
2015-05-29 06:00:24 +08:00
|
|
|
Link = Builder.CreateStructGEP(RegNodeTy, RegNode, 1);
|
|
|
|
linkExceptionRegistration(Builder, Trampoline);
|
2016-03-01 03:16:03 +08:00
|
|
|
|
|
|
|
CxxLongjmpUnwind = TheModule->getOrInsertFunction(
|
|
|
|
"__CxxLongjmpUnwind",
|
[StackProtector] Fix computation of GSCookieOffset and EHCookieOffset with SEH4
Summary:
Fix the computation of the offsets present in the scopetable when using the
SEH (__except_handler4).
This patch added an intrinsic to track the position of the allocation on the
stack of the EHGuard. This position is needed when producing the ScopeTable.
```
struct _EH4_SCOPETABLE {
DWORD GSCookieOffset;
DWORD GSCookieXOROffset;
DWORD EHCookieOffset;
DWORD EHCookieXOROffset;
_EH4_SCOPETABLE_RECORD ScopeRecord[1];
};
struct _EH4_SCOPETABLE_RECORD {
DWORD EnclosingLevel;
long (*FilterFunc)();
union {
void (*HandlerAddress)();
void (*FinallyFunc)();
};
};
```
The code to generate the EHCookie is added in `X86WinEHState.cpp`.
Which is adding these instructions when using SEH4.
```
Lfunc_begin0:
# BB#0: # %entry
pushl %ebp
movl %esp, %ebp
pushl %ebx
pushl %edi
pushl %esi
subl $28, %esp
movl %ebp, %eax <<-- Loading FramePtr
movl %esp, -36(%ebp)
movl $-2, -16(%ebp)
movl $L__ehtable$use_except_handler4_ssp, %ecx
xorl ___security_cookie, %ecx
movl %ecx, -20(%ebp)
xorl ___security_cookie, %eax <<-- XOR FramePtr and Cookie
movl %eax, -40(%ebp) <<-- Storing EHGuard
leal -28(%ebp), %eax
movl $__except_handler4, -24(%ebp)
movl %fs:0, %ecx
movl %ecx, -28(%ebp)
movl %eax, %fs:0
movl $0, -16(%ebp)
calll _may_throw_or_crash
LBB1_1: # %cont
movl -28(%ebp), %eax
movl %eax, %fs:0
addl $28, %esp
popl %esi
popl %edi
popl %ebx
popl %ebp
retl
```
And the corresponding offset is computed:
```
Luse_except_handler4_ssp$parent_frame_offset = -36
.p2align 2
L__ehtable$use_except_handler4_ssp:
.long -2 # GSCookieOffset
.long 0 # GSCookieXOROffset
.long -40 # EHCookieOffset <<----
.long 0 # EHCookieXOROffset
.long -2 # ToState
.long _catchall_filt # FilterFunction
.long LBB1_2 # ExceptionHandler
```
Clang is not yet producing function using SEH4, but it's a work in progress.
This patch is a step toward having a valid implementation of SEH4.
Unfortunately, it is not yet fully working. The EH registration block is not
allocated at the right offset on the stack.
Reviewers: rnk, majnemer
Subscribers: llvm-commits, chrisha
Differential Revision: http://reviews.llvm.org/D21231
llvm-svn: 273281
2016-06-21 23:58:55 +08:00
|
|
|
FunctionType::get(VoidTy, Int8PtrType, /*isVarArg=*/false));
|
[opaque pointer types] Add a FunctionCallee wrapper type, and use it.
Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.
Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.
Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.
One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.
However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)
Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.
Differential Revision: https://reviews.llvm.org/D57315
llvm-svn: 352827
2019-02-01 10:28:03 +08:00
|
|
|
cast<Function>(CxxLongjmpUnwind.getCallee()->stripPointerCasts())
|
2016-03-01 03:16:03 +08:00
|
|
|
->setCallingConv(CallingConv::X86_StdCall);
|
2015-05-30 06:57:46 +08:00
|
|
|
} else if (Personality == EHPersonality::MSVC_X86SEH) {
|
|
|
|
// If _except_handler4 is in use, some additional guard checks and prologue
|
|
|
|
// stuff is required.
|
[StackProtector] Fix computation of GSCookieOffset and EHCookieOffset with SEH4
Summary:
Fix the computation of the offsets present in the scopetable when using the
SEH (__except_handler4).
This patch added an intrinsic to track the position of the allocation on the
stack of the EHGuard. This position is needed when producing the ScopeTable.
```
struct _EH4_SCOPETABLE {
DWORD GSCookieOffset;
DWORD GSCookieXOROffset;
DWORD EHCookieOffset;
DWORD EHCookieXOROffset;
_EH4_SCOPETABLE_RECORD ScopeRecord[1];
};
struct _EH4_SCOPETABLE_RECORD {
DWORD EnclosingLevel;
long (*FilterFunc)();
union {
void (*HandlerAddress)();
void (*FinallyFunc)();
};
};
```
The code to generate the EHCookie is added in `X86WinEHState.cpp`.
Which is adding these instructions when using SEH4.
```
Lfunc_begin0:
# BB#0: # %entry
pushl %ebp
movl %esp, %ebp
pushl %ebx
pushl %edi
pushl %esi
subl $28, %esp
movl %ebp, %eax <<-- Loading FramePtr
movl %esp, -36(%ebp)
movl $-2, -16(%ebp)
movl $L__ehtable$use_except_handler4_ssp, %ecx
xorl ___security_cookie, %ecx
movl %ecx, -20(%ebp)
xorl ___security_cookie, %eax <<-- XOR FramePtr and Cookie
movl %eax, -40(%ebp) <<-- Storing EHGuard
leal -28(%ebp), %eax
movl $__except_handler4, -24(%ebp)
movl %fs:0, %ecx
movl %ecx, -28(%ebp)
movl %eax, %fs:0
movl $0, -16(%ebp)
calll _may_throw_or_crash
LBB1_1: # %cont
movl -28(%ebp), %eax
movl %eax, %fs:0
addl $28, %esp
popl %esi
popl %edi
popl %ebx
popl %ebp
retl
```
And the corresponding offset is computed:
```
Luse_except_handler4_ssp$parent_frame_offset = -36
.p2align 2
L__ehtable$use_except_handler4_ssp:
.long -2 # GSCookieOffset
.long 0 # GSCookieXOROffset
.long -40 # EHCookieOffset <<----
.long 0 # EHCookieXOROffset
.long -2 # ToState
.long _catchall_filt # FilterFunction
.long LBB1_2 # ExceptionHandler
```
Clang is not yet producing function using SEH4, but it's a work in progress.
This patch is a step toward having a valid implementation of SEH4.
Unfortunately, it is not yet fully working. The EH registration block is not
allocated at the right offset on the stack.
Reviewers: rnk, majnemer
Subscribers: llvm-commits, chrisha
Differential Revision: http://reviews.llvm.org/D21231
llvm-svn: 273281
2016-06-21 23:58:55 +08:00
|
|
|
StringRef PersonalityName = PersonalityFn->getName();
|
|
|
|
UseStackGuard = (PersonalityName == "_except_handler4");
|
|
|
|
|
|
|
|
// Allocate local structures.
|
2015-05-30 06:57:46 +08:00
|
|
|
RegNodeTy = getSEHRegistrationType();
|
2015-05-29 06:00:24 +08:00
|
|
|
RegNode = Builder.CreateAlloca(RegNodeTy);
|
[StackProtector] Fix computation of GSCookieOffset and EHCookieOffset with SEH4
Summary:
Fix the computation of the offsets present in the scopetable when using the
SEH (__except_handler4).
This patch added an intrinsic to track the position of the allocation on the
stack of the EHGuard. This position is needed when producing the ScopeTable.
```
struct _EH4_SCOPETABLE {
DWORD GSCookieOffset;
DWORD GSCookieXOROffset;
DWORD EHCookieOffset;
DWORD EHCookieXOROffset;
_EH4_SCOPETABLE_RECORD ScopeRecord[1];
};
struct _EH4_SCOPETABLE_RECORD {
DWORD EnclosingLevel;
long (*FilterFunc)();
union {
void (*HandlerAddress)();
void (*FinallyFunc)();
};
};
```
The code to generate the EHCookie is added in `X86WinEHState.cpp`.
Which is adding these instructions when using SEH4.
```
Lfunc_begin0:
# BB#0: # %entry
pushl %ebp
movl %esp, %ebp
pushl %ebx
pushl %edi
pushl %esi
subl $28, %esp
movl %ebp, %eax <<-- Loading FramePtr
movl %esp, -36(%ebp)
movl $-2, -16(%ebp)
movl $L__ehtable$use_except_handler4_ssp, %ecx
xorl ___security_cookie, %ecx
movl %ecx, -20(%ebp)
xorl ___security_cookie, %eax <<-- XOR FramePtr and Cookie
movl %eax, -40(%ebp) <<-- Storing EHGuard
leal -28(%ebp), %eax
movl $__except_handler4, -24(%ebp)
movl %fs:0, %ecx
movl %ecx, -28(%ebp)
movl %eax, %fs:0
movl $0, -16(%ebp)
calll _may_throw_or_crash
LBB1_1: # %cont
movl -28(%ebp), %eax
movl %eax, %fs:0
addl $28, %esp
popl %esi
popl %edi
popl %ebx
popl %ebp
retl
```
And the corresponding offset is computed:
```
Luse_except_handler4_ssp$parent_frame_offset = -36
.p2align 2
L__ehtable$use_except_handler4_ssp:
.long -2 # GSCookieOffset
.long 0 # GSCookieXOROffset
.long -40 # EHCookieOffset <<----
.long 0 # EHCookieXOROffset
.long -2 # ToState
.long _catchall_filt # FilterFunction
.long LBB1_2 # ExceptionHandler
```
Clang is not yet producing function using SEH4, but it's a work in progress.
This patch is a step toward having a valid implementation of SEH4.
Unfortunately, it is not yet fully working. The EH registration block is not
allocated at the right offset on the stack.
Reviewers: rnk, majnemer
Subscribers: llvm-commits, chrisha
Differential Revision: http://reviews.llvm.org/D21231
llvm-svn: 273281
2016-06-21 23:58:55 +08:00
|
|
|
if (UseStackGuard)
|
|
|
|
EHGuardNode = Builder.CreateAlloca(Int32Ty);
|
|
|
|
|
2015-05-06 01:44:16 +08:00
|
|
|
// SavedESP = llvm.stacksave()
|
|
|
|
Value *SP = Builder.CreateCall(
|
2015-05-19 06:13:54 +08:00
|
|
|
Intrinsic::getDeclaration(TheModule, Intrinsic::stacksave), {});
|
2015-05-06 01:44:16 +08:00
|
|
|
Builder.CreateStore(SP, Builder.CreateStructGEP(RegNodeTy, RegNode, 0));
|
2015-05-30 06:57:46 +08:00
|
|
|
// TryLevel = -2 / -1
|
2015-05-29 06:00:24 +08:00
|
|
|
StateFieldIndex = 4;
|
2016-02-18 02:37:11 +08:00
|
|
|
ParentBaseState = UseStackGuard ? -2 : -1;
|
|
|
|
insertStateNumberStore(&*Builder.GetInsertPoint(), ParentBaseState);
|
2015-05-21 07:08:04 +08:00
|
|
|
// ScopeTable = llvm.x86.seh.lsda(F)
|
2016-03-01 03:16:03 +08:00
|
|
|
Value *LSDA = emitEHLSDA(Builder, F);
|
2015-05-30 06:57:46 +08:00
|
|
|
LSDA = Builder.CreatePtrToInt(LSDA, Int32Ty);
|
|
|
|
// If using _except_handler4, xor the address of the table with
|
|
|
|
// __security_cookie.
|
|
|
|
if (UseStackGuard) {
|
2016-03-01 03:16:03 +08:00
|
|
|
Cookie = TheModule->getOrInsertGlobal("__security_cookie", Int32Ty);
|
[StackProtector] Fix computation of GSCookieOffset and EHCookieOffset with SEH4
Summary:
Fix the computation of the offsets present in the scopetable when using the
SEH (__except_handler4).
This patch added an intrinsic to track the position of the allocation on the
stack of the EHGuard. This position is needed when producing the ScopeTable.
```
struct _EH4_SCOPETABLE {
DWORD GSCookieOffset;
DWORD GSCookieXOROffset;
DWORD EHCookieOffset;
DWORD EHCookieXOROffset;
_EH4_SCOPETABLE_RECORD ScopeRecord[1];
};
struct _EH4_SCOPETABLE_RECORD {
DWORD EnclosingLevel;
long (*FilterFunc)();
union {
void (*HandlerAddress)();
void (*FinallyFunc)();
};
};
```
The code to generate the EHCookie is added in `X86WinEHState.cpp`.
Which is adding these instructions when using SEH4.
```
Lfunc_begin0:
# BB#0: # %entry
pushl %ebp
movl %esp, %ebp
pushl %ebx
pushl %edi
pushl %esi
subl $28, %esp
movl %ebp, %eax <<-- Loading FramePtr
movl %esp, -36(%ebp)
movl $-2, -16(%ebp)
movl $L__ehtable$use_except_handler4_ssp, %ecx
xorl ___security_cookie, %ecx
movl %ecx, -20(%ebp)
xorl ___security_cookie, %eax <<-- XOR FramePtr and Cookie
movl %eax, -40(%ebp) <<-- Storing EHGuard
leal -28(%ebp), %eax
movl $__except_handler4, -24(%ebp)
movl %fs:0, %ecx
movl %ecx, -28(%ebp)
movl %eax, %fs:0
movl $0, -16(%ebp)
calll _may_throw_or_crash
LBB1_1: # %cont
movl -28(%ebp), %eax
movl %eax, %fs:0
addl $28, %esp
popl %esi
popl %edi
popl %ebx
popl %ebp
retl
```
And the corresponding offset is computed:
```
Luse_except_handler4_ssp$parent_frame_offset = -36
.p2align 2
L__ehtable$use_except_handler4_ssp:
.long -2 # GSCookieOffset
.long 0 # GSCookieXOROffset
.long -40 # EHCookieOffset <<----
.long 0 # EHCookieXOROffset
.long -2 # ToState
.long _catchall_filt # FilterFunction
.long LBB1_2 # ExceptionHandler
```
Clang is not yet producing function using SEH4, but it's a work in progress.
This patch is a step toward having a valid implementation of SEH4.
Unfortunately, it is not yet fully working. The EH registration block is not
allocated at the right offset on the stack.
Reviewers: rnk, majnemer
Subscribers: llvm-commits, chrisha
Differential Revision: http://reviews.llvm.org/D21231
llvm-svn: 273281
2016-06-21 23:58:55 +08:00
|
|
|
Value *Val = Builder.CreateLoad(Int32Ty, Cookie, "cookie");
|
2015-05-30 06:57:46 +08:00
|
|
|
LSDA = Builder.CreateXor(LSDA, Val);
|
|
|
|
}
|
|
|
|
Builder.CreateStore(LSDA, Builder.CreateStructGEP(RegNodeTy, RegNode, 3));
|
[StackProtector] Fix computation of GSCookieOffset and EHCookieOffset with SEH4
Summary:
Fix the computation of the offsets present in the scopetable when using the
SEH (__except_handler4).
This patch added an intrinsic to track the position of the allocation on the
stack of the EHGuard. This position is needed when producing the ScopeTable.
```
struct _EH4_SCOPETABLE {
DWORD GSCookieOffset;
DWORD GSCookieXOROffset;
DWORD EHCookieOffset;
DWORD EHCookieXOROffset;
_EH4_SCOPETABLE_RECORD ScopeRecord[1];
};
struct _EH4_SCOPETABLE_RECORD {
DWORD EnclosingLevel;
long (*FilterFunc)();
union {
void (*HandlerAddress)();
void (*FinallyFunc)();
};
};
```
The code to generate the EHCookie is added in `X86WinEHState.cpp`.
Which is adding these instructions when using SEH4.
```
Lfunc_begin0:
# BB#0: # %entry
pushl %ebp
movl %esp, %ebp
pushl %ebx
pushl %edi
pushl %esi
subl $28, %esp
movl %ebp, %eax <<-- Loading FramePtr
movl %esp, -36(%ebp)
movl $-2, -16(%ebp)
movl $L__ehtable$use_except_handler4_ssp, %ecx
xorl ___security_cookie, %ecx
movl %ecx, -20(%ebp)
xorl ___security_cookie, %eax <<-- XOR FramePtr and Cookie
movl %eax, -40(%ebp) <<-- Storing EHGuard
leal -28(%ebp), %eax
movl $__except_handler4, -24(%ebp)
movl %fs:0, %ecx
movl %ecx, -28(%ebp)
movl %eax, %fs:0
movl $0, -16(%ebp)
calll _may_throw_or_crash
LBB1_1: # %cont
movl -28(%ebp), %eax
movl %eax, %fs:0
addl $28, %esp
popl %esi
popl %edi
popl %ebx
popl %ebp
retl
```
And the corresponding offset is computed:
```
Luse_except_handler4_ssp$parent_frame_offset = -36
.p2align 2
L__ehtable$use_except_handler4_ssp:
.long -2 # GSCookieOffset
.long 0 # GSCookieXOROffset
.long -40 # EHCookieOffset <<----
.long 0 # EHCookieXOROffset
.long -2 # ToState
.long _catchall_filt # FilterFunction
.long LBB1_2 # ExceptionHandler
```
Clang is not yet producing function using SEH4, but it's a work in progress.
This patch is a step toward having a valid implementation of SEH4.
Unfortunately, it is not yet fully working. The EH registration block is not
allocated at the right offset on the stack.
Reviewers: rnk, majnemer
Subscribers: llvm-commits, chrisha
Differential Revision: http://reviews.llvm.org/D21231
llvm-svn: 273281
2016-06-21 23:58:55 +08:00
|
|
|
|
|
|
|
// If using _except_handler4, the EHGuard contains: FramePtr xor Cookie.
|
|
|
|
if (UseStackGuard) {
|
|
|
|
Value *Val = Builder.CreateLoad(Int32Ty, Cookie);
|
|
|
|
Value *FrameAddr = Builder.CreateCall(
|
2019-07-22 20:42:48 +08:00
|
|
|
Intrinsic::getDeclaration(
|
|
|
|
TheModule, Intrinsic::frameaddress,
|
|
|
|
Builder.getInt8PtrTy(
|
|
|
|
TheModule->getDataLayout().getAllocaAddrSpace())),
|
[StackProtector] Fix computation of GSCookieOffset and EHCookieOffset with SEH4
Summary:
Fix the computation of the offsets present in the scopetable when using the
SEH (__except_handler4).
This patch added an intrinsic to track the position of the allocation on the
stack of the EHGuard. This position is needed when producing the ScopeTable.
```
struct _EH4_SCOPETABLE {
DWORD GSCookieOffset;
DWORD GSCookieXOROffset;
DWORD EHCookieOffset;
DWORD EHCookieXOROffset;
_EH4_SCOPETABLE_RECORD ScopeRecord[1];
};
struct _EH4_SCOPETABLE_RECORD {
DWORD EnclosingLevel;
long (*FilterFunc)();
union {
void (*HandlerAddress)();
void (*FinallyFunc)();
};
};
```
The code to generate the EHCookie is added in `X86WinEHState.cpp`.
Which is adding these instructions when using SEH4.
```
Lfunc_begin0:
# BB#0: # %entry
pushl %ebp
movl %esp, %ebp
pushl %ebx
pushl %edi
pushl %esi
subl $28, %esp
movl %ebp, %eax <<-- Loading FramePtr
movl %esp, -36(%ebp)
movl $-2, -16(%ebp)
movl $L__ehtable$use_except_handler4_ssp, %ecx
xorl ___security_cookie, %ecx
movl %ecx, -20(%ebp)
xorl ___security_cookie, %eax <<-- XOR FramePtr and Cookie
movl %eax, -40(%ebp) <<-- Storing EHGuard
leal -28(%ebp), %eax
movl $__except_handler4, -24(%ebp)
movl %fs:0, %ecx
movl %ecx, -28(%ebp)
movl %eax, %fs:0
movl $0, -16(%ebp)
calll _may_throw_or_crash
LBB1_1: # %cont
movl -28(%ebp), %eax
movl %eax, %fs:0
addl $28, %esp
popl %esi
popl %edi
popl %ebx
popl %ebp
retl
```
And the corresponding offset is computed:
```
Luse_except_handler4_ssp$parent_frame_offset = -36
.p2align 2
L__ehtable$use_except_handler4_ssp:
.long -2 # GSCookieOffset
.long 0 # GSCookieXOROffset
.long -40 # EHCookieOffset <<----
.long 0 # EHCookieXOROffset
.long -2 # ToState
.long _catchall_filt # FilterFunction
.long LBB1_2 # ExceptionHandler
```
Clang is not yet producing function using SEH4, but it's a work in progress.
This patch is a step toward having a valid implementation of SEH4.
Unfortunately, it is not yet fully working. The EH registration block is not
allocated at the right offset on the stack.
Reviewers: rnk, majnemer
Subscribers: llvm-commits, chrisha
Differential Revision: http://reviews.llvm.org/D21231
llvm-svn: 273281
2016-06-21 23:58:55 +08:00
|
|
|
Builder.getInt32(0), "frameaddr");
|
|
|
|
Value *FrameAddrI32 = Builder.CreatePtrToInt(FrameAddr, Int32Ty);
|
|
|
|
FrameAddrI32 = Builder.CreateXor(FrameAddrI32, Val);
|
|
|
|
Builder.CreateStore(FrameAddrI32, EHGuardNode);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Register the exception handler.
|
2015-05-29 06:00:24 +08:00
|
|
|
Link = Builder.CreateStructGEP(RegNodeTy, RegNode, 2);
|
|
|
|
linkExceptionRegistration(Builder, PersonalityFn);
|
2016-03-01 03:16:03 +08:00
|
|
|
|
|
|
|
SehLongjmpUnwind = TheModule->getOrInsertFunction(
|
|
|
|
UseStackGuard ? "_seh_longjmp_unwind4" : "_seh_longjmp_unwind",
|
|
|
|
FunctionType::get(Type::getVoidTy(TheModule->getContext()), Int8PtrType,
|
|
|
|
/*isVarArg=*/false));
|
[opaque pointer types] Add a FunctionCallee wrapper type, and use it.
Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.
Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.
Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.
One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.
However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)
Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.
Differential Revision: https://reviews.llvm.org/D57315
llvm-svn: 352827
2019-02-01 10:28:03 +08:00
|
|
|
cast<Function>(SehLongjmpUnwind.getCallee()->stripPointerCasts())
|
2016-03-01 03:16:03 +08:00
|
|
|
->setCallingConv(CallingConv::X86_StdCall);
|
2015-05-06 01:44:16 +08:00
|
|
|
} else {
|
|
|
|
llvm_unreachable("unexpected personality function");
|
|
|
|
}
|
|
|
|
|
2015-05-29 06:00:24 +08:00
|
|
|
// Insert an unlink before all returns.
|
2015-05-06 01:44:16 +08:00
|
|
|
for (BasicBlock &BB : *F) {
|
2018-10-15 18:04:59 +08:00
|
|
|
Instruction *T = BB.getTerminator();
|
2015-05-06 01:44:16 +08:00
|
|
|
if (!isa<ReturnInst>(T))
|
|
|
|
continue;
|
|
|
|
Builder.SetInsertPoint(T);
|
2015-05-29 06:00:24 +08:00
|
|
|
unlinkExceptionRegistration(Builder);
|
2015-05-06 01:44:16 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-05-21 07:08:04 +08:00
|
|
|
Value *WinEHStatePass::emitEHLSDA(IRBuilder<> &Builder, Function *F) {
|
|
|
|
Value *FI8 = Builder.CreateBitCast(F, Type::getInt8PtrTy(F->getContext()));
|
|
|
|
return Builder.CreateCall(
|
|
|
|
Intrinsic::getDeclaration(TheModule, Intrinsic::x86_seh_lsda), FI8);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Generate a thunk that puts the LSDA of ParentFunc in EAX and then calls
|
|
|
|
/// PersonalityFn, forwarding the parameters passed to PEXCEPTION_ROUTINE:
|
|
|
|
/// typedef _EXCEPTION_DISPOSITION (*PEXCEPTION_ROUTINE)(
|
|
|
|
/// _EXCEPTION_RECORD *, void *, _CONTEXT *, void *);
|
|
|
|
/// We essentially want this code:
|
|
|
|
/// movl $lsda, %eax
|
|
|
|
/// jmpl ___CxxFrameHandler3
|
|
|
|
Function *WinEHStatePass::generateLSDAInEAXThunk(Function *ParentFunc) {
|
|
|
|
LLVMContext &Context = ParentFunc->getContext();
|
|
|
|
Type *Int32Ty = Type::getInt32Ty(Context);
|
|
|
|
Type *Int8PtrType = Type::getInt8PtrTy(Context);
|
|
|
|
Type *ArgTys[5] = {Int8PtrType, Int8PtrType, Int8PtrType, Int8PtrType,
|
|
|
|
Int8PtrType};
|
|
|
|
FunctionType *TrampolineTy =
|
|
|
|
FunctionType::get(Int32Ty, makeArrayRef(&ArgTys[0], 4),
|
|
|
|
/*isVarArg=*/false);
|
|
|
|
FunctionType *TargetFuncTy =
|
|
|
|
FunctionType::get(Int32Ty, makeArrayRef(&ArgTys[0], 5),
|
|
|
|
/*isVarArg=*/false);
|
2015-07-14 01:55:14 +08:00
|
|
|
Function *Trampoline =
|
|
|
|
Function::Create(TrampolineTy, GlobalValue::InternalLinkage,
|
2017-05-16 08:39:01 +08:00
|
|
|
Twine("__ehhandler$") + GlobalValue::dropLLVMManglingEscape(
|
2015-07-14 01:55:14 +08:00
|
|
|
ParentFunc->getName()),
|
|
|
|
TheModule);
|
Make x86 __ehhandler comdat if parent function is
Summary:
This change comes from using lld for i686-windows-msvc. Before this change, lld
emits an error of:
error: relocation against symbol in discarded section: .xdata
It's possible that this could be addressed in lld, but I think this change is
reasonable on its own.
At a high level, this is being generated:
A (.text comdat) -> B (.text) -> C (.xdata comdat)
Where A is a C++ inline function, which references B, an exception handler
thunk, which references C, the exception handling info.
With this structure, lld will error when applying relocations to B if the C it
references has been discarded (some other C has been selected).
This change checks if A is comdat, and if so places the exception registration
thunk (B) in the comdata group of A (and B).
It appears that MSVC makes the __ehhandler function comdat.
Is it possible that duplicate thunks are being emitted into the final binary
with other linkers, or are they stripping the unused thunks?
Reviewers: rnk, majnemer, compnerd, smeenai
Reviewed By: rnk, compnerd
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38940
llvm-svn: 316219
2017-10-21 01:04:43 +08:00
|
|
|
if (auto *C = ParentFunc->getComdat())
|
|
|
|
Trampoline->setComdat(C);
|
2015-05-21 07:08:04 +08:00
|
|
|
BasicBlock *EntryBB = BasicBlock::Create(Context, "entry", Trampoline);
|
|
|
|
IRBuilder<> Builder(EntryBB);
|
|
|
|
Value *LSDA = emitEHLSDA(Builder, ParentFunc);
|
|
|
|
Value *CastPersonality =
|
|
|
|
Builder.CreateBitCast(PersonalityFn, TargetFuncTy->getPointerTo());
|
|
|
|
auto AI = Trampoline->arg_begin();
|
2015-10-20 05:48:29 +08:00
|
|
|
Value *Args[5] = {LSDA, &*AI++, &*AI++, &*AI++, &*AI++};
|
2019-02-02 04:43:25 +08:00
|
|
|
CallInst *Call = Builder.CreateCall(TargetFuncTy, CastPersonality, Args);
|
2015-05-21 07:08:04 +08:00
|
|
|
// Can't use musttail due to prototype mismatch, but we can use tail.
|
|
|
|
Call->setTailCall(true);
|
|
|
|
// Set inreg so we pass it in EAX.
|
2017-05-04 02:17:31 +08:00
|
|
|
Call->addParamAttr(0, Attribute::InReg);
|
2015-05-21 07:08:04 +08:00
|
|
|
Builder.CreateRet(Call);
|
|
|
|
return Trampoline;
|
|
|
|
}
|
|
|
|
|
2015-05-06 01:44:16 +08:00
|
|
|
void WinEHStatePass::linkExceptionRegistration(IRBuilder<> &Builder,
|
2015-06-10 09:02:30 +08:00
|
|
|
Function *Handler) {
|
|
|
|
// Emit the .safeseh directive for this function.
|
|
|
|
Handler->addFnAttr("safeseh");
|
|
|
|
|
2015-05-30 06:57:46 +08:00
|
|
|
Type *LinkTy = getEHLinkRegistrationType();
|
2015-05-06 01:44:16 +08:00
|
|
|
// Handler = Handler
|
2015-06-10 09:02:30 +08:00
|
|
|
Value *HandlerI8 = Builder.CreateBitCast(Handler, Builder.getInt8PtrTy());
|
|
|
|
Builder.CreateStore(HandlerI8, Builder.CreateStructGEP(LinkTy, Link, 1));
|
2015-05-06 01:44:16 +08:00
|
|
|
// Next = [fs:00]
|
|
|
|
Constant *FSZero =
|
2015-05-29 06:00:24 +08:00
|
|
|
Constant::getNullValue(LinkTy->getPointerTo()->getPointerTo(257));
|
2019-02-02 04:44:24 +08:00
|
|
|
Value *Next = Builder.CreateLoad(LinkTy->getPointerTo(), FSZero);
|
2015-05-29 06:00:24 +08:00
|
|
|
Builder.CreateStore(Next, Builder.CreateStructGEP(LinkTy, Link, 0));
|
|
|
|
// [fs:00] = Link
|
|
|
|
Builder.CreateStore(Link, FSZero);
|
2015-05-06 01:44:16 +08:00
|
|
|
}
|
|
|
|
|
2015-05-29 06:00:24 +08:00
|
|
|
void WinEHStatePass::unlinkExceptionRegistration(IRBuilder<> &Builder) {
|
|
|
|
// Clone Link into the current BB for better address mode folding.
|
|
|
|
if (auto *GEP = dyn_cast<GetElementPtrInst>(Link)) {
|
2015-05-06 01:44:16 +08:00
|
|
|
GEP = cast<GetElementPtrInst>(GEP->clone());
|
|
|
|
Builder.Insert(GEP);
|
2015-05-29 06:00:24 +08:00
|
|
|
Link = GEP;
|
2015-05-06 01:44:16 +08:00
|
|
|
}
|
2015-05-30 06:57:46 +08:00
|
|
|
Type *LinkTy = getEHLinkRegistrationType();
|
2015-05-29 06:00:24 +08:00
|
|
|
// [fs:00] = Link->Next
|
2019-02-02 04:44:24 +08:00
|
|
|
Value *Next = Builder.CreateLoad(LinkTy->getPointerTo(),
|
|
|
|
Builder.CreateStructGEP(LinkTy, Link, 0));
|
2015-05-06 01:44:16 +08:00
|
|
|
Constant *FSZero =
|
2015-05-29 06:00:24 +08:00
|
|
|
Constant::getNullValue(LinkTy->getPointerTo()->getPointerTo(257));
|
2015-05-06 01:44:16 +08:00
|
|
|
Builder.CreateStore(Next, FSZero);
|
|
|
|
}
|
2015-05-29 06:00:24 +08:00
|
|
|
|
2016-03-01 03:16:03 +08:00
|
|
|
// Calls to setjmp(p) are lowered to _setjmp3(p, 0) by the frontend.
|
|
|
|
// The idea behind _setjmp3 is that it takes an optional number of personality
|
|
|
|
// specific parameters to indicate how to restore the personality-specific frame
|
|
|
|
// state when longjmp is initiated. Typically, the current TryLevel is saved.
|
|
|
|
void WinEHStatePass::rewriteSetJmpCallSite(IRBuilder<> &Builder, Function &F,
|
|
|
|
CallSite CS, Value *State) {
|
|
|
|
// Don't rewrite calls with a weird number of arguments.
|
|
|
|
if (CS.getNumArgOperands() != 2)
|
|
|
|
return;
|
|
|
|
|
|
|
|
Instruction *Inst = CS.getInstruction();
|
|
|
|
|
|
|
|
SmallVector<OperandBundleDef, 1> OpBundles;
|
|
|
|
CS.getOperandBundlesAsDefs(OpBundles);
|
|
|
|
|
|
|
|
SmallVector<Value *, 3> OptionalArgs;
|
|
|
|
if (Personality == EHPersonality::MSVC_CXX) {
|
[opaque pointer types] Add a FunctionCallee wrapper type, and use it.
Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.
Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.
Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.
One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.
However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)
Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.
Differential Revision: https://reviews.llvm.org/D57315
llvm-svn: 352827
2019-02-01 10:28:03 +08:00
|
|
|
OptionalArgs.push_back(CxxLongjmpUnwind.getCallee());
|
2016-03-01 03:16:03 +08:00
|
|
|
OptionalArgs.push_back(State);
|
|
|
|
OptionalArgs.push_back(emitEHLSDA(Builder, &F));
|
|
|
|
} else if (Personality == EHPersonality::MSVC_X86SEH) {
|
[opaque pointer types] Add a FunctionCallee wrapper type, and use it.
Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.
Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.
Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.
One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.
However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)
Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.
Differential Revision: https://reviews.llvm.org/D57315
llvm-svn: 352827
2019-02-01 10:28:03 +08:00
|
|
|
OptionalArgs.push_back(SehLongjmpUnwind.getCallee());
|
2016-03-01 03:16:03 +08:00
|
|
|
OptionalArgs.push_back(State);
|
|
|
|
if (UseStackGuard)
|
|
|
|
OptionalArgs.push_back(Cookie);
|
|
|
|
} else {
|
|
|
|
llvm_unreachable("unhandled personality!");
|
|
|
|
}
|
|
|
|
|
|
|
|
SmallVector<Value *, 5> Args;
|
|
|
|
Args.push_back(
|
|
|
|
Builder.CreateBitCast(CS.getArgOperand(0), Builder.getInt8PtrTy()));
|
|
|
|
Args.push_back(Builder.getInt32(OptionalArgs.size()));
|
|
|
|
Args.append(OptionalArgs.begin(), OptionalArgs.end());
|
|
|
|
|
|
|
|
CallSite NewCS;
|
|
|
|
if (CS.isCall()) {
|
|
|
|
auto *CI = cast<CallInst>(Inst);
|
|
|
|
CallInst *NewCI = Builder.CreateCall(SetJmp3, Args, OpBundles);
|
|
|
|
NewCI->setTailCallKind(CI->getTailCallKind());
|
|
|
|
NewCS = NewCI;
|
|
|
|
} else {
|
|
|
|
auto *II = cast<InvokeInst>(Inst);
|
|
|
|
NewCS = Builder.CreateInvoke(
|
|
|
|
SetJmp3, II->getNormalDest(), II->getUnwindDest(), Args, OpBundles);
|
|
|
|
}
|
|
|
|
NewCS.setCallingConv(CS.getCallingConv());
|
|
|
|
NewCS.setAttributes(CS.getAttributes());
|
|
|
|
NewCS->setDebugLoc(CS->getDebugLoc());
|
|
|
|
|
|
|
|
Instruction *NewInst = NewCS.getInstruction();
|
|
|
|
NewInst->takeName(Inst);
|
|
|
|
Inst->replaceAllUsesWith(NewInst);
|
|
|
|
Inst->eraseFromParent();
|
|
|
|
}
|
|
|
|
|
2016-02-18 02:37:11 +08:00
|
|
|
// Figure out what state we should assign calls in this block.
|
2016-03-01 03:16:03 +08:00
|
|
|
int WinEHStatePass::getBaseStateForBB(
|
|
|
|
DenseMap<BasicBlock *, ColorVector> &BlockColors, WinEHFuncInfo &FuncInfo,
|
|
|
|
BasicBlock *BB) {
|
|
|
|
int BaseState = ParentBaseState;
|
2016-02-18 02:37:11 +08:00
|
|
|
auto &BBColors = BlockColors[BB];
|
|
|
|
|
|
|
|
assert(BBColors.size() == 1 && "multi-color BB not removed by preparation");
|
|
|
|
BasicBlock *FuncletEntryBB = BBColors.front();
|
|
|
|
if (auto *FuncletPad =
|
|
|
|
dyn_cast<FuncletPadInst>(FuncletEntryBB->getFirstNonPHI())) {
|
|
|
|
auto BaseStateI = FuncInfo.FuncletBaseStateMap.find(FuncletPad);
|
|
|
|
if (BaseStateI != FuncInfo.FuncletBaseStateMap.end())
|
|
|
|
BaseState = BaseStateI->second;
|
|
|
|
}
|
|
|
|
|
|
|
|
return BaseState;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Calculate the state a call-site is in.
|
2016-03-01 03:16:03 +08:00
|
|
|
int WinEHStatePass::getStateForCallSite(
|
|
|
|
DenseMap<BasicBlock *, ColorVector> &BlockColors, WinEHFuncInfo &FuncInfo,
|
|
|
|
CallSite CS) {
|
2016-02-18 02:37:11 +08:00
|
|
|
if (auto *II = dyn_cast<InvokeInst>(CS.getInstruction())) {
|
|
|
|
// Look up the state number of the EH pad this unwinds to.
|
|
|
|
assert(FuncInfo.InvokeStateMap.count(II) && "invoke has no state!");
|
|
|
|
return FuncInfo.InvokeStateMap[II];
|
|
|
|
}
|
|
|
|
// Possibly throwing call instructions have no actions to take after
|
|
|
|
// an unwind. Ensure they are in the -1 state.
|
|
|
|
return getBaseStateForBB(BlockColors, FuncInfo, CS.getParent());
|
|
|
|
}
|
|
|
|
|
|
|
|
// Calculate the intersection of all the FinalStates for a BasicBlock's
|
2016-02-19 05:13:35 +08:00
|
|
|
// predecessors.
|
2016-02-18 02:37:11 +08:00
|
|
|
static int getPredState(DenseMap<BasicBlock *, int> &FinalStates, Function &F,
|
|
|
|
int ParentBaseState, BasicBlock *BB) {
|
|
|
|
// The entry block has no predecessors but we know that the prologue always
|
|
|
|
// sets us up with a fixed state.
|
|
|
|
if (&F.getEntryBlock() == BB)
|
|
|
|
return ParentBaseState;
|
|
|
|
|
|
|
|
// This is an EH Pad, conservatively report this basic block as overdefined.
|
|
|
|
if (BB->isEHPad())
|
|
|
|
return OverdefinedState;
|
|
|
|
|
|
|
|
int CommonState = OverdefinedState;
|
|
|
|
for (BasicBlock *PredBB : predecessors(BB)) {
|
|
|
|
// We didn't manage to get a state for one of these predecessors,
|
|
|
|
// conservatively report this basic block as overdefined.
|
|
|
|
auto PredEndState = FinalStates.find(PredBB);
|
|
|
|
if (PredEndState == FinalStates.end())
|
|
|
|
return OverdefinedState;
|
|
|
|
|
|
|
|
// This code is reachable via exceptional control flow,
|
|
|
|
// conservatively report this basic block as overdefined.
|
|
|
|
if (isa<CatchReturnInst>(PredBB->getTerminator()))
|
|
|
|
return OverdefinedState;
|
|
|
|
|
|
|
|
int PredState = PredEndState->second;
|
|
|
|
assert(PredState != OverdefinedState &&
|
|
|
|
"overdefined BBs shouldn't be in FinalStates");
|
|
|
|
if (CommonState == OverdefinedState)
|
|
|
|
CommonState = PredState;
|
|
|
|
|
|
|
|
// At least two predecessors have different FinalStates,
|
|
|
|
// conservatively report this basic block as overdefined.
|
|
|
|
if (CommonState != PredState)
|
|
|
|
return OverdefinedState;
|
|
|
|
}
|
|
|
|
|
|
|
|
return CommonState;
|
2016-02-18 02:48:08 +08:00
|
|
|
}
|
2016-02-18 02:37:11 +08:00
|
|
|
|
2016-02-19 05:13:35 +08:00
|
|
|
// Calculate the intersection of all the InitialStates for a BasicBlock's
|
|
|
|
// successors.
|
|
|
|
static int getSuccState(DenseMap<BasicBlock *, int> &InitialStates, Function &F,
|
|
|
|
int ParentBaseState, BasicBlock *BB) {
|
|
|
|
// This block rejoins normal control flow,
|
|
|
|
// conservatively report this basic block as overdefined.
|
|
|
|
if (isa<CatchReturnInst>(BB->getTerminator()))
|
|
|
|
return OverdefinedState;
|
|
|
|
|
|
|
|
int CommonState = OverdefinedState;
|
|
|
|
for (BasicBlock *SuccBB : successors(BB)) {
|
|
|
|
// We didn't manage to get a state for one of these predecessors,
|
|
|
|
// conservatively report this basic block as overdefined.
|
|
|
|
auto SuccStartState = InitialStates.find(SuccBB);
|
|
|
|
if (SuccStartState == InitialStates.end())
|
|
|
|
return OverdefinedState;
|
|
|
|
|
|
|
|
// This is an EH Pad, conservatively report this basic block as overdefined.
|
|
|
|
if (SuccBB->isEHPad())
|
|
|
|
return OverdefinedState;
|
|
|
|
|
|
|
|
int SuccState = SuccStartState->second;
|
|
|
|
assert(SuccState != OverdefinedState &&
|
|
|
|
"overdefined BBs shouldn't be in FinalStates");
|
|
|
|
if (CommonState == OverdefinedState)
|
|
|
|
CommonState = SuccState;
|
|
|
|
|
|
|
|
// At least two successors have different InitialStates,
|
|
|
|
// conservatively report this basic block as overdefined.
|
|
|
|
if (CommonState != SuccState)
|
|
|
|
return OverdefinedState;
|
|
|
|
}
|
|
|
|
|
|
|
|
return CommonState;
|
|
|
|
}
|
|
|
|
|
2016-03-01 03:16:03 +08:00
|
|
|
bool WinEHStatePass::isStateStoreNeeded(EHPersonality Personality,
|
|
|
|
CallSite CS) {
|
2016-02-18 02:37:11 +08:00
|
|
|
if (!CS)
|
|
|
|
return false;
|
|
|
|
|
2016-03-01 03:16:03 +08:00
|
|
|
// If the function touches memory, it needs a state store.
|
2016-02-18 02:37:11 +08:00
|
|
|
if (isAsynchronousEHPersonality(Personality))
|
|
|
|
return !CS.doesNotAccessMemory();
|
|
|
|
|
2016-03-01 03:16:03 +08:00
|
|
|
// If the function throws, it needs a state store.
|
2016-02-18 02:37:11 +08:00
|
|
|
return !CS.doesNotThrow();
|
|
|
|
}
|
|
|
|
|
2015-11-18 05:10:25 +08:00
|
|
|
void WinEHStatePass::addStateStores(Function &F, WinEHFuncInfo &FuncInfo) {
|
|
|
|
// Mark the registration node. The backend needs to know which alloca it is so
|
|
|
|
// that it can recover the original frame pointer.
|
[StackProtector] Fix computation of GSCookieOffset and EHCookieOffset with SEH4
Summary:
Fix the computation of the offsets present in the scopetable when using the
SEH (__except_handler4).
This patch added an intrinsic to track the position of the allocation on the
stack of the EHGuard. This position is needed when producing the ScopeTable.
```
struct _EH4_SCOPETABLE {
DWORD GSCookieOffset;
DWORD GSCookieXOROffset;
DWORD EHCookieOffset;
DWORD EHCookieXOROffset;
_EH4_SCOPETABLE_RECORD ScopeRecord[1];
};
struct _EH4_SCOPETABLE_RECORD {
DWORD EnclosingLevel;
long (*FilterFunc)();
union {
void (*HandlerAddress)();
void (*FinallyFunc)();
};
};
```
The code to generate the EHCookie is added in `X86WinEHState.cpp`.
Which is adding these instructions when using SEH4.
```
Lfunc_begin0:
# BB#0: # %entry
pushl %ebp
movl %esp, %ebp
pushl %ebx
pushl %edi
pushl %esi
subl $28, %esp
movl %ebp, %eax <<-- Loading FramePtr
movl %esp, -36(%ebp)
movl $-2, -16(%ebp)
movl $L__ehtable$use_except_handler4_ssp, %ecx
xorl ___security_cookie, %ecx
movl %ecx, -20(%ebp)
xorl ___security_cookie, %eax <<-- XOR FramePtr and Cookie
movl %eax, -40(%ebp) <<-- Storing EHGuard
leal -28(%ebp), %eax
movl $__except_handler4, -24(%ebp)
movl %fs:0, %ecx
movl %ecx, -28(%ebp)
movl %eax, %fs:0
movl $0, -16(%ebp)
calll _may_throw_or_crash
LBB1_1: # %cont
movl -28(%ebp), %eax
movl %eax, %fs:0
addl $28, %esp
popl %esi
popl %edi
popl %ebx
popl %ebp
retl
```
And the corresponding offset is computed:
```
Luse_except_handler4_ssp$parent_frame_offset = -36
.p2align 2
L__ehtable$use_except_handler4_ssp:
.long -2 # GSCookieOffset
.long 0 # GSCookieXOROffset
.long -40 # EHCookieOffset <<----
.long 0 # EHCookieXOROffset
.long -2 # ToState
.long _catchall_filt # FilterFunction
.long LBB1_2 # ExceptionHandler
```
Clang is not yet producing function using SEH4, but it's a work in progress.
This patch is a step toward having a valid implementation of SEH4.
Unfortunately, it is not yet fully working. The EH registration block is not
allocated at the right offset on the stack.
Reviewers: rnk, majnemer
Subscribers: llvm-commits, chrisha
Differential Revision: http://reviews.llvm.org/D21231
llvm-svn: 273281
2016-06-21 23:58:55 +08:00
|
|
|
IRBuilder<> Builder(RegNode->getNextNode());
|
2015-11-18 05:10:25 +08:00
|
|
|
Value *RegNodeI8 = Builder.CreateBitCast(RegNode, Builder.getInt8PtrTy());
|
|
|
|
Builder.CreateCall(
|
|
|
|
Intrinsic::getDeclaration(TheModule, Intrinsic::x86_seh_ehregnode),
|
|
|
|
{RegNodeI8});
|
|
|
|
|
[StackProtector] Fix computation of GSCookieOffset and EHCookieOffset with SEH4
Summary:
Fix the computation of the offsets present in the scopetable when using the
SEH (__except_handler4).
This patch added an intrinsic to track the position of the allocation on the
stack of the EHGuard. This position is needed when producing the ScopeTable.
```
struct _EH4_SCOPETABLE {
DWORD GSCookieOffset;
DWORD GSCookieXOROffset;
DWORD EHCookieOffset;
DWORD EHCookieXOROffset;
_EH4_SCOPETABLE_RECORD ScopeRecord[1];
};
struct _EH4_SCOPETABLE_RECORD {
DWORD EnclosingLevel;
long (*FilterFunc)();
union {
void (*HandlerAddress)();
void (*FinallyFunc)();
};
};
```
The code to generate the EHCookie is added in `X86WinEHState.cpp`.
Which is adding these instructions when using SEH4.
```
Lfunc_begin0:
# BB#0: # %entry
pushl %ebp
movl %esp, %ebp
pushl %ebx
pushl %edi
pushl %esi
subl $28, %esp
movl %ebp, %eax <<-- Loading FramePtr
movl %esp, -36(%ebp)
movl $-2, -16(%ebp)
movl $L__ehtable$use_except_handler4_ssp, %ecx
xorl ___security_cookie, %ecx
movl %ecx, -20(%ebp)
xorl ___security_cookie, %eax <<-- XOR FramePtr and Cookie
movl %eax, -40(%ebp) <<-- Storing EHGuard
leal -28(%ebp), %eax
movl $__except_handler4, -24(%ebp)
movl %fs:0, %ecx
movl %ecx, -28(%ebp)
movl %eax, %fs:0
movl $0, -16(%ebp)
calll _may_throw_or_crash
LBB1_1: # %cont
movl -28(%ebp), %eax
movl %eax, %fs:0
addl $28, %esp
popl %esi
popl %edi
popl %ebx
popl %ebp
retl
```
And the corresponding offset is computed:
```
Luse_except_handler4_ssp$parent_frame_offset = -36
.p2align 2
L__ehtable$use_except_handler4_ssp:
.long -2 # GSCookieOffset
.long 0 # GSCookieXOROffset
.long -40 # EHCookieOffset <<----
.long 0 # EHCookieXOROffset
.long -2 # ToState
.long _catchall_filt # FilterFunction
.long LBB1_2 # ExceptionHandler
```
Clang is not yet producing function using SEH4, but it's a work in progress.
This patch is a step toward having a valid implementation of SEH4.
Unfortunately, it is not yet fully working. The EH registration block is not
allocated at the right offset on the stack.
Reviewers: rnk, majnemer
Subscribers: llvm-commits, chrisha
Differential Revision: http://reviews.llvm.org/D21231
llvm-svn: 273281
2016-06-21 23:58:55 +08:00
|
|
|
if (EHGuardNode) {
|
|
|
|
IRBuilder<> Builder(EHGuardNode->getNextNode());
|
|
|
|
Value *EHGuardNodeI8 =
|
|
|
|
Builder.CreateBitCast(EHGuardNode, Builder.getInt8PtrTy());
|
|
|
|
Builder.CreateCall(
|
|
|
|
Intrinsic::getDeclaration(TheModule, Intrinsic::x86_seh_ehguard),
|
|
|
|
{EHGuardNodeI8});
|
|
|
|
}
|
|
|
|
|
2015-11-18 05:10:25 +08:00
|
|
|
// Calculate state numbers.
|
|
|
|
if (isAsynchronousEHPersonality(Personality))
|
|
|
|
calculateSEHStateNumbers(&F, FuncInfo);
|
|
|
|
else
|
|
|
|
calculateWinCXXEHStateNumbers(&F, FuncInfo);
|
2015-05-29 06:00:24 +08:00
|
|
|
|
|
|
|
// Iterate all the instructions and emit state number stores.
|
[IR] Reformulate LLVM's EH funclet IR
While we have successfully implemented a funclet-oriented EH scheme on
top of LLVM IR, our scheme has some notable deficiencies:
- catchendpad and cleanupendpad are necessary in the current design
but they are difficult to explain to others, even to seasoned LLVM
experts.
- catchendpad and cleanupendpad are optimization barriers. They cannot
be split and force all potentially throwing call-sites to be invokes.
This has a noticable effect on the quality of our code generation.
- catchpad, while similar in some aspects to invoke, is fairly awkward.
It is unsplittable, starts a funclet, and has control flow to other
funclets.
- The nesting relationship between funclets is currently a property of
control flow edges. Because of this, we are forced to carefully
analyze the flow graph to see if there might potentially exist illegal
nesting among funclets. While we have logic to clone funclets when
they are illegally nested, it would be nicer if we had a
representation which forbade them upfront.
Let's clean this up a bit by doing the following:
- Instead, make catchpad more like cleanuppad and landingpad: no control
flow, just a bunch of simple operands; catchpad would be splittable.
- Introduce catchswitch, a control flow instruction designed to model
the constraints of funclet oriented EH.
- Make funclet scoping explicit by having funclet instructions consume
the token produced by the funclet which contains them.
- Remove catchendpad and cleanupendpad. Their presence can be inferred
implicitly using coloring information.
N.B. The state numbering code for the CLR has been updated but the
veracity of it's output cannot be spoken for. An expert should take a
look to make sure the results are reasonable.
Reviewers: rnk, JosephTremoulet, andrew.w.kaylor
Differential Revision: http://reviews.llvm.org/D15139
llvm-svn: 255422
2015-12-12 13:38:55 +08:00
|
|
|
DenseMap<BasicBlock *, ColorVector> BlockColors = colorEHFunclets(F);
|
2016-02-18 02:37:11 +08:00
|
|
|
ReversePostOrderTraversal<Function *> RPOT(&F);
|
|
|
|
|
|
|
|
// InitialStates yields the state of the first call-site for a BasicBlock.
|
|
|
|
DenseMap<BasicBlock *, int> InitialStates;
|
|
|
|
// FinalStates yields the state of the last call-site for a BasicBlock.
|
|
|
|
DenseMap<BasicBlock *, int> FinalStates;
|
|
|
|
// Worklist used to revisit BasicBlocks with indeterminate
|
|
|
|
// Initial/Final-States.
|
|
|
|
std::deque<BasicBlock *> Worklist;
|
|
|
|
// Fill in InitialStates and FinalStates for BasicBlocks with call-sites.
|
|
|
|
for (BasicBlock *BB : RPOT) {
|
|
|
|
int InitialState = OverdefinedState;
|
|
|
|
int FinalState;
|
|
|
|
if (&F.getEntryBlock() == BB)
|
|
|
|
InitialState = FinalState = ParentBaseState;
|
|
|
|
for (Instruction &I : *BB) {
|
|
|
|
CallSite CS(&I);
|
|
|
|
if (!isStateStoreNeeded(Personality, CS))
|
2016-01-29 13:33:15 +08:00
|
|
|
continue;
|
|
|
|
|
2016-02-18 02:37:11 +08:00
|
|
|
int State = getStateForCallSite(BlockColors, FuncInfo, CS);
|
|
|
|
if (InitialState == OverdefinedState)
|
|
|
|
InitialState = State;
|
|
|
|
FinalState = State;
|
|
|
|
}
|
|
|
|
// No call-sites in this basic block? That's OK, we will come back to these
|
|
|
|
// in a later pass.
|
|
|
|
if (InitialState == OverdefinedState) {
|
|
|
|
Worklist.push_back(BB);
|
|
|
|
continue;
|
[IR] Reformulate LLVM's EH funclet IR
While we have successfully implemented a funclet-oriented EH scheme on
top of LLVM IR, our scheme has some notable deficiencies:
- catchendpad and cleanupendpad are necessary in the current design
but they are difficult to explain to others, even to seasoned LLVM
experts.
- catchendpad and cleanupendpad are optimization barriers. They cannot
be split and force all potentially throwing call-sites to be invokes.
This has a noticable effect on the quality of our code generation.
- catchpad, while similar in some aspects to invoke, is fairly awkward.
It is unsplittable, starts a funclet, and has control flow to other
funclets.
- The nesting relationship between funclets is currently a property of
control flow edges. Because of this, we are forced to carefully
analyze the flow graph to see if there might potentially exist illegal
nesting among funclets. While we have logic to clone funclets when
they are illegally nested, it would be nicer if we had a
representation which forbade them upfront.
Let's clean this up a bit by doing the following:
- Instead, make catchpad more like cleanuppad and landingpad: no control
flow, just a bunch of simple operands; catchpad would be splittable.
- Introduce catchswitch, a control flow instruction designed to model
the constraints of funclet oriented EH.
- Make funclet scoping explicit by having funclet instructions consume
the token produced by the funclet which contains them.
- Remove catchendpad and cleanupendpad. Their presence can be inferred
implicitly using coloring information.
N.B. The state numbering code for the CLR has been updated but the
veracity of it's output cannot be spoken for. An expert should take a
look to make sure the results are reasonable.
Reviewers: rnk, JosephTremoulet, andrew.w.kaylor
Differential Revision: http://reviews.llvm.org/D15139
llvm-svn: 255422
2015-12-12 13:38:55 +08:00
|
|
|
}
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(dbgs() << "X86WinEHState: " << BB->getName()
|
|
|
|
<< " InitialState=" << InitialState << '\n');
|
|
|
|
LLVM_DEBUG(dbgs() << "X86WinEHState: " << BB->getName()
|
|
|
|
<< " FinalState=" << FinalState << '\n');
|
2016-02-18 02:37:11 +08:00
|
|
|
InitialStates.insert({BB, InitialState});
|
|
|
|
FinalStates.insert({BB, FinalState});
|
|
|
|
}
|
|
|
|
|
|
|
|
// Try to fill-in InitialStates and FinalStates which have no call-sites.
|
|
|
|
while (!Worklist.empty()) {
|
|
|
|
BasicBlock *BB = Worklist.front();
|
|
|
|
Worklist.pop_front();
|
|
|
|
// This BasicBlock has already been figured out, nothing more we can do.
|
|
|
|
if (InitialStates.count(BB) != 0)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
int PredState = getPredState(FinalStates, F, ParentBaseState, BB);
|
|
|
|
if (PredState == OverdefinedState)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// We successfully inferred this BasicBlock's state via it's predecessors;
|
|
|
|
// enqueue it's successors to see if we can infer their states.
|
|
|
|
InitialStates.insert({BB, PredState});
|
|
|
|
FinalStates.insert({BB, PredState});
|
|
|
|
for (BasicBlock *SuccBB : successors(BB))
|
|
|
|
Worklist.push_back(SuccBB);
|
|
|
|
}
|
|
|
|
|
2016-02-19 05:13:35 +08:00
|
|
|
// Try to hoist stores from successors.
|
|
|
|
for (BasicBlock *BB : RPOT) {
|
|
|
|
int SuccState = getSuccState(InitialStates, F, ParentBaseState, BB);
|
|
|
|
if (SuccState == OverdefinedState)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// Update our FinalState to reflect the common InitialState of our
|
|
|
|
// successors.
|
|
|
|
FinalStates.insert({BB, SuccState});
|
|
|
|
}
|
|
|
|
|
2016-02-18 02:37:11 +08:00
|
|
|
// Finally, insert state stores before call-sites which transition us to a new
|
|
|
|
// state.
|
|
|
|
for (BasicBlock *BB : RPOT) {
|
|
|
|
auto &BBColors = BlockColors[BB];
|
|
|
|
BasicBlock *FuncletEntryBB = BBColors.front();
|
|
|
|
if (isa<CleanupPadInst>(FuncletEntryBB->getFirstNonPHI()))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
int PrevState = getPredState(FinalStates, F, ParentBaseState, BB);
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(dbgs() << "X86WinEHState: " << BB->getName()
|
|
|
|
<< " PrevState=" << PrevState << '\n');
|
2016-02-18 02:37:11 +08:00
|
|
|
|
|
|
|
for (Instruction &I : *BB) {
|
|
|
|
CallSite CS(&I);
|
|
|
|
if (!isStateStoreNeeded(Personality, CS))
|
|
|
|
continue;
|
[IR] Reformulate LLVM's EH funclet IR
While we have successfully implemented a funclet-oriented EH scheme on
top of LLVM IR, our scheme has some notable deficiencies:
- catchendpad and cleanupendpad are necessary in the current design
but they are difficult to explain to others, even to seasoned LLVM
experts.
- catchendpad and cleanupendpad are optimization barriers. They cannot
be split and force all potentially throwing call-sites to be invokes.
This has a noticable effect on the quality of our code generation.
- catchpad, while similar in some aspects to invoke, is fairly awkward.
It is unsplittable, starts a funclet, and has control flow to other
funclets.
- The nesting relationship between funclets is currently a property of
control flow edges. Because of this, we are forced to carefully
analyze the flow graph to see if there might potentially exist illegal
nesting among funclets. While we have logic to clone funclets when
they are illegally nested, it would be nicer if we had a
representation which forbade them upfront.
Let's clean this up a bit by doing the following:
- Instead, make catchpad more like cleanuppad and landingpad: no control
flow, just a bunch of simple operands; catchpad would be splittable.
- Introduce catchswitch, a control flow instruction designed to model
the constraints of funclet oriented EH.
- Make funclet scoping explicit by having funclet instructions consume
the token produced by the funclet which contains them.
- Remove catchendpad and cleanupendpad. Their presence can be inferred
implicitly using coloring information.
N.B. The state numbering code for the CLR has been updated but the
veracity of it's output cannot be spoken for. An expert should take a
look to make sure the results are reasonable.
Reviewers: rnk, JosephTremoulet, andrew.w.kaylor
Differential Revision: http://reviews.llvm.org/D15139
llvm-svn: 255422
2015-12-12 13:38:55 +08:00
|
|
|
|
2016-02-18 02:37:11 +08:00
|
|
|
int State = getStateForCallSite(BlockColors, FuncInfo, CS);
|
|
|
|
if (State != PrevState)
|
|
|
|
insertStateNumberStore(&I, State);
|
|
|
|
PrevState = State;
|
2015-05-29 06:00:24 +08:00
|
|
|
}
|
2016-02-19 05:13:35 +08:00
|
|
|
|
|
|
|
// We might have hoisted a state store into this block, emit it now.
|
|
|
|
auto EndState = FinalStates.find(BB);
|
|
|
|
if (EndState != FinalStates.end())
|
|
|
|
if (EndState->second != PrevState)
|
|
|
|
insertStateNumberStore(BB->getTerminator(), EndState->second);
|
2015-05-29 06:00:24 +08:00
|
|
|
}
|
2016-03-01 03:16:03 +08:00
|
|
|
|
|
|
|
SmallVector<CallSite, 1> SetJmp3CallSites;
|
|
|
|
for (BasicBlock *BB : RPOT) {
|
|
|
|
for (Instruction &I : *BB) {
|
|
|
|
CallSite CS(&I);
|
|
|
|
if (!CS)
|
|
|
|
continue;
|
|
|
|
if (CS.getCalledValue()->stripPointerCasts() !=
|
[opaque pointer types] Add a FunctionCallee wrapper type, and use it.
Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.
Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.
Then:
- update the CallInst/InvokeInst instruction creation functions to
take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.
One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.
However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)
Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.
Differential Revision: https://reviews.llvm.org/D57315
llvm-svn: 352827
2019-02-01 10:28:03 +08:00
|
|
|
SetJmp3.getCallee()->stripPointerCasts())
|
2016-03-01 03:16:03 +08:00
|
|
|
continue;
|
|
|
|
|
|
|
|
SetJmp3CallSites.push_back(CS);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
for (CallSite CS : SetJmp3CallSites) {
|
|
|
|
auto &BBColors = BlockColors[CS->getParent()];
|
|
|
|
BasicBlock *FuncletEntryBB = BBColors.front();
|
|
|
|
bool InCleanup = isa<CleanupPadInst>(FuncletEntryBB->getFirstNonPHI());
|
|
|
|
|
|
|
|
IRBuilder<> Builder(CS.getInstruction());
|
|
|
|
Value *State;
|
|
|
|
if (InCleanup) {
|
2019-02-02 04:44:47 +08:00
|
|
|
Value *StateField = Builder.CreateStructGEP(RegNode->getAllocatedType(),
|
|
|
|
RegNode, StateFieldIndex);
|
2019-02-02 04:44:24 +08:00
|
|
|
State = Builder.CreateLoad(Builder.getInt32Ty(), StateField);
|
2016-03-01 03:16:03 +08:00
|
|
|
} else {
|
|
|
|
State = Builder.getInt32(getStateForCallSite(BlockColors, FuncInfo, CS));
|
|
|
|
}
|
|
|
|
rewriteSetJmpCallSite(Builder, F, CS, State);
|
|
|
|
}
|
2015-05-29 06:00:24 +08:00
|
|
|
}
|
|
|
|
|
2016-02-01 12:28:59 +08:00
|
|
|
void WinEHStatePass::insertStateNumberStore(Instruction *IP, int State) {
|
2015-05-29 06:00:24 +08:00
|
|
|
IRBuilder<> Builder(IP);
|
2019-02-02 04:44:47 +08:00
|
|
|
Value *StateField = Builder.CreateStructGEP(RegNode->getAllocatedType(),
|
|
|
|
RegNode, StateFieldIndex);
|
2015-05-29 06:00:24 +08:00
|
|
|
Builder.CreateStore(Builder.getInt32(State), StateField);
|
|
|
|
}
|