2015-05-29 06:47:01 +08:00
|
|
|
//===-- CodeGen/AsmPrinter/WinException.cpp - Dwarf Exception Impl ------===//
|
2011-05-28 07:47:32 +08:00
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file contains support for writing Win64 exception info into asm files.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2015-05-29 06:47:01 +08:00
|
|
|
#include "WinException.h"
|
2012-12-04 00:50:05 +08:00
|
|
|
#include "llvm/ADT/StringExtras.h"
|
|
|
|
#include "llvm/ADT/Twine.h"
|
2011-05-28 07:47:32 +08:00
|
|
|
#include "llvm/CodeGen/AsmPrinter.h"
|
|
|
|
#include "llvm/CodeGen/MachineFrameInfo.h"
|
|
|
|
#include "llvm/CodeGen/MachineFunction.h"
|
2012-12-04 00:50:05 +08:00
|
|
|
#include "llvm/CodeGen/MachineModuleInfo.h"
|
2015-03-31 06:58:10 +08:00
|
|
|
#include "llvm/CodeGen/WinEHFuncInfo.h"
|
2013-01-02 19:36:10 +08:00
|
|
|
#include "llvm/IR/DataLayout.h"
|
2014-01-08 05:19:40 +08:00
|
|
|
#include "llvm/IR/Mangler.h"
|
2013-01-02 19:36:10 +08:00
|
|
|
#include "llvm/IR/Module.h"
|
2011-05-28 07:47:32 +08:00
|
|
|
#include "llvm/MC/MCAsmInfo.h"
|
|
|
|
#include "llvm/MC/MCContext.h"
|
|
|
|
#include "llvm/MC/MCExpr.h"
|
|
|
|
#include "llvm/MC/MCSection.h"
|
|
|
|
#include "llvm/MC/MCStreamer.h"
|
|
|
|
#include "llvm/MC/MCSymbol.h"
|
2015-05-30 01:00:57 +08:00
|
|
|
#include "llvm/MC/MCWin64EH.h"
|
2015-09-30 04:12:33 +08:00
|
|
|
#include "llvm/Support/COFF.h"
|
2012-12-04 00:50:05 +08:00
|
|
|
#include "llvm/Support/Dwarf.h"
|
|
|
|
#include "llvm/Support/ErrorHandling.h"
|
|
|
|
#include "llvm/Support/FormattedStream.h"
|
2011-05-28 07:47:32 +08:00
|
|
|
#include "llvm/Target/TargetFrameLowering.h"
|
2016-06-17 02:54:06 +08:00
|
|
|
#include "llvm/Target/TargetLowering.h"
|
2011-05-28 07:47:32 +08:00
|
|
|
#include "llvm/Target/TargetLoweringObjectFile.h"
|
|
|
|
#include "llvm/Target/TargetOptions.h"
|
|
|
|
#include "llvm/Target/TargetRegisterInfo.h"
|
2015-10-08 05:13:15 +08:00
|
|
|
#include "llvm/Target/TargetSubtargetInfo.h"
|
2011-05-28 07:47:32 +08:00
|
|
|
using namespace llvm;
|
|
|
|
|
2015-05-30 01:00:57 +08:00
|
|
|
WinException::WinException(AsmPrinter *A) : EHStreamer(A) {
|
|
|
|
// MSVC's EH tables are always composed of 32-bit words. All known 64-bit
|
|
|
|
// platforms use an imagerel32 relocation to refer to symbols.
|
|
|
|
useImageRel32 = (A->getDataLayout().getPointerSizeInBits() == 64);
|
|
|
|
}
|
2011-05-28 07:47:32 +08:00
|
|
|
|
2015-05-29 06:47:01 +08:00
|
|
|
WinException::~WinException() {}
|
2011-05-28 07:47:32 +08:00
|
|
|
|
2013-11-26 21:34:55 +08:00
|
|
|
/// endModule - Emit all exception information that should come after the
|
2011-05-28 07:47:32 +08:00
|
|
|
/// content.
|
2015-05-29 06:47:01 +08:00
|
|
|
void WinException::endModule() {
|
2015-06-10 09:02:30 +08:00
|
|
|
auto &OS = *Asm->OutStreamer;
|
|
|
|
const Module *M = MMI->getModule();
|
2015-06-10 09:13:44 +08:00
|
|
|
for (const Function &F : *M)
|
|
|
|
if (F.hasFnAttribute("safeseh"))
|
2015-06-10 09:02:30 +08:00
|
|
|
OS.EmitCOFFSafeSEH(Asm->getSymbol(&F));
|
2011-05-28 07:47:32 +08:00
|
|
|
}
|
|
|
|
|
2015-05-29 06:47:01 +08:00
|
|
|
void WinException::beginFunction(const MachineFunction *MF) {
|
2011-05-28 12:21:04 +08:00
|
|
|
shouldEmitMoves = shouldEmitPersonality = shouldEmitLSDA = false;
|
|
|
|
|
|
|
|
// If any landing pads survive, we need an EH table.
|
2016-12-02 03:32:15 +08:00
|
|
|
bool hasLandingPads = !MF->getLandingPads().empty();
|
|
|
|
bool hasEHFunclets = MF->hasEHFunclets();
|
2011-05-28 12:21:04 +08:00
|
|
|
|
2015-05-30 01:00:57 +08:00
|
|
|
const Function *F = MF->getFunction();
|
|
|
|
|
2017-03-21 01:45:59 +08:00
|
|
|
shouldEmitMoves = Asm->needsSEHMoves() && MF->hasWinCFI();
|
2011-05-28 12:21:04 +08:00
|
|
|
|
|
|
|
const TargetLoweringObjectFile &TLOF = Asm->getObjFileLowering();
|
|
|
|
unsigned PerEncoding = TLOF.getPersonalityEncoding();
|
|
|
|
|
2016-10-01 06:10:12 +08:00
|
|
|
EHPersonality Per = EHPersonality::Unknown;
|
|
|
|
const Function *PerFn = nullptr;
|
|
|
|
if (F->hasPersonalityFn()) {
|
|
|
|
PerFn = dyn_cast<Function>(F->getPersonalityFn()->stripPointerCasts());
|
|
|
|
Per = classifyEHPersonality(PerFn);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool forceEmitPersonality = F->hasPersonalityFn() &&
|
|
|
|
!isNoOpWithoutInvoke(Per) &&
|
|
|
|
F->needsUnwindTableEntry();
|
2015-07-15 03:22:51 +08:00
|
|
|
|
2015-08-28 07:27:47 +08:00
|
|
|
shouldEmitPersonality =
|
|
|
|
forceEmitPersonality || ((hasLandingPads || hasEHFunclets) &&
|
2016-10-01 06:10:12 +08:00
|
|
|
PerEncoding != dwarf::DW_EH_PE_omit && PerFn);
|
2011-05-28 12:21:04 +08:00
|
|
|
|
|
|
|
unsigned LSDAEncoding = TLOF.getLSDAEncoding();
|
|
|
|
shouldEmitLSDA = shouldEmitPersonality &&
|
|
|
|
LSDAEncoding != dwarf::DW_EH_PE_omit;
|
|
|
|
|
2015-08-28 07:27:47 +08:00
|
|
|
// If we're not using CFI, we don't want the CFI or the personality, but we
|
|
|
|
// might want EH tables if we had EH pads.
|
2017-03-21 01:45:59 +08:00
|
|
|
if (!Asm->MAI->usesWindowsCFI()) {
|
2016-10-01 06:10:12 +08:00
|
|
|
if (Per == EHPersonality::MSVC_X86SEH && !hasEHFunclets) {
|
|
|
|
// If this is 32-bit SEH and we don't have any funclets (really invokes),
|
|
|
|
// make sure we emit the parent offset label. Some unreferenced filter
|
|
|
|
// functions may still refer to it.
|
|
|
|
const WinEHFuncInfo &FuncInfo = *MF->getWinEHFuncInfo();
|
|
|
|
StringRef FLinkageName =
|
2017-05-16 08:39:01 +08:00
|
|
|
GlobalValue::dropLLVMManglingEscape(MF->getFunction()->getName());
|
2016-10-01 06:10:12 +08:00
|
|
|
emitEHRegistrationOffsetLabel(FuncInfo, FLinkageName);
|
|
|
|
}
|
2015-10-10 08:04:29 +08:00
|
|
|
shouldEmitLSDA = hasEHFunclets;
|
2015-05-30 01:00:57 +08:00
|
|
|
shouldEmitPersonality = false;
|
|
|
|
return;
|
|
|
|
}
|
2015-04-01 06:35:44 +08:00
|
|
|
|
2015-09-30 04:12:33 +08:00
|
|
|
beginFunclet(MF->front(), Asm->CurrentFnSym);
|
2011-05-28 07:47:32 +08:00
|
|
|
}
|
|
|
|
|
2013-11-26 21:34:55 +08:00
|
|
|
/// endFunction - Gather and emit post-function exception information.
|
2011-05-28 07:47:32 +08:00
|
|
|
///
|
2015-05-29 06:47:01 +08:00
|
|
|
void WinException::endFunction(const MachineFunction *MF) {
|
2015-05-30 01:00:57 +08:00
|
|
|
if (!shouldEmitPersonality && !shouldEmitMoves && !shouldEmitLSDA)
|
2011-05-28 12:21:04 +08:00
|
|
|
return;
|
|
|
|
|
2015-07-14 04:41:46 +08:00
|
|
|
const Function *F = MF->getFunction();
|
|
|
|
EHPersonality Per = EHPersonality::Unknown;
|
|
|
|
if (F->hasPersonalityFn())
|
2016-10-01 06:10:12 +08:00
|
|
|
Per = classifyEHPersonality(F->getPersonalityFn()->stripPointerCasts());
|
2015-04-16 02:48:15 +08:00
|
|
|
|
2015-10-07 04:28:16 +08:00
|
|
|
// Get rid of any dead landing pads if we're not using funclets. In funclet
|
|
|
|
// schemes, the landing pad is not actually reachable. It only exists so
|
|
|
|
// that we can emit the right table data.
|
2016-12-02 03:32:15 +08:00
|
|
|
if (!isFuncletEHPersonality(Per)) {
|
|
|
|
MachineFunction *NonConstMF = const_cast<MachineFunction*>(MF);
|
|
|
|
NonConstMF->tidyLandingPads();
|
|
|
|
}
|
2011-05-30 08:13:34 +08:00
|
|
|
|
2015-09-30 04:12:33 +08:00
|
|
|
endFunclet();
|
|
|
|
|
2015-10-02 05:38:24 +08:00
|
|
|
// endFunclet will emit the necessary .xdata tables for x64 SEH.
|
2016-12-02 03:32:15 +08:00
|
|
|
if (Per == EHPersonality::MSVC_Win64SEH && MF->hasEHFunclets())
|
2015-10-02 05:38:24 +08:00
|
|
|
return;
|
|
|
|
|
2015-05-30 01:00:57 +08:00
|
|
|
if (shouldEmitPersonality || shouldEmitLSDA) {
|
2015-04-25 03:11:51 +08:00
|
|
|
Asm->OutStreamer->PushSection();
|
2015-01-14 09:05:27 +08:00
|
|
|
|
2016-05-03 07:22:18 +08:00
|
|
|
// Just switch sections to the right xdata section.
|
|
|
|
MCSection *XData = Asm->OutStreamer->getAssociatedXDataSection(
|
|
|
|
Asm->OutStreamer->getCurrentSectionOnly());
|
2015-09-30 04:12:33 +08:00
|
|
|
Asm->OutStreamer->SwitchSection(XData);
|
2015-01-14 09:05:27 +08:00
|
|
|
|
2015-01-15 02:50:10 +08:00
|
|
|
// Emit the tables appropriate to the personality function in use. If we
|
|
|
|
// don't recognize the personality, assume it uses an Itanium-style LSDA.
|
2015-02-14 08:21:02 +08:00
|
|
|
if (Per == EHPersonality::MSVC_Win64SEH)
|
2015-09-10 05:10:03 +08:00
|
|
|
emitCSpecificHandlerTable(MF);
|
2015-05-30 01:00:57 +08:00
|
|
|
else if (Per == EHPersonality::MSVC_X86SEH)
|
2015-06-10 05:42:19 +08:00
|
|
|
emitExceptHandlerTable(MF);
|
2015-03-31 06:58:10 +08:00
|
|
|
else if (Per == EHPersonality::MSVC_CXX)
|
|
|
|
emitCXXFrameHandler3Table(MF);
|
2015-10-14 04:18:27 +08:00
|
|
|
else if (Per == EHPersonality::CoreCLR)
|
|
|
|
emitCLRExceptionTable(MF);
|
2015-01-15 02:50:10 +08:00
|
|
|
else
|
2015-01-14 09:05:27 +08:00
|
|
|
emitExceptionTable();
|
|
|
|
|
2015-04-25 03:11:51 +08:00
|
|
|
Asm->OutStreamer->PopSection();
|
2011-05-30 08:13:34 +08:00
|
|
|
}
|
2015-09-30 04:12:33 +08:00
|
|
|
}
|
|
|
|
|
2016-11-20 21:47:59 +08:00
|
|
|
/// Retrieve the MCSymbol for a GlobalValue or MachineBasicBlock.
|
2015-10-10 08:04:29 +08:00
|
|
|
static MCSymbol *getMCSymbolForMBB(AsmPrinter *Asm,
|
|
|
|
const MachineBasicBlock *MBB) {
|
|
|
|
if (!MBB)
|
2015-09-30 04:12:33 +08:00
|
|
|
return nullptr;
|
2015-10-10 08:04:29 +08:00
|
|
|
|
|
|
|
assert(MBB->isEHFuncletEntry());
|
|
|
|
|
|
|
|
// Give catches and cleanups a name based off of their parent function and
|
|
|
|
// their funclet entry block's number.
|
|
|
|
const MachineFunction *MF = MBB->getParent();
|
|
|
|
const Function *F = MF->getFunction();
|
2017-05-16 08:39:01 +08:00
|
|
|
StringRef FuncLinkageName = GlobalValue::dropLLVMManglingEscape(F->getName());
|
2015-10-10 08:04:29 +08:00
|
|
|
MCContext &Ctx = MF->getContext();
|
|
|
|
StringRef HandlerPrefix = MBB->isCleanupFuncletEntry() ? "dtor" : "catch";
|
|
|
|
return Ctx.getOrCreateSymbol("?" + HandlerPrefix + "$" +
|
|
|
|
Twine(MBB->getNumber()) + "@?0?" +
|
|
|
|
FuncLinkageName + "@4HA");
|
2015-09-30 04:12:33 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void WinException::beginFunclet(const MachineBasicBlock &MBB,
|
|
|
|
MCSymbol *Sym) {
|
|
|
|
CurrentFuncletEntry = &MBB;
|
|
|
|
|
|
|
|
const Function *F = Asm->MF->getFunction();
|
|
|
|
// If a symbol was not provided for the funclet, invent one.
|
|
|
|
if (!Sym) {
|
2015-10-10 08:04:29 +08:00
|
|
|
Sym = getMCSymbolForMBB(Asm, &MBB);
|
2015-09-30 04:12:33 +08:00
|
|
|
|
|
|
|
// Describe our funclet symbol as a function with internal linkage.
|
|
|
|
Asm->OutStreamer->BeginCOFFSymbolDef(Sym);
|
|
|
|
Asm->OutStreamer->EmitCOFFSymbolStorageClass(COFF::IMAGE_SYM_CLASS_STATIC);
|
|
|
|
Asm->OutStreamer->EmitCOFFSymbolType(COFF::IMAGE_SYM_DTYPE_FUNCTION
|
|
|
|
<< COFF::SCT_COMPLEX_TYPE_SHIFT);
|
|
|
|
Asm->OutStreamer->EndCOFFSymbolDef();
|
|
|
|
|
|
|
|
// We want our funclet's entry point to be aligned such that no nops will be
|
|
|
|
// present after the label.
|
|
|
|
Asm->EmitAlignment(std::max(Asm->MF->getAlignment(), MBB.getAlignment()),
|
|
|
|
F);
|
|
|
|
|
|
|
|
// Now that we've emitted the alignment directive, point at our funclet.
|
|
|
|
Asm->OutStreamer->EmitLabel(Sym);
|
|
|
|
}
|
2015-05-30 01:00:57 +08:00
|
|
|
|
2015-09-30 04:12:33 +08:00
|
|
|
// Mark 'Sym' as starting our funclet.
|
2016-12-29 03:05:12 +08:00
|
|
|
if (shouldEmitMoves || shouldEmitPersonality) {
|
|
|
|
CurrentFuncletTextSection = Asm->OutStreamer->getCurrentSectionOnly();
|
2015-09-30 04:12:33 +08:00
|
|
|
Asm->OutStreamer->EmitWinCFIStartProc(Sym);
|
2016-12-29 03:05:12 +08:00
|
|
|
}
|
2015-09-30 04:12:33 +08:00
|
|
|
|
|
|
|
if (shouldEmitPersonality) {
|
|
|
|
const TargetLoweringObjectFile &TLOF = Asm->getObjFileLowering();
|
|
|
|
const Function *PerFn = nullptr;
|
|
|
|
|
|
|
|
// Determine which personality routine we are using for this funclet.
|
|
|
|
if (F->hasPersonalityFn())
|
|
|
|
PerFn = dyn_cast<Function>(F->getPersonalityFn()->stripPointerCasts());
|
|
|
|
const MCSymbol *PersHandlerSym =
|
2016-09-16 15:33:15 +08:00
|
|
|
TLOF.getCFIPersonalitySymbol(PerFn, Asm->TM, MMI);
|
2015-09-30 04:12:33 +08:00
|
|
|
|
2016-12-09 04:38:46 +08:00
|
|
|
// Do not emit a .seh_handler directives for cleanup funclets.
|
|
|
|
// FIXME: This means cleanup funclets cannot handle exceptions. Given that
|
|
|
|
// Clang doesn't produce EH constructs inside cleanup funclets and LLVM's
|
|
|
|
// inliner doesn't allow inlining them, this isn't a major problem in
|
|
|
|
// practice.
|
|
|
|
if (!CurrentFuncletEntry->isCleanupFuncletEntry())
|
2015-09-30 04:12:33 +08:00
|
|
|
Asm->OutStreamer->EmitWinEHHandler(PersHandlerSym, true, true);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void WinException::endFunclet() {
|
|
|
|
// No funclet to process? Great, we have nothing to do.
|
|
|
|
if (!CurrentFuncletEntry)
|
|
|
|
return;
|
|
|
|
|
2016-12-02 03:32:15 +08:00
|
|
|
const MachineFunction *MF = Asm->MF;
|
2015-09-30 04:12:33 +08:00
|
|
|
if (shouldEmitMoves || shouldEmitPersonality) {
|
2016-12-02 03:32:15 +08:00
|
|
|
const Function *F = MF->getFunction();
|
2015-09-30 04:12:33 +08:00
|
|
|
EHPersonality Per = EHPersonality::Unknown;
|
|
|
|
if (F->hasPersonalityFn())
|
2016-10-01 06:10:12 +08:00
|
|
|
Per = classifyEHPersonality(F->getPersonalityFn()->stripPointerCasts());
|
2015-09-30 04:12:33 +08:00
|
|
|
|
|
|
|
// Emit an UNWIND_INFO struct describing the prologue.
|
|
|
|
Asm->OutStreamer->EmitWinEHHandlerData();
|
|
|
|
|
|
|
|
if (Per == EHPersonality::MSVC_CXX && shouldEmitPersonality &&
|
|
|
|
!CurrentFuncletEntry->isCleanupFuncletEntry()) {
|
2015-10-02 05:38:24 +08:00
|
|
|
// If this is a C++ catch funclet (or the parent function),
|
|
|
|
// emit a reference to the LSDA for the parent function.
|
2017-05-16 08:39:01 +08:00
|
|
|
StringRef FuncLinkageName = GlobalValue::dropLLVMManglingEscape(F->getName());
|
2015-09-30 04:12:33 +08:00
|
|
|
MCSymbol *FuncInfoXData = Asm->OutContext.getOrCreateSymbol(
|
|
|
|
Twine("$cppxdata$", FuncLinkageName));
|
|
|
|
Asm->OutStreamer->EmitValue(create32bitRef(FuncInfoXData), 4);
|
2016-12-02 03:32:15 +08:00
|
|
|
} else if (Per == EHPersonality::MSVC_Win64SEH && MF->hasEHFunclets() &&
|
2015-10-02 05:38:24 +08:00
|
|
|
!CurrentFuncletEntry->isEHFuncletEntry()) {
|
|
|
|
// If this is the parent function in Win64 SEH, emit the LSDA immediately
|
|
|
|
// following .seh_handlerdata.
|
2016-12-02 03:32:15 +08:00
|
|
|
emitCSpecificHandlerTable(MF);
|
2015-09-30 04:12:33 +08:00
|
|
|
}
|
|
|
|
|
2016-12-29 03:05:12 +08:00
|
|
|
// Switch back to the funclet start .text section now that we are done
|
|
|
|
// writing to .xdata, and emit an .seh_endproc directive to mark the end of
|
|
|
|
// the function.
|
|
|
|
Asm->OutStreamer->SwitchSection(CurrentFuncletTextSection);
|
2015-05-30 01:00:57 +08:00
|
|
|
Asm->OutStreamer->EmitWinCFIEndProc();
|
2015-09-30 04:12:33 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Let's make sure we don't try to end the same funclet twice.
|
|
|
|
CurrentFuncletEntry = nullptr;
|
2011-05-28 07:47:32 +08:00
|
|
|
}
|
2015-01-14 09:05:27 +08:00
|
|
|
|
2015-05-30 01:00:57 +08:00
|
|
|
const MCExpr *WinException::create32bitRef(const MCSymbol *Value) {
|
2015-03-31 06:58:10 +08:00
|
|
|
if (!Value)
|
2015-05-30 09:25:56 +08:00
|
|
|
return MCConstantExpr::create(0, Asm->OutContext);
|
|
|
|
return MCSymbolRefExpr::create(Value, useImageRel32
|
2015-05-30 01:00:57 +08:00
|
|
|
? MCSymbolRefExpr::VK_COFF_IMGREL32
|
|
|
|
: MCSymbolRefExpr::VK_None,
|
2015-01-14 09:05:27 +08:00
|
|
|
Asm->OutContext);
|
|
|
|
}
|
|
|
|
|
2015-10-23 23:06:05 +08:00
|
|
|
const MCExpr *WinException::create32bitRef(const GlobalValue *GV) {
|
|
|
|
if (!GV)
|
2015-05-30 09:25:56 +08:00
|
|
|
return MCConstantExpr::create(0, Asm->OutContext);
|
2015-10-23 23:06:05 +08:00
|
|
|
return create32bitRef(Asm->getSymbol(GV));
|
2015-03-31 06:58:10 +08:00
|
|
|
}
|
|
|
|
|
2015-10-14 00:44:30 +08:00
|
|
|
const MCExpr *WinException::getLabelPlusOne(const MCSymbol *Label) {
|
2015-09-29 07:56:30 +08:00
|
|
|
return MCBinaryExpr::createAdd(create32bitRef(Label),
|
|
|
|
MCConstantExpr::create(1, Asm->OutContext),
|
|
|
|
Asm->OutContext);
|
|
|
|
}
|
|
|
|
|
2015-10-14 04:18:27 +08:00
|
|
|
const MCExpr *WinException::getOffset(const MCSymbol *OffsetOf,
|
|
|
|
const MCSymbol *OffsetFrom) {
|
|
|
|
return MCBinaryExpr::createSub(
|
|
|
|
MCSymbolRefExpr::create(OffsetOf, Asm->OutContext),
|
|
|
|
MCSymbolRefExpr::create(OffsetFrom, Asm->OutContext), Asm->OutContext);
|
|
|
|
}
|
|
|
|
|
|
|
|
const MCExpr *WinException::getOffsetPlusOne(const MCSymbol *OffsetOf,
|
|
|
|
const MCSymbol *OffsetFrom) {
|
|
|
|
return MCBinaryExpr::createAdd(getOffset(OffsetOf, OffsetFrom),
|
|
|
|
MCConstantExpr::create(1, Asm->OutContext),
|
|
|
|
Asm->OutContext);
|
|
|
|
}
|
|
|
|
|
2015-11-18 05:10:25 +08:00
|
|
|
int WinException::getFrameIndexOffset(int FrameIndex,
|
|
|
|
const WinEHFuncInfo &FuncInfo) {
|
2015-10-08 05:13:15 +08:00
|
|
|
const TargetFrameLowering &TFI = *Asm->MF->getSubtarget().getFrameLowering();
|
|
|
|
unsigned UnusedReg;
|
2016-06-17 02:54:06 +08:00
|
|
|
if (Asm->MAI->usesWindowsCFI()) {
|
|
|
|
int Offset =
|
|
|
|
TFI.getFrameIndexReferencePreferSP(*Asm->MF, FrameIndex, UnusedReg,
|
|
|
|
/*IgnoreSPUpdates*/ true);
|
|
|
|
assert(UnusedReg ==
|
|
|
|
Asm->MF->getSubtarget()
|
|
|
|
.getTargetLowering()
|
|
|
|
->getStackPointerRegisterToSaveRestore());
|
|
|
|
return Offset;
|
|
|
|
}
|
|
|
|
|
2015-11-06 05:09:49 +08:00
|
|
|
// For 32-bit, offsets should be relative to the end of the EH registration
|
|
|
|
// node. For 64-bit, it's relative to SP at the end of the prologue.
|
|
|
|
assert(FuncInfo.EHRegNodeEndOffset != INT_MAX);
|
|
|
|
int Offset = TFI.getFrameIndexReference(*Asm->MF, FrameIndex, UnusedReg);
|
|
|
|
Offset += FuncInfo.EHRegNodeEndOffset;
|
|
|
|
return Offset;
|
2015-10-08 05:13:15 +08:00
|
|
|
}
|
|
|
|
|
2015-10-06 05:20:26 +08:00
|
|
|
namespace {
|
2015-10-14 00:44:30 +08:00
|
|
|
|
|
|
|
/// Top-level state used to represent unwind to caller
|
|
|
|
const int NullState = -1;
|
|
|
|
|
|
|
|
struct InvokeStateChange {
|
|
|
|
/// EH Label immediately after the last invoke in the previous state, or
|
|
|
|
/// nullptr if the previous state was the null state.
|
|
|
|
const MCSymbol *PreviousEndLabel;
|
|
|
|
|
|
|
|
/// EH label immediately before the first invoke in the new state, or nullptr
|
|
|
|
/// if the new state is the null state.
|
|
|
|
const MCSymbol *NewStartLabel;
|
|
|
|
|
|
|
|
/// State of the invoke following NewStartLabel, or NullState to indicate
|
|
|
|
/// the presence of calls which may unwind to caller.
|
|
|
|
int NewState;
|
2015-10-02 05:38:24 +08:00
|
|
|
};
|
|
|
|
|
2015-10-14 00:44:30 +08:00
|
|
|
/// Iterator that reports all the invoke state changes in a range of machine
|
|
|
|
/// basic blocks. Changes to the null state are reported whenever a call that
|
|
|
|
/// may unwind to caller is encountered. The MBB range is expected to be an
|
|
|
|
/// entire function or funclet, and the start and end of the range are treated
|
|
|
|
/// as being in the NullState even if there's not an unwind-to-caller call
|
|
|
|
/// before the first invoke or after the last one (i.e., the first state change
|
|
|
|
/// reported is the first change to something other than NullState, and a
|
|
|
|
/// change back to NullState is always reported at the end of iteration).
|
|
|
|
class InvokeStateChangeIterator {
|
2015-11-18 05:10:25 +08:00
|
|
|
InvokeStateChangeIterator(const WinEHFuncInfo &EHInfo,
|
2015-10-14 00:44:30 +08:00
|
|
|
MachineFunction::const_iterator MFI,
|
|
|
|
MachineFunction::const_iterator MFE,
|
[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
|
|
|
MachineBasicBlock::const_iterator MBBI,
|
|
|
|
int BaseState)
|
|
|
|
: EHInfo(EHInfo), MFI(MFI), MFE(MFE), MBBI(MBBI), BaseState(BaseState) {
|
2015-10-14 00:44:30 +08:00
|
|
|
LastStateChange.PreviousEndLabel = nullptr;
|
|
|
|
LastStateChange.NewStartLabel = nullptr;
|
[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
|
|
|
LastStateChange.NewState = BaseState;
|
2015-10-02 05:38:24 +08:00
|
|
|
scan();
|
|
|
|
}
|
|
|
|
|
2015-10-14 00:44:30 +08:00
|
|
|
public:
|
|
|
|
static iterator_range<InvokeStateChangeIterator>
|
2015-11-18 05:10:25 +08:00
|
|
|
range(const WinEHFuncInfo &EHInfo, MachineFunction::const_iterator Begin,
|
[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
|
|
|
MachineFunction::const_iterator End, int BaseState = NullState) {
|
2015-10-14 00:44:30 +08:00
|
|
|
// Reject empty ranges to simplify bookkeeping by ensuring that we can get
|
|
|
|
// the end of the last block.
|
|
|
|
assert(Begin != End);
|
|
|
|
auto BlockBegin = Begin->begin();
|
|
|
|
auto BlockEnd = std::prev(End)->end();
|
[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
|
|
|
return make_range(
|
|
|
|
InvokeStateChangeIterator(EHInfo, Begin, End, BlockBegin, BaseState),
|
|
|
|
InvokeStateChangeIterator(EHInfo, End, End, BlockEnd, BaseState));
|
2015-10-14 00:44:30 +08:00
|
|
|
}
|
|
|
|
|
2015-10-02 05:38:24 +08:00
|
|
|
// Iterator methods.
|
2015-10-14 00:44:30 +08:00
|
|
|
bool operator==(const InvokeStateChangeIterator &O) const {
|
[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
|
|
|
assert(BaseState == O.BaseState);
|
2015-10-14 00:44:30 +08:00
|
|
|
// Must be visiting same block.
|
|
|
|
if (MFI != O.MFI)
|
|
|
|
return false;
|
|
|
|
// Must be visiting same isntr.
|
|
|
|
if (MBBI != O.MBBI)
|
|
|
|
return false;
|
|
|
|
// At end of block/instr iteration, we can still have two distinct states:
|
|
|
|
// one to report the final EndLabel, and another indicating the end of the
|
|
|
|
// state change iteration. Check for CurrentEndLabel equality to
|
|
|
|
// distinguish these.
|
|
|
|
return CurrentEndLabel == O.CurrentEndLabel;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool operator!=(const InvokeStateChangeIterator &O) const {
|
|
|
|
return !operator==(O);
|
|
|
|
}
|
|
|
|
InvokeStateChange &operator*() { return LastStateChange; }
|
|
|
|
InvokeStateChange *operator->() { return &LastStateChange; }
|
|
|
|
InvokeStateChangeIterator &operator++() { return scan(); }
|
2015-10-02 05:38:24 +08:00
|
|
|
|
|
|
|
private:
|
2015-10-14 00:44:30 +08:00
|
|
|
InvokeStateChangeIterator &scan();
|
2015-10-02 05:38:24 +08:00
|
|
|
|
2015-11-18 05:10:25 +08:00
|
|
|
const WinEHFuncInfo &EHInfo;
|
2015-10-14 00:44:30 +08:00
|
|
|
const MCSymbol *CurrentEndLabel = nullptr;
|
|
|
|
MachineFunction::const_iterator MFI;
|
|
|
|
MachineFunction::const_iterator MFE;
|
2015-10-02 05:38:24 +08:00
|
|
|
MachineBasicBlock::const_iterator MBBI;
|
2015-10-14 00:44:30 +08:00
|
|
|
InvokeStateChange LastStateChange;
|
|
|
|
bool VisitingInvoke = false;
|
[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
|
|
|
int BaseState;
|
2015-10-02 05:38:24 +08:00
|
|
|
};
|
2015-10-14 00:44:30 +08:00
|
|
|
|
2015-10-06 05:20:26 +08:00
|
|
|
} // end anonymous namespace
|
2015-10-02 05:38:24 +08:00
|
|
|
|
2015-10-14 00:44:30 +08:00
|
|
|
InvokeStateChangeIterator &InvokeStateChangeIterator::scan() {
|
|
|
|
bool IsNewBlock = false;
|
|
|
|
for (; MFI != MFE; ++MFI, IsNewBlock = true) {
|
|
|
|
if (IsNewBlock)
|
|
|
|
MBBI = MFI->begin();
|
|
|
|
for (auto MBBE = MFI->end(); MBBI != MBBE; ++MBBI) {
|
|
|
|
const MachineInstr &MI = *MBBI;
|
[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
|
|
|
if (!VisitingInvoke && LastStateChange.NewState != BaseState &&
|
2015-10-14 00:44:30 +08:00
|
|
|
MI.isCall() && !EHStreamer::callToNoUnwindFunction(&MI)) {
|
|
|
|
// Indicate a change of state to the null state. We don't have
|
|
|
|
// start/end EH labels handy but the caller won't expect them for
|
|
|
|
// null state regions.
|
|
|
|
LastStateChange.PreviousEndLabel = CurrentEndLabel;
|
|
|
|
LastStateChange.NewStartLabel = nullptr;
|
[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
|
|
|
LastStateChange.NewState = BaseState;
|
2015-10-14 00:44:30 +08:00
|
|
|
CurrentEndLabel = nullptr;
|
|
|
|
// Don't re-visit this instr on the next scan
|
|
|
|
++MBBI;
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
|
|
|
// All other state changes are at EH labels before/after invokes.
|
|
|
|
if (!MI.isEHLabel())
|
|
|
|
continue;
|
|
|
|
MCSymbol *Label = MI.getOperand(0).getMCSymbol();
|
|
|
|
if (Label == CurrentEndLabel) {
|
|
|
|
VisitingInvoke = false;
|
|
|
|
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
|
|
|
auto InvokeMapIter = EHInfo.LabelToStateMap.find(Label);
|
2015-10-14 00:44:30 +08:00
|
|
|
// Ignore EH labels that aren't the ones inserted before an invoke
|
[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
|
|
|
if (InvokeMapIter == EHInfo.LabelToStateMap.end())
|
2015-10-14 00:44:30 +08:00
|
|
|
continue;
|
|
|
|
auto &StateAndEnd = InvokeMapIter->second;
|
|
|
|
int NewState = StateAndEnd.first;
|
|
|
|
// Keep track of the fact that we're between EH start/end labels so
|
|
|
|
// we know not to treat the inoke we'll see as unwinding to caller.
|
|
|
|
VisitingInvoke = true;
|
|
|
|
if (NewState == LastStateChange.NewState) {
|
|
|
|
// The state isn't actually changing here. Record the new end and
|
|
|
|
// keep going.
|
|
|
|
CurrentEndLabel = StateAndEnd.second;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
// Found a state change to report
|
|
|
|
LastStateChange.PreviousEndLabel = CurrentEndLabel;
|
|
|
|
LastStateChange.NewStartLabel = Label;
|
|
|
|
LastStateChange.NewState = NewState;
|
|
|
|
// Start keeping track of the new current end
|
|
|
|
CurrentEndLabel = StateAndEnd.second;
|
|
|
|
// Don't re-visit this instr on the next scan
|
|
|
|
++MBBI;
|
|
|
|
return *this;
|
2015-10-02 05:38:24 +08:00
|
|
|
}
|
|
|
|
}
|
2015-10-14 00:44:30 +08:00
|
|
|
// Iteration hit the end of the block range.
|
[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
|
|
|
if (LastStateChange.NewState != BaseState) {
|
2015-10-14 00:44:30 +08:00
|
|
|
// Report the end of the last new state
|
|
|
|
LastStateChange.PreviousEndLabel = CurrentEndLabel;
|
|
|
|
LastStateChange.NewStartLabel = nullptr;
|
[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
|
|
|
LastStateChange.NewState = BaseState;
|
2015-10-14 00:44:30 +08:00
|
|
|
// Leave CurrentEndLabel non-null to distinguish this state from end.
|
|
|
|
assert(CurrentEndLabel != nullptr);
|
2015-10-02 05:38:24 +08:00
|
|
|
return *this;
|
|
|
|
}
|
2015-10-14 00:44:30 +08:00
|
|
|
// We've reported all state changes and hit the end state.
|
|
|
|
CurrentEndLabel = nullptr;
|
2015-10-02 05:38:24 +08:00
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
2015-01-14 09:05:27 +08:00
|
|
|
/// Emit the language-specific data that __C_specific_handler expects. This
|
|
|
|
/// handler lives in the x64 Microsoft C runtime and allows catching or cleaning
|
|
|
|
/// up after faults with __try, __except, and __finally. The typeinfo values
|
|
|
|
/// are not really RTTI data, but pointers to filter functions that return an
|
|
|
|
/// integer (1, 0, or -1) indicating how to handle the exception. For __finally
|
|
|
|
/// blocks and other cleanups, the landing pad label is zero, and the filter
|
|
|
|
/// function is actually a cleanup handler with the same prototype. A catch-all
|
|
|
|
/// entry is modeled with a null filter function field and a non-zero landing
|
|
|
|
/// pad label.
|
|
|
|
///
|
|
|
|
/// Possible filter function return values:
|
|
|
|
/// EXCEPTION_EXECUTE_HANDLER (1):
|
|
|
|
/// Jump to the landing pad label after cleanups.
|
|
|
|
/// EXCEPTION_CONTINUE_SEARCH (0):
|
|
|
|
/// Continue searching this table or continue unwinding.
|
|
|
|
/// EXCEPTION_CONTINUE_EXECUTION (-1):
|
|
|
|
/// Resume execution at the trapping PC.
|
|
|
|
///
|
|
|
|
/// Inferred table structure:
|
|
|
|
/// struct Table {
|
|
|
|
/// int NumEntries;
|
|
|
|
/// struct Entry {
|
|
|
|
/// imagerel32 LabelStart;
|
|
|
|
/// imagerel32 LabelEnd;
|
2015-01-22 10:27:44 +08:00
|
|
|
/// imagerel32 FilterOrFinally; // One means catch-all.
|
2015-10-10 07:34:53 +08:00
|
|
|
/// imagerel32 LabelLPad; // Zero means __finally.
|
2015-01-14 09:05:27 +08:00
|
|
|
/// } Entries[NumEntries];
|
|
|
|
/// };
|
2015-09-10 05:10:03 +08:00
|
|
|
void WinException::emitCSpecificHandlerTable(const MachineFunction *MF) {
|
2015-10-02 05:38:24 +08:00
|
|
|
auto &OS = *Asm->OutStreamer;
|
|
|
|
MCContext &Ctx = Asm->OutContext;
|
2015-11-18 05:10:25 +08:00
|
|
|
const WinEHFuncInfo &FuncInfo = *MF->getWinEHFuncInfo();
|
2015-12-16 07:40:58 +08:00
|
|
|
|
2015-12-27 14:07:12 +08:00
|
|
|
bool VerboseAsm = OS.isVerboseAsm();
|
|
|
|
auto AddComment = [&](const Twine &Comment) {
|
|
|
|
if (VerboseAsm)
|
|
|
|
OS.AddComment(Comment);
|
|
|
|
};
|
|
|
|
|
2015-12-16 07:40:58 +08:00
|
|
|
// Emit a label assignment with the SEH frame offset so we can use it for
|
|
|
|
// llvm.x86.seh.recoverfp.
|
|
|
|
StringRef FLinkageName =
|
2017-05-16 08:39:01 +08:00
|
|
|
GlobalValue::dropLLVMManglingEscape(MF->getFunction()->getName());
|
2015-12-16 07:40:58 +08:00
|
|
|
MCSymbol *ParentFrameOffset =
|
|
|
|
Ctx.getOrCreateParentFrameOffsetSymbol(FLinkageName);
|
|
|
|
const MCExpr *MCOffset =
|
|
|
|
MCConstantExpr::create(FuncInfo.SEHSetFrameOffset, Ctx);
|
|
|
|
Asm->OutStreamer->EmitAssignment(ParentFrameOffset, MCOffset);
|
|
|
|
|
2015-10-10 07:34:53 +08:00
|
|
|
// Use the assembler to compute the number of table entries through label
|
|
|
|
// difference and division.
|
|
|
|
MCSymbol *TableBegin =
|
|
|
|
Ctx.createTempSymbol("lsda_begin", /*AlwaysAddSuffix=*/true);
|
|
|
|
MCSymbol *TableEnd =
|
|
|
|
Ctx.createTempSymbol("lsda_end", /*AlwaysAddSuffix=*/true);
|
2015-10-14 04:18:27 +08:00
|
|
|
const MCExpr *LabelDiff = getOffset(TableEnd, TableBegin);
|
2015-10-10 07:34:53 +08:00
|
|
|
const MCExpr *EntrySize = MCConstantExpr::create(16, Ctx);
|
|
|
|
const MCExpr *EntryCount = MCBinaryExpr::createDiv(LabelDiff, EntrySize, Ctx);
|
2015-12-27 14:07:12 +08:00
|
|
|
AddComment("Number of call sites");
|
2015-10-10 07:34:53 +08:00
|
|
|
OS.EmitValue(EntryCount, 4);
|
|
|
|
|
|
|
|
OS.EmitLabel(TableBegin);
|
|
|
|
|
|
|
|
// Iterate over all the invoke try ranges. Unlike MSVC, LLVM currently only
|
|
|
|
// models exceptions from invokes. LLVM also allows arbitrary reordering of
|
|
|
|
// the code, so our tables end up looking a bit different. Rather than
|
|
|
|
// trying to match MSVC's tables exactly, we emit a denormalized table. For
|
|
|
|
// each range of invokes in the same state, we emit table entries for all
|
|
|
|
// the actions that would be taken in that state. This means our tables are
|
|
|
|
// slightly bigger, which is OK.
|
2015-10-14 00:44:30 +08:00
|
|
|
const MCSymbol *LastStartLabel = nullptr;
|
|
|
|
int LastEHState = -1;
|
|
|
|
// Break out before we enter into a finally funclet.
|
|
|
|
// FIXME: We need to emit separate EH tables for cleanups.
|
|
|
|
MachineFunction::const_iterator End = MF->end();
|
|
|
|
MachineFunction::const_iterator Stop = std::next(MF->begin());
|
|
|
|
while (Stop != End && !Stop->isEHFuncletEntry())
|
|
|
|
++Stop;
|
|
|
|
for (const auto &StateChange :
|
|
|
|
InvokeStateChangeIterator::range(FuncInfo, MF->begin(), Stop)) {
|
|
|
|
// Emit all the actions for the state we just transitioned out of
|
|
|
|
// if it was not the null state
|
|
|
|
if (LastEHState != -1)
|
|
|
|
emitSEHActionsForRange(FuncInfo, LastStartLabel,
|
|
|
|
StateChange.PreviousEndLabel, LastEHState);
|
|
|
|
LastStartLabel = StateChange.NewStartLabel;
|
|
|
|
LastEHState = StateChange.NewState;
|
2015-10-02 05:38:24 +08:00
|
|
|
}
|
2015-09-10 05:10:03 +08:00
|
|
|
|
2015-10-10 07:34:53 +08:00
|
|
|
OS.EmitLabel(TableEnd);
|
2015-01-14 09:05:27 +08:00
|
|
|
}
|
2015-03-31 06:58:10 +08:00
|
|
|
|
2015-11-18 05:10:25 +08:00
|
|
|
void WinException::emitSEHActionsForRange(const WinEHFuncInfo &FuncInfo,
|
2015-10-14 00:44:30 +08:00
|
|
|
const MCSymbol *BeginLabel,
|
|
|
|
const MCSymbol *EndLabel, int State) {
|
2015-10-10 04:39:39 +08:00
|
|
|
auto &OS = *Asm->OutStreamer;
|
|
|
|
MCContext &Ctx = Asm->OutContext;
|
|
|
|
|
2015-12-27 14:07:12 +08:00
|
|
|
bool VerboseAsm = OS.isVerboseAsm();
|
|
|
|
auto AddComment = [&](const Twine &Comment) {
|
|
|
|
if (VerboseAsm)
|
|
|
|
OS.AddComment(Comment);
|
|
|
|
};
|
|
|
|
|
2015-10-10 04:39:39 +08:00
|
|
|
assert(BeginLabel && EndLabel);
|
|
|
|
while (State != -1) {
|
2015-11-18 05:10:25 +08:00
|
|
|
const SEHUnwindMapEntry &UME = FuncInfo.SEHUnwindMap[State];
|
2015-10-10 04:39:39 +08:00
|
|
|
const MCExpr *FilterOrFinally;
|
|
|
|
const MCExpr *ExceptOrNull;
|
|
|
|
auto *Handler = UME.Handler.get<MachineBasicBlock *>();
|
|
|
|
if (UME.IsFinally) {
|
2015-10-10 08:04:29 +08:00
|
|
|
FilterOrFinally = create32bitRef(getMCSymbolForMBB(Asm, Handler));
|
2015-10-10 04:39:39 +08:00
|
|
|
ExceptOrNull = MCConstantExpr::create(0, Ctx);
|
|
|
|
} else {
|
|
|
|
// For an except, the filter can be 1 (catch-all) or a function
|
|
|
|
// label.
|
|
|
|
FilterOrFinally = UME.Filter ? create32bitRef(UME.Filter)
|
|
|
|
: MCConstantExpr::create(1, Ctx);
|
|
|
|
ExceptOrNull = create32bitRef(Handler->getSymbol());
|
|
|
|
}
|
|
|
|
|
2015-12-27 14:07:12 +08:00
|
|
|
AddComment("LabelStart");
|
2015-10-10 04:39:39 +08:00
|
|
|
OS.EmitValue(getLabelPlusOne(BeginLabel), 4);
|
2015-12-27 14:07:12 +08:00
|
|
|
AddComment("LabelEnd");
|
2015-10-10 04:39:39 +08:00
|
|
|
OS.EmitValue(getLabelPlusOne(EndLabel), 4);
|
2015-12-27 14:07:12 +08:00
|
|
|
AddComment(UME.IsFinally ? "FinallyFunclet" : UME.Filter ? "FilterFunction"
|
|
|
|
: "CatchAll");
|
2015-10-10 04:39:39 +08:00
|
|
|
OS.EmitValue(FilterOrFinally, 4);
|
2015-12-27 14:07:12 +08:00
|
|
|
AddComment(UME.IsFinally ? "Null" : "ExceptionHandler");
|
2015-10-10 04:39:39 +08:00
|
|
|
OS.EmitValue(ExceptOrNull, 4);
|
|
|
|
|
|
|
|
assert(UME.ToState < State && "states should decrease");
|
|
|
|
State = UME.ToState;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-05-29 06:47:01 +08:00
|
|
|
void WinException::emitCXXFrameHandler3Table(const MachineFunction *MF) {
|
2015-03-31 06:58:10 +08:00
|
|
|
const Function *F = MF->getFunction();
|
2015-04-25 03:11:51 +08:00
|
|
|
auto &OS = *Asm->OutStreamer;
|
2015-11-18 05:10:25 +08:00
|
|
|
const WinEHFuncInfo &FuncInfo = *MF->getWinEHFuncInfo();
|
2015-03-31 06:58:10 +08:00
|
|
|
|
2017-05-16 08:39:01 +08:00
|
|
|
StringRef FuncLinkageName = GlobalValue::dropLLVMManglingEscape(F->getName());
|
2015-03-31 06:58:10 +08:00
|
|
|
|
2015-09-29 07:56:30 +08:00
|
|
|
SmallVector<std::pair<const MCExpr *, int>, 4> IPToStateTable;
|
2015-05-30 01:00:57 +08:00
|
|
|
MCSymbol *FuncInfoXData = nullptr;
|
|
|
|
if (shouldEmitPersonality) {
|
2015-09-29 07:56:30 +08:00
|
|
|
// If we're 64-bit, emit a pointer to the C++ EH data, and build a map from
|
|
|
|
// IPs to state numbers.
|
2015-09-17 06:14:46 +08:00
|
|
|
FuncInfoXData =
|
|
|
|
Asm->OutContext.getOrCreateSymbol(Twine("$cppxdata$", FuncLinkageName));
|
2015-09-29 07:56:30 +08:00
|
|
|
computeIP2StateTable(MF, FuncInfo, IPToStateTable);
|
2015-05-30 01:00:57 +08:00
|
|
|
} else {
|
2015-09-17 06:14:46 +08:00
|
|
|
FuncInfoXData = Asm->OutContext.getOrCreateLSDASymbol(FuncLinkageName);
|
2015-03-31 06:58:10 +08:00
|
|
|
}
|
|
|
|
|
2015-10-08 05:13:15 +08:00
|
|
|
int UnwindHelpOffset = 0;
|
|
|
|
if (Asm->MAI->usesWindowsCFI())
|
2015-11-06 05:09:49 +08:00
|
|
|
UnwindHelpOffset =
|
|
|
|
getFrameIndexOffset(FuncInfo.UnwindHelpFrameIdx, FuncInfo);
|
2015-10-08 05:13:15 +08:00
|
|
|
|
2015-03-31 06:58:10 +08:00
|
|
|
MCSymbol *UnwindMapXData = nullptr;
|
|
|
|
MCSymbol *TryBlockMapXData = nullptr;
|
|
|
|
MCSymbol *IPToStateXData = nullptr;
|
2015-10-10 07:34:53 +08:00
|
|
|
if (!FuncInfo.CxxUnwindMap.empty())
|
2015-05-19 02:43:14 +08:00
|
|
|
UnwindMapXData = Asm->OutContext.getOrCreateSymbol(
|
2015-09-17 06:14:46 +08:00
|
|
|
Twine("$stateUnwindMap$", FuncLinkageName));
|
2015-03-31 06:58:10 +08:00
|
|
|
if (!FuncInfo.TryBlockMap.empty())
|
2015-09-17 06:14:46 +08:00
|
|
|
TryBlockMapXData =
|
|
|
|
Asm->OutContext.getOrCreateSymbol(Twine("$tryMap$", FuncLinkageName));
|
2015-09-29 07:56:30 +08:00
|
|
|
if (!IPToStateTable.empty())
|
2015-09-17 06:14:46 +08:00
|
|
|
IPToStateXData =
|
|
|
|
Asm->OutContext.getOrCreateSymbol(Twine("$ip2state$", FuncLinkageName));
|
2015-03-31 06:58:10 +08:00
|
|
|
|
2015-12-27 14:07:12 +08:00
|
|
|
bool VerboseAsm = OS.isVerboseAsm();
|
|
|
|
auto AddComment = [&](const Twine &Comment) {
|
|
|
|
if (VerboseAsm)
|
|
|
|
OS.AddComment(Comment);
|
|
|
|
};
|
|
|
|
|
2015-03-31 06:58:10 +08:00
|
|
|
// FuncInfo {
|
|
|
|
// uint32_t MagicNumber
|
|
|
|
// int32_t MaxState;
|
|
|
|
// UnwindMapEntry *UnwindMap;
|
|
|
|
// uint32_t NumTryBlocks;
|
|
|
|
// TryBlockMapEntry *TryBlockMap;
|
2015-05-30 01:00:57 +08:00
|
|
|
// uint32_t IPMapEntries; // always 0 for x86
|
|
|
|
// IPToStateMapEntry *IPToStateMap; // always 0 for x86
|
|
|
|
// uint32_t UnwindHelp; // non-x86 only
|
2015-03-31 06:58:10 +08:00
|
|
|
// ESTypeList *ESTypeList;
|
|
|
|
// int32_t EHFlags;
|
|
|
|
// }
|
|
|
|
// EHFlags & 1 -> Synchronous exceptions only, no async exceptions.
|
|
|
|
// EHFlags & 2 -> ???
|
|
|
|
// EHFlags & 4 -> The function is noexcept(true), unwinding can't continue.
|
2015-07-10 08:08:49 +08:00
|
|
|
OS.EmitValueToAlignment(4);
|
2015-03-31 06:58:10 +08:00
|
|
|
OS.EmitLabel(FuncInfoXData);
|
2015-12-27 14:07:12 +08:00
|
|
|
|
|
|
|
AddComment("MagicNumber");
|
|
|
|
OS.EmitIntValue(0x19930522, 4);
|
|
|
|
|
|
|
|
AddComment("MaxState");
|
|
|
|
OS.EmitIntValue(FuncInfo.CxxUnwindMap.size(), 4);
|
|
|
|
|
|
|
|
AddComment("UnwindMap");
|
|
|
|
OS.EmitValue(create32bitRef(UnwindMapXData), 4);
|
|
|
|
|
|
|
|
AddComment("NumTryBlocks");
|
|
|
|
OS.EmitIntValue(FuncInfo.TryBlockMap.size(), 4);
|
|
|
|
|
|
|
|
AddComment("TryBlockMap");
|
|
|
|
OS.EmitValue(create32bitRef(TryBlockMapXData), 4);
|
|
|
|
|
|
|
|
AddComment("IPMapEntries");
|
|
|
|
OS.EmitIntValue(IPToStateTable.size(), 4);
|
|
|
|
|
|
|
|
AddComment("IPToStateXData");
|
|
|
|
OS.EmitValue(create32bitRef(IPToStateXData), 4);
|
|
|
|
|
|
|
|
if (Asm->MAI->usesWindowsCFI()) {
|
|
|
|
AddComment("UnwindHelp");
|
|
|
|
OS.EmitIntValue(UnwindHelpOffset, 4);
|
|
|
|
}
|
|
|
|
|
|
|
|
AddComment("ESTypeList");
|
|
|
|
OS.EmitIntValue(0, 4);
|
|
|
|
|
|
|
|
AddComment("EHFlags");
|
|
|
|
OS.EmitIntValue(1, 4);
|
2015-03-31 06:58:10 +08:00
|
|
|
|
|
|
|
// UnwindMapEntry {
|
|
|
|
// int32_t ToState;
|
|
|
|
// void (*Action)();
|
|
|
|
// };
|
|
|
|
if (UnwindMapXData) {
|
|
|
|
OS.EmitLabel(UnwindMapXData);
|
2015-10-10 07:34:53 +08:00
|
|
|
for (const CxxUnwindMapEntry &UME : FuncInfo.CxxUnwindMap) {
|
2015-10-10 08:04:29 +08:00
|
|
|
MCSymbol *CleanupSym =
|
|
|
|
getMCSymbolForMBB(Asm, UME.Cleanup.dyn_cast<MachineBasicBlock *>());
|
2015-12-27 14:07:12 +08:00
|
|
|
AddComment("ToState");
|
|
|
|
OS.EmitIntValue(UME.ToState, 4);
|
|
|
|
|
|
|
|
AddComment("Action");
|
|
|
|
OS.EmitValue(create32bitRef(CleanupSym), 4);
|
2015-03-31 06:58:10 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// TryBlockMap {
|
|
|
|
// int32_t TryLow;
|
|
|
|
// int32_t TryHigh;
|
|
|
|
// int32_t CatchHigh;
|
|
|
|
// int32_t NumCatches;
|
|
|
|
// HandlerType *HandlerArray;
|
|
|
|
// };
|
|
|
|
if (TryBlockMapXData) {
|
|
|
|
OS.EmitLabel(TryBlockMapXData);
|
|
|
|
SmallVector<MCSymbol *, 1> HandlerMaps;
|
|
|
|
for (size_t I = 0, E = FuncInfo.TryBlockMap.size(); I != E; ++I) {
|
2015-11-18 05:10:25 +08:00
|
|
|
const WinEHTryBlockMapEntry &TBME = FuncInfo.TryBlockMap[I];
|
2015-03-31 06:58:10 +08:00
|
|
|
|
2015-09-17 06:14:46 +08:00
|
|
|
MCSymbol *HandlerMapXData = nullptr;
|
2015-03-31 06:58:10 +08:00
|
|
|
if (!TBME.HandlerArray.empty())
|
|
|
|
HandlerMapXData =
|
2015-05-19 02:43:14 +08:00
|
|
|
Asm->OutContext.getOrCreateSymbol(Twine("$handlerMap$")
|
2015-03-31 06:58:10 +08:00
|
|
|
.concat(Twine(I))
|
|
|
|
.concat("$")
|
2015-09-17 06:14:46 +08:00
|
|
|
.concat(FuncLinkageName));
|
2015-03-31 06:58:10 +08:00
|
|
|
HandlerMaps.push_back(HandlerMapXData);
|
|
|
|
|
2015-09-17 06:14:46 +08:00
|
|
|
// TBMEs should form intervals.
|
|
|
|
assert(0 <= TBME.TryLow && "bad trymap interval");
|
|
|
|
assert(TBME.TryLow <= TBME.TryHigh && "bad trymap interval");
|
|
|
|
assert(TBME.TryHigh < TBME.CatchHigh && "bad trymap interval");
|
2015-10-10 07:34:53 +08:00
|
|
|
assert(TBME.CatchHigh < int(FuncInfo.CxxUnwindMap.size()) &&
|
2015-09-17 06:14:46 +08:00
|
|
|
"bad trymap interval");
|
2015-04-04 07:37:34 +08:00
|
|
|
|
2015-12-27 14:07:12 +08:00
|
|
|
AddComment("TryLow");
|
|
|
|
OS.EmitIntValue(TBME.TryLow, 4);
|
|
|
|
|
|
|
|
AddComment("TryHigh");
|
|
|
|
OS.EmitIntValue(TBME.TryHigh, 4);
|
|
|
|
|
|
|
|
AddComment("CatchHigh");
|
|
|
|
OS.EmitIntValue(TBME.CatchHigh, 4);
|
|
|
|
|
|
|
|
AddComment("NumCatches");
|
|
|
|
OS.EmitIntValue(TBME.HandlerArray.size(), 4);
|
|
|
|
|
|
|
|
AddComment("HandlerArray");
|
|
|
|
OS.EmitValue(create32bitRef(HandlerMapXData), 4);
|
2015-03-31 06:58:10 +08:00
|
|
|
}
|
|
|
|
|
2015-10-17 07:43:27 +08:00
|
|
|
// All funclets use the same parent frame offset currently.
|
|
|
|
unsigned ParentFrameOffset = 0;
|
|
|
|
if (shouldEmitPersonality) {
|
|
|
|
const TargetFrameLowering *TFI = MF->getSubtarget().getFrameLowering();
|
|
|
|
ParentFrameOffset = TFI->getWinEHParentFrameOffset(*MF);
|
|
|
|
}
|
|
|
|
|
2015-03-31 06:58:10 +08:00
|
|
|
for (size_t I = 0, E = FuncInfo.TryBlockMap.size(); I != E; ++I) {
|
2015-11-18 05:10:25 +08:00
|
|
|
const WinEHTryBlockMapEntry &TBME = FuncInfo.TryBlockMap[I];
|
2015-03-31 06:58:10 +08:00
|
|
|
MCSymbol *HandlerMapXData = HandlerMaps[I];
|
|
|
|
if (!HandlerMapXData)
|
|
|
|
continue;
|
|
|
|
// HandlerType {
|
|
|
|
// int32_t Adjectives;
|
|
|
|
// TypeDescriptor *Type;
|
|
|
|
// int32_t CatchObjOffset;
|
|
|
|
// void (*Handler)();
|
|
|
|
// int32_t ParentFrameOffset; // x64 only
|
|
|
|
// };
|
|
|
|
OS.EmitLabel(HandlerMapXData);
|
|
|
|
for (const WinEHHandlerType &HT : TBME.HandlerArray) {
|
2015-04-08 03:46:38 +08:00
|
|
|
// Get the frame escape label with the offset of the catch object. If
|
2015-10-13 00:44:22 +08:00
|
|
|
// the index is INT_MAX, then there is no catch object, and we should
|
|
|
|
// emit an offset of zero, indicating that no copy will occur.
|
2015-04-08 03:46:38 +08:00
|
|
|
const MCExpr *FrameAllocOffsetRef = nullptr;
|
2015-10-13 00:44:22 +08:00
|
|
|
if (HT.CatchObj.FrameIndex != INT_MAX) {
|
2015-11-06 05:09:49 +08:00
|
|
|
int Offset = getFrameIndexOffset(HT.CatchObj.FrameIndex, FuncInfo);
|
2016-03-01 12:30:16 +08:00
|
|
|
assert(Offset != 0 && "Illegal offset for catch object!");
|
2015-09-17 04:16:27 +08:00
|
|
|
FrameAllocOffsetRef = MCConstantExpr::create(Offset, Asm->OutContext);
|
2015-04-08 03:46:38 +08:00
|
|
|
} else {
|
2015-05-30 09:25:56 +08:00
|
|
|
FrameAllocOffsetRef = MCConstantExpr::create(0, Asm->OutContext);
|
2015-04-08 03:46:38 +08:00
|
|
|
}
|
2015-04-04 06:49:05 +08:00
|
|
|
|
2015-10-10 08:04:29 +08:00
|
|
|
MCSymbol *HandlerSym =
|
|
|
|
getMCSymbolForMBB(Asm, HT.Handler.dyn_cast<MachineBasicBlock *>());
|
2015-09-10 05:10:03 +08:00
|
|
|
|
2015-12-27 14:07:12 +08:00
|
|
|
AddComment("Adjectives");
|
|
|
|
OS.EmitIntValue(HT.Adjectives, 4);
|
|
|
|
|
|
|
|
AddComment("Type");
|
|
|
|
OS.EmitValue(create32bitRef(HT.TypeDescriptor), 4);
|
|
|
|
|
|
|
|
AddComment("CatchObjOffset");
|
|
|
|
OS.EmitValue(FrameAllocOffsetRef, 4);
|
|
|
|
|
|
|
|
AddComment("Handler");
|
|
|
|
OS.EmitValue(create32bitRef(HandlerSym), 4);
|
|
|
|
|
|
|
|
if (shouldEmitPersonality) {
|
|
|
|
AddComment("ParentFrameOffset");
|
|
|
|
OS.EmitIntValue(ParentFrameOffset, 4);
|
|
|
|
}
|
2015-03-31 06:58:10 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// IPToStateMapEntry {
|
|
|
|
// void *IP;
|
|
|
|
// int32_t State;
|
|
|
|
// };
|
|
|
|
if (IPToStateXData) {
|
|
|
|
OS.EmitLabel(IPToStateXData);
|
2015-09-29 07:56:30 +08:00
|
|
|
for (auto &IPStatePair : IPToStateTable) {
|
2015-12-27 14:07:12 +08:00
|
|
|
AddComment("IP");
|
|
|
|
OS.EmitValue(IPStatePair.first, 4);
|
|
|
|
AddComment("ToState");
|
|
|
|
OS.EmitIntValue(IPStatePair.second, 4);
|
2015-03-31 06:58:10 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2015-05-30 01:00:57 +08:00
|
|
|
|
2015-09-29 07:56:30 +08:00
|
|
|
void WinException::computeIP2StateTable(
|
2015-11-18 05:10:25 +08:00
|
|
|
const MachineFunction *MF, const WinEHFuncInfo &FuncInfo,
|
2015-09-29 07:56:30 +08:00
|
|
|
SmallVectorImpl<std::pair<const MCExpr *, int>> &IPToStateTable) {
|
[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
|
|
|
|
|
|
|
for (MachineFunction::const_iterator FuncletStart = MF->begin(),
|
|
|
|
FuncletEnd = MF->begin(),
|
|
|
|
End = MF->end();
|
|
|
|
FuncletStart != End; FuncletStart = FuncletEnd) {
|
|
|
|
// Find the end of the funclet
|
|
|
|
while (++FuncletEnd != End) {
|
|
|
|
if (FuncletEnd->isEHFuncletEntry()) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Don't emit ip2state entries for cleanup funclets. Any interesting
|
|
|
|
// exceptional actions in cleanups must be handled in a separate IR
|
|
|
|
// function.
|
|
|
|
if (FuncletStart->isCleanupFuncletEntry())
|
|
|
|
continue;
|
|
|
|
|
|
|
|
MCSymbol *StartLabel;
|
|
|
|
int BaseState;
|
|
|
|
if (FuncletStart == MF->begin()) {
|
|
|
|
BaseState = NullState;
|
|
|
|
StartLabel = Asm->getFunctionBegin();
|
|
|
|
} else {
|
|
|
|
auto *FuncletPad =
|
|
|
|
cast<FuncletPadInst>(FuncletStart->getBasicBlock()->getFirstNonPHI());
|
|
|
|
assert(FuncInfo.FuncletBaseStateMap.count(FuncletPad) != 0);
|
|
|
|
BaseState = FuncInfo.FuncletBaseStateMap.find(FuncletPad)->second;
|
|
|
|
StartLabel = getMCSymbolForMBB(Asm, &*FuncletStart);
|
|
|
|
}
|
|
|
|
assert(StartLabel && "need local function start label");
|
2015-10-14 00:44:30 +08:00
|
|
|
IPToStateTable.push_back(
|
[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
|
|
|
std::make_pair(create32bitRef(StartLabel), BaseState));
|
|
|
|
|
|
|
|
for (const auto &StateChange : InvokeStateChangeIterator::range(
|
|
|
|
FuncInfo, FuncletStart, FuncletEnd, BaseState)) {
|
|
|
|
// Compute the label to report as the start of this entry; use the EH
|
|
|
|
// start label for the invoke if we have one, otherwise (this is a call
|
|
|
|
// which may unwind to our caller and does not have an EH start label, so)
|
|
|
|
// use the previous end label.
|
|
|
|
const MCSymbol *ChangeLabel = StateChange.NewStartLabel;
|
|
|
|
if (!ChangeLabel)
|
|
|
|
ChangeLabel = StateChange.PreviousEndLabel;
|
|
|
|
// Emit an entry indicating that PCs after 'Label' have this EH state.
|
|
|
|
IPToStateTable.push_back(
|
|
|
|
std::make_pair(getLabelPlusOne(ChangeLabel), StateChange.NewState));
|
|
|
|
// FIXME: assert that NewState is between CatchLow and CatchHigh.
|
|
|
|
}
|
2015-09-29 07:56:30 +08:00
|
|
|
}
|
2015-05-30 01:00:57 +08:00
|
|
|
}
|
2015-06-10 05:42:19 +08:00
|
|
|
|
2015-07-01 06:46:59 +08:00
|
|
|
void WinException::emitEHRegistrationOffsetLabel(const WinEHFuncInfo &FuncInfo,
|
|
|
|
StringRef FLinkageName) {
|
|
|
|
// Outlined helpers called by the EH runtime need to know the offset of the EH
|
|
|
|
// registration in order to recover the parent frame pointer. Now that we know
|
|
|
|
// we've code generated the parent, we can emit the label assignment that
|
|
|
|
// those helpers use to get the offset of the registration node.
|
2016-10-01 06:10:12 +08:00
|
|
|
|
|
|
|
// Compute the parent frame offset. The EHRegNodeFrameIndex will be invalid if
|
|
|
|
// after optimization all the invokes were eliminated. We still need to emit
|
|
|
|
// the parent frame offset label, but it should be garbage and should never be
|
|
|
|
// used.
|
|
|
|
int64_t Offset = 0;
|
|
|
|
int FI = FuncInfo.EHRegNodeFrameIndex;
|
|
|
|
if (FI != INT_MAX) {
|
|
|
|
const TargetFrameLowering *TFI = Asm->MF->getSubtarget().getFrameLowering();
|
|
|
|
unsigned UnusedReg;
|
|
|
|
Offset = TFI->getFrameIndexReference(*Asm->MF, FI, UnusedReg);
|
|
|
|
}
|
|
|
|
|
2015-11-18 05:10:25 +08:00
|
|
|
MCContext &Ctx = Asm->OutContext;
|
2015-07-01 06:46:59 +08:00
|
|
|
MCSymbol *ParentFrameOffset =
|
2015-11-18 05:10:25 +08:00
|
|
|
Ctx.getOrCreateParentFrameOffsetSymbol(FLinkageName);
|
2016-10-01 06:10:12 +08:00
|
|
|
Asm->OutStreamer->EmitAssignment(ParentFrameOffset,
|
|
|
|
MCConstantExpr::create(Offset, Ctx));
|
2015-07-01 06:46:59 +08:00
|
|
|
}
|
|
|
|
|
2015-06-10 05:42:19 +08:00
|
|
|
/// Emit the language-specific data that _except_handler3 and 4 expect. This is
|
|
|
|
/// functionally equivalent to the __C_specific_handler table, except it is
|
|
|
|
/// indexed by state number instead of IP.
|
|
|
|
void WinException::emitExceptHandlerTable(const MachineFunction *MF) {
|
2015-06-12 06:32:23 +08:00
|
|
|
MCStreamer &OS = *Asm->OutStreamer;
|
2015-06-10 05:42:19 +08:00
|
|
|
const Function *F = MF->getFunction();
|
2017-05-16 08:39:01 +08:00
|
|
|
StringRef FLinkageName = GlobalValue::dropLLVMManglingEscape(F->getName());
|
2015-07-01 06:46:59 +08:00
|
|
|
|
2015-12-27 14:07:12 +08:00
|
|
|
bool VerboseAsm = OS.isVerboseAsm();
|
|
|
|
auto AddComment = [&](const Twine &Comment) {
|
|
|
|
if (VerboseAsm)
|
|
|
|
OS.AddComment(Comment);
|
|
|
|
};
|
|
|
|
|
2015-11-18 05:10:25 +08:00
|
|
|
const WinEHFuncInfo &FuncInfo = *MF->getWinEHFuncInfo();
|
2015-07-01 06:46:59 +08:00
|
|
|
emitEHRegistrationOffsetLabel(FuncInfo, FLinkageName);
|
2015-06-12 06:32:23 +08:00
|
|
|
|
|
|
|
// Emit the __ehtable label that we use for llvm.x86.seh.lsda.
|
2015-06-10 05:42:19 +08:00
|
|
|
MCSymbol *LSDALabel = Asm->OutContext.getOrCreateLSDASymbol(FLinkageName);
|
2015-07-10 08:08:49 +08:00
|
|
|
OS.EmitValueToAlignment(4);
|
2015-06-10 05:42:19 +08:00
|
|
|
OS.EmitLabel(LSDALabel);
|
|
|
|
|
2015-07-14 04:41:46 +08:00
|
|
|
const Function *Per =
|
|
|
|
dyn_cast<Function>(F->getPersonalityFn()->stripPointerCasts());
|
2015-06-10 05:42:19 +08:00
|
|
|
StringRef PerName = Per->getName();
|
|
|
|
int BaseState = -1;
|
|
|
|
if (PerName == "_except_handler4") {
|
|
|
|
// The LSDA for _except_handler4 starts with this struct, followed by the
|
|
|
|
// scope table:
|
|
|
|
//
|
|
|
|
// struct EH4ScopeTable {
|
|
|
|
// int32_t GSCookieOffset;
|
|
|
|
// int32_t GSCookieXOROffset;
|
|
|
|
// int32_t EHCookieOffset;
|
|
|
|
// int32_t EHCookieXOROffset;
|
|
|
|
// ScopeTableEntry ScopeRecord[];
|
|
|
|
// };
|
|
|
|
//
|
[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
|
|
|
// Offsets are %ebp relative.
|
|
|
|
//
|
|
|
|
// The GS cookie is present only if the function needs stack protection.
|
|
|
|
// GSCookieOffset = -2 means that GS cookie is not used.
|
|
|
|
//
|
|
|
|
// The EH cookie is always present.
|
|
|
|
//
|
|
|
|
// Check is done the following way:
|
|
|
|
// (ebp+CookieXOROffset) ^ [ebp+CookieOffset] == _security_cookie
|
|
|
|
|
|
|
|
// Retrieve the Guard Stack slot.
|
|
|
|
int GSCookieOffset = -2;
|
2016-07-29 02:40:00 +08:00
|
|
|
const MachineFrameInfo &MFI = MF->getFrameInfo();
|
|
|
|
if (MFI.hasStackProtectorIndex()) {
|
[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
|
|
|
unsigned UnusedReg;
|
|
|
|
const TargetFrameLowering *TFI = MF->getSubtarget().getFrameLowering();
|
2016-07-29 02:40:00 +08:00
|
|
|
int SSPIdx = MFI.getStackProtectorIndex();
|
[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
|
|
|
GSCookieOffset = TFI->getFrameIndexReference(*MF, SSPIdx, UnusedReg);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Retrieve the EH Guard slot.
|
|
|
|
// TODO(etienneb): Get rid of this value and change it for and assertion.
|
|
|
|
int EHCookieOffset = 9999;
|
|
|
|
if (FuncInfo.EHGuardFrameIndex != INT_MAX) {
|
|
|
|
unsigned UnusedReg;
|
|
|
|
const TargetFrameLowering *TFI = MF->getSubtarget().getFrameLowering();
|
|
|
|
int EHGuardIdx = FuncInfo.EHGuardFrameIndex;
|
|
|
|
EHCookieOffset = TFI->getFrameIndexReference(*MF, EHGuardIdx, UnusedReg);
|
|
|
|
}
|
|
|
|
|
2015-12-27 14:07:12 +08:00
|
|
|
AddComment("GSCookieOffset");
|
[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
|
|
|
OS.EmitIntValue(GSCookieOffset, 4);
|
2015-12-27 14:07:12 +08:00
|
|
|
AddComment("GSCookieXOROffset");
|
2015-06-10 05:42:19 +08:00
|
|
|
OS.EmitIntValue(0, 4);
|
2015-12-27 14:07:12 +08:00
|
|
|
AddComment("EHCookieOffset");
|
[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
|
|
|
OS.EmitIntValue(EHCookieOffset, 4);
|
2015-12-27 14:07:12 +08:00
|
|
|
AddComment("EHCookieXOROffset");
|
2015-06-10 05:42:19 +08:00
|
|
|
OS.EmitIntValue(0, 4);
|
|
|
|
BaseState = -2;
|
|
|
|
}
|
|
|
|
|
2015-10-10 07:34:53 +08:00
|
|
|
assert(!FuncInfo.SEHUnwindMap.empty());
|
2015-11-18 05:10:25 +08:00
|
|
|
for (const SEHUnwindMapEntry &UME : FuncInfo.SEHUnwindMap) {
|
2015-12-27 14:07:12 +08:00
|
|
|
auto *Handler = UME.Handler.get<MachineBasicBlock *>();
|
|
|
|
const MCSymbol *ExceptOrFinally =
|
|
|
|
UME.IsFinally ? getMCSymbolForMBB(Asm, Handler) : Handler->getSymbol();
|
2015-10-10 07:34:53 +08:00
|
|
|
// -1 is usually the base state for "unwind to caller", but for
|
|
|
|
// _except_handler4 it's -2. Do that replacement here if necessary.
|
|
|
|
int ToState = UME.ToState == -1 ? BaseState : UME.ToState;
|
2015-12-27 14:07:12 +08:00
|
|
|
AddComment("ToState");
|
|
|
|
OS.EmitIntValue(ToState, 4);
|
|
|
|
AddComment(UME.IsFinally ? "Null" : "FilterFunction");
|
|
|
|
OS.EmitValue(create32bitRef(UME.Filter), 4);
|
|
|
|
AddComment(UME.IsFinally ? "FinallyFunclet" : "ExceptionHandler");
|
|
|
|
OS.EmitValue(create32bitRef(ExceptOrFinally), 4);
|
2015-06-10 05:42:19 +08:00
|
|
|
}
|
|
|
|
}
|
2015-10-14 04:18:27 +08:00
|
|
|
|
[WinEH] Update CoreCLR EH state numbering
Summary:
Fix the CLR state numbering to generate correct tables, and update the lit
test to verify them.
The CLR numbering assigns one state number to each catchpad and
cleanuppad.
It also computes two tree-like relations over states:
1) Each state has a "HandlerParentState", which is the state of the next
outer handler enclosing this state's handler (same as nearest ancestor
per the ParentPad linkage on EH pads, but skipping over catchswitches).
2) Each state has a "TryParentState", which:
a) for a catchpad that's not the last handler on its catchswitch, is
the state of the next catchpad on that catchswitch.
b) for all other pads, is the state of the pad whose try region is the
next outer try region enclosing this state's try region. The "try
regions are not present as such in the IR, but will be inferred
based on the placement of invokes and pads which reach each other
by exceptional exits.
Catchswitches do not get their own states, but each gets mapped to the
state of its first catchpad.
Table generation requires each state's "unwind dest" state to have a lower
state number than the given state.
Since HandlerParentState can be computed as a function of a pad's
ParentPad, and TryParentState can be computed as a function of its unwind
dest and the TryParentStates of its children, the CLR state numbering
algorithm first computes HandlerParentState in a top-down pass, then
computes TryParentState in a bottom-up pass.
Also reword some comments/names in the CLR EH table generation to make the
distinction between the different kinds of "parent" clear.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: AndyAyers, llvm-commits
Differential Revision: http://reviews.llvm.org/D15325
llvm-svn: 256760
2016-01-05 00:16:01 +08:00
|
|
|
static int getTryRank(const WinEHFuncInfo &FuncInfo, int State) {
|
2015-10-14 04:18:27 +08:00
|
|
|
int Rank = 0;
|
|
|
|
while (State != -1) {
|
|
|
|
++Rank;
|
[WinEH] Update CoreCLR EH state numbering
Summary:
Fix the CLR state numbering to generate correct tables, and update the lit
test to verify them.
The CLR numbering assigns one state number to each catchpad and
cleanuppad.
It also computes two tree-like relations over states:
1) Each state has a "HandlerParentState", which is the state of the next
outer handler enclosing this state's handler (same as nearest ancestor
per the ParentPad linkage on EH pads, but skipping over catchswitches).
2) Each state has a "TryParentState", which:
a) for a catchpad that's not the last handler on its catchswitch, is
the state of the next catchpad on that catchswitch.
b) for all other pads, is the state of the pad whose try region is the
next outer try region enclosing this state's try region. The "try
regions are not present as such in the IR, but will be inferred
based on the placement of invokes and pads which reach each other
by exceptional exits.
Catchswitches do not get their own states, but each gets mapped to the
state of its first catchpad.
Table generation requires each state's "unwind dest" state to have a lower
state number than the given state.
Since HandlerParentState can be computed as a function of a pad's
ParentPad, and TryParentState can be computed as a function of its unwind
dest and the TryParentStates of its children, the CLR state numbering
algorithm first computes HandlerParentState in a top-down pass, then
computes TryParentState in a bottom-up pass.
Also reword some comments/names in the CLR EH table generation to make the
distinction between the different kinds of "parent" clear.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: AndyAyers, llvm-commits
Differential Revision: http://reviews.llvm.org/D15325
llvm-svn: 256760
2016-01-05 00:16:01 +08:00
|
|
|
State = FuncInfo.ClrEHUnwindMap[State].TryParentState;
|
2015-10-14 04:18:27 +08:00
|
|
|
}
|
|
|
|
return Rank;
|
|
|
|
}
|
|
|
|
|
[WinEH] Update CoreCLR EH state numbering
Summary:
Fix the CLR state numbering to generate correct tables, and update the lit
test to verify them.
The CLR numbering assigns one state number to each catchpad and
cleanuppad.
It also computes two tree-like relations over states:
1) Each state has a "HandlerParentState", which is the state of the next
outer handler enclosing this state's handler (same as nearest ancestor
per the ParentPad linkage on EH pads, but skipping over catchswitches).
2) Each state has a "TryParentState", which:
a) for a catchpad that's not the last handler on its catchswitch, is
the state of the next catchpad on that catchswitch.
b) for all other pads, is the state of the pad whose try region is the
next outer try region enclosing this state's try region. The "try
regions are not present as such in the IR, but will be inferred
based on the placement of invokes and pads which reach each other
by exceptional exits.
Catchswitches do not get their own states, but each gets mapped to the
state of its first catchpad.
Table generation requires each state's "unwind dest" state to have a lower
state number than the given state.
Since HandlerParentState can be computed as a function of a pad's
ParentPad, and TryParentState can be computed as a function of its unwind
dest and the TryParentStates of its children, the CLR state numbering
algorithm first computes HandlerParentState in a top-down pass, then
computes TryParentState in a bottom-up pass.
Also reword some comments/names in the CLR EH table generation to make the
distinction between the different kinds of "parent" clear.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: AndyAyers, llvm-commits
Differential Revision: http://reviews.llvm.org/D15325
llvm-svn: 256760
2016-01-05 00:16:01 +08:00
|
|
|
static int getTryAncestor(const WinEHFuncInfo &FuncInfo, int Left, int Right) {
|
|
|
|
int LeftRank = getTryRank(FuncInfo, Left);
|
|
|
|
int RightRank = getTryRank(FuncInfo, Right);
|
2015-10-14 04:18:27 +08:00
|
|
|
|
|
|
|
while (LeftRank < RightRank) {
|
[WinEH] Update CoreCLR EH state numbering
Summary:
Fix the CLR state numbering to generate correct tables, and update the lit
test to verify them.
The CLR numbering assigns one state number to each catchpad and
cleanuppad.
It also computes two tree-like relations over states:
1) Each state has a "HandlerParentState", which is the state of the next
outer handler enclosing this state's handler (same as nearest ancestor
per the ParentPad linkage on EH pads, but skipping over catchswitches).
2) Each state has a "TryParentState", which:
a) for a catchpad that's not the last handler on its catchswitch, is
the state of the next catchpad on that catchswitch.
b) for all other pads, is the state of the pad whose try region is the
next outer try region enclosing this state's try region. The "try
regions are not present as such in the IR, but will be inferred
based on the placement of invokes and pads which reach each other
by exceptional exits.
Catchswitches do not get their own states, but each gets mapped to the
state of its first catchpad.
Table generation requires each state's "unwind dest" state to have a lower
state number than the given state.
Since HandlerParentState can be computed as a function of a pad's
ParentPad, and TryParentState can be computed as a function of its unwind
dest and the TryParentStates of its children, the CLR state numbering
algorithm first computes HandlerParentState in a top-down pass, then
computes TryParentState in a bottom-up pass.
Also reword some comments/names in the CLR EH table generation to make the
distinction between the different kinds of "parent" clear.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: AndyAyers, llvm-commits
Differential Revision: http://reviews.llvm.org/D15325
llvm-svn: 256760
2016-01-05 00:16:01 +08:00
|
|
|
Right = FuncInfo.ClrEHUnwindMap[Right].TryParentState;
|
2015-10-14 04:18:27 +08:00
|
|
|
--RightRank;
|
|
|
|
}
|
|
|
|
|
|
|
|
while (RightRank < LeftRank) {
|
[WinEH] Update CoreCLR EH state numbering
Summary:
Fix the CLR state numbering to generate correct tables, and update the lit
test to verify them.
The CLR numbering assigns one state number to each catchpad and
cleanuppad.
It also computes two tree-like relations over states:
1) Each state has a "HandlerParentState", which is the state of the next
outer handler enclosing this state's handler (same as nearest ancestor
per the ParentPad linkage on EH pads, but skipping over catchswitches).
2) Each state has a "TryParentState", which:
a) for a catchpad that's not the last handler on its catchswitch, is
the state of the next catchpad on that catchswitch.
b) for all other pads, is the state of the pad whose try region is the
next outer try region enclosing this state's try region. The "try
regions are not present as such in the IR, but will be inferred
based on the placement of invokes and pads which reach each other
by exceptional exits.
Catchswitches do not get their own states, but each gets mapped to the
state of its first catchpad.
Table generation requires each state's "unwind dest" state to have a lower
state number than the given state.
Since HandlerParentState can be computed as a function of a pad's
ParentPad, and TryParentState can be computed as a function of its unwind
dest and the TryParentStates of its children, the CLR state numbering
algorithm first computes HandlerParentState in a top-down pass, then
computes TryParentState in a bottom-up pass.
Also reword some comments/names in the CLR EH table generation to make the
distinction between the different kinds of "parent" clear.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: AndyAyers, llvm-commits
Differential Revision: http://reviews.llvm.org/D15325
llvm-svn: 256760
2016-01-05 00:16:01 +08:00
|
|
|
Left = FuncInfo.ClrEHUnwindMap[Left].TryParentState;
|
2015-10-14 04:18:27 +08:00
|
|
|
--LeftRank;
|
|
|
|
}
|
|
|
|
|
|
|
|
while (Left != Right) {
|
[WinEH] Update CoreCLR EH state numbering
Summary:
Fix the CLR state numbering to generate correct tables, and update the lit
test to verify them.
The CLR numbering assigns one state number to each catchpad and
cleanuppad.
It also computes two tree-like relations over states:
1) Each state has a "HandlerParentState", which is the state of the next
outer handler enclosing this state's handler (same as nearest ancestor
per the ParentPad linkage on EH pads, but skipping over catchswitches).
2) Each state has a "TryParentState", which:
a) for a catchpad that's not the last handler on its catchswitch, is
the state of the next catchpad on that catchswitch.
b) for all other pads, is the state of the pad whose try region is the
next outer try region enclosing this state's try region. The "try
regions are not present as such in the IR, but will be inferred
based on the placement of invokes and pads which reach each other
by exceptional exits.
Catchswitches do not get their own states, but each gets mapped to the
state of its first catchpad.
Table generation requires each state's "unwind dest" state to have a lower
state number than the given state.
Since HandlerParentState can be computed as a function of a pad's
ParentPad, and TryParentState can be computed as a function of its unwind
dest and the TryParentStates of its children, the CLR state numbering
algorithm first computes HandlerParentState in a top-down pass, then
computes TryParentState in a bottom-up pass.
Also reword some comments/names in the CLR EH table generation to make the
distinction between the different kinds of "parent" clear.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: AndyAyers, llvm-commits
Differential Revision: http://reviews.llvm.org/D15325
llvm-svn: 256760
2016-01-05 00:16:01 +08:00
|
|
|
Left = FuncInfo.ClrEHUnwindMap[Left].TryParentState;
|
|
|
|
Right = FuncInfo.ClrEHUnwindMap[Right].TryParentState;
|
2015-10-14 04:18:27 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return Left;
|
|
|
|
}
|
|
|
|
|
|
|
|
void WinException::emitCLRExceptionTable(const MachineFunction *MF) {
|
|
|
|
// CLR EH "states" are really just IDs that identify handlers/funclets;
|
|
|
|
// states, handlers, and funclets all have 1:1 mappings between them, and a
|
|
|
|
// handler/funclet's "state" is its index in the ClrEHUnwindMap.
|
|
|
|
MCStreamer &OS = *Asm->OutStreamer;
|
2015-11-18 05:10:25 +08:00
|
|
|
const WinEHFuncInfo &FuncInfo = *MF->getWinEHFuncInfo();
|
2015-10-14 04:18:27 +08:00
|
|
|
MCSymbol *FuncBeginSym = Asm->getFunctionBegin();
|
|
|
|
MCSymbol *FuncEndSym = Asm->getFunctionEnd();
|
|
|
|
|
|
|
|
// A ClrClause describes a protected region.
|
|
|
|
struct ClrClause {
|
|
|
|
const MCSymbol *StartLabel; // Start of protected region
|
|
|
|
const MCSymbol *EndLabel; // End of protected region
|
|
|
|
int State; // Index of handler protecting the protected region
|
|
|
|
int EnclosingState; // Index of funclet enclosing the protected region
|
|
|
|
};
|
|
|
|
SmallVector<ClrClause, 8> Clauses;
|
|
|
|
|
|
|
|
// Build a map from handler MBBs to their corresponding states (i.e. their
|
|
|
|
// indices in the ClrEHUnwindMap).
|
|
|
|
int NumStates = FuncInfo.ClrEHUnwindMap.size();
|
|
|
|
assert(NumStates > 0 && "Don't need exception table!");
|
|
|
|
DenseMap<const MachineBasicBlock *, int> HandlerStates;
|
|
|
|
for (int State = 0; State < NumStates; ++State) {
|
|
|
|
MachineBasicBlock *HandlerBlock =
|
|
|
|
FuncInfo.ClrEHUnwindMap[State].Handler.get<MachineBasicBlock *>();
|
|
|
|
HandlerStates[HandlerBlock] = State;
|
|
|
|
// Use this loop through all handlers to verify our assumption (used in
|
[WinEH] Update CoreCLR EH state numbering
Summary:
Fix the CLR state numbering to generate correct tables, and update the lit
test to verify them.
The CLR numbering assigns one state number to each catchpad and
cleanuppad.
It also computes two tree-like relations over states:
1) Each state has a "HandlerParentState", which is the state of the next
outer handler enclosing this state's handler (same as nearest ancestor
per the ParentPad linkage on EH pads, but skipping over catchswitches).
2) Each state has a "TryParentState", which:
a) for a catchpad that's not the last handler on its catchswitch, is
the state of the next catchpad on that catchswitch.
b) for all other pads, is the state of the pad whose try region is the
next outer try region enclosing this state's try region. The "try
regions are not present as such in the IR, but will be inferred
based on the placement of invokes and pads which reach each other
by exceptional exits.
Catchswitches do not get their own states, but each gets mapped to the
state of its first catchpad.
Table generation requires each state's "unwind dest" state to have a lower
state number than the given state.
Since HandlerParentState can be computed as a function of a pad's
ParentPad, and TryParentState can be computed as a function of its unwind
dest and the TryParentStates of its children, the CLR state numbering
algorithm first computes HandlerParentState in a top-down pass, then
computes TryParentState in a bottom-up pass.
Also reword some comments/names in the CLR EH table generation to make the
distinction between the different kinds of "parent" clear.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: AndyAyers, llvm-commits
Differential Revision: http://reviews.llvm.org/D15325
llvm-svn: 256760
2016-01-05 00:16:01 +08:00
|
|
|
// the MinEnclosingState computation) that enclosing funclets have lower
|
|
|
|
// state numbers than their enclosed funclets.
|
|
|
|
assert(FuncInfo.ClrEHUnwindMap[State].HandlerParentState < State &&
|
2015-10-14 04:18:27 +08:00
|
|
|
"ill-formed state numbering");
|
|
|
|
}
|
|
|
|
// Map the main function to the NullState.
|
2015-10-20 08:36:08 +08:00
|
|
|
HandlerStates[&MF->front()] = NullState;
|
2015-10-14 04:18:27 +08:00
|
|
|
|
|
|
|
// Write out a sentinel indicating the end of the standard (Windows) xdata
|
|
|
|
// and the start of the additional (CLR) info.
|
|
|
|
OS.EmitIntValue(0xffffffff, 4);
|
|
|
|
// Write out the number of funclets
|
|
|
|
OS.EmitIntValue(NumStates, 4);
|
|
|
|
|
|
|
|
// Walk the machine blocks/instrs, computing and emitting a few things:
|
|
|
|
// 1. Emit a list of the offsets to each handler entry, in lexical order.
|
|
|
|
// 2. Compute a map (EndSymbolMap) from each funclet to the symbol at its end.
|
|
|
|
// 3. Compute the list of ClrClauses, in the required order (inner before
|
|
|
|
// outer, earlier before later; the order by which a forward scan with
|
|
|
|
// early termination will find the innermost enclosing clause covering
|
|
|
|
// a given address).
|
|
|
|
// 4. A map (MinClauseMap) from each handler index to the index of the
|
|
|
|
// outermost funclet/function which contains a try clause targeting the
|
|
|
|
// key handler. This will be used to determine IsDuplicate-ness when
|
|
|
|
// emitting ClrClauses. The NullState value is used to indicate that the
|
|
|
|
// top-level function contains a try clause targeting the key handler.
|
|
|
|
// HandlerStack is a stack of (PendingStartLabel, PendingState) pairs for
|
|
|
|
// try regions we entered before entering the PendingState try but which
|
|
|
|
// we haven't yet exited.
|
|
|
|
SmallVector<std::pair<const MCSymbol *, int>, 4> HandlerStack;
|
|
|
|
// EndSymbolMap and MinClauseMap are maps described above.
|
|
|
|
std::unique_ptr<MCSymbol *[]> EndSymbolMap(new MCSymbol *[NumStates]);
|
|
|
|
SmallVector<int, 4> MinClauseMap((size_t)NumStates, NumStates);
|
|
|
|
|
|
|
|
// Visit the root function and each funclet.
|
|
|
|
for (MachineFunction::const_iterator FuncletStart = MF->begin(),
|
|
|
|
FuncletEnd = MF->begin(),
|
|
|
|
End = MF->end();
|
|
|
|
FuncletStart != End; FuncletStart = FuncletEnd) {
|
2015-10-20 08:36:08 +08:00
|
|
|
int FuncletState = HandlerStates[&*FuncletStart];
|
2015-10-14 04:18:27 +08:00
|
|
|
// Find the end of the funclet
|
|
|
|
MCSymbol *EndSymbol = FuncEndSym;
|
|
|
|
while (++FuncletEnd != End) {
|
|
|
|
if (FuncletEnd->isEHFuncletEntry()) {
|
2015-10-20 08:36:08 +08:00
|
|
|
EndSymbol = getMCSymbolForMBB(Asm, &*FuncletEnd);
|
2015-10-14 04:18:27 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
// Emit the function/funclet end and, if this is a funclet (and not the
|
|
|
|
// root function), record it in the EndSymbolMap.
|
|
|
|
OS.EmitValue(getOffset(EndSymbol, FuncBeginSym), 4);
|
|
|
|
if (FuncletState != NullState) {
|
|
|
|
// Record the end of the handler.
|
|
|
|
EndSymbolMap[FuncletState] = EndSymbol;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Walk the state changes in this function/funclet and compute its clauses.
|
|
|
|
// Funclets always start in the null state.
|
|
|
|
const MCSymbol *CurrentStartLabel = nullptr;
|
|
|
|
int CurrentState = NullState;
|
|
|
|
assert(HandlerStack.empty());
|
|
|
|
for (const auto &StateChange :
|
|
|
|
InvokeStateChangeIterator::range(FuncInfo, FuncletStart, FuncletEnd)) {
|
|
|
|
// Close any try regions we're not still under
|
[WinEH] Update CoreCLR EH state numbering
Summary:
Fix the CLR state numbering to generate correct tables, and update the lit
test to verify them.
The CLR numbering assigns one state number to each catchpad and
cleanuppad.
It also computes two tree-like relations over states:
1) Each state has a "HandlerParentState", which is the state of the next
outer handler enclosing this state's handler (same as nearest ancestor
per the ParentPad linkage on EH pads, but skipping over catchswitches).
2) Each state has a "TryParentState", which:
a) for a catchpad that's not the last handler on its catchswitch, is
the state of the next catchpad on that catchswitch.
b) for all other pads, is the state of the pad whose try region is the
next outer try region enclosing this state's try region. The "try
regions are not present as such in the IR, but will be inferred
based on the placement of invokes and pads which reach each other
by exceptional exits.
Catchswitches do not get their own states, but each gets mapped to the
state of its first catchpad.
Table generation requires each state's "unwind dest" state to have a lower
state number than the given state.
Since HandlerParentState can be computed as a function of a pad's
ParentPad, and TryParentState can be computed as a function of its unwind
dest and the TryParentStates of its children, the CLR state numbering
algorithm first computes HandlerParentState in a top-down pass, then
computes TryParentState in a bottom-up pass.
Also reword some comments/names in the CLR EH table generation to make the
distinction between the different kinds of "parent" clear.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: AndyAyers, llvm-commits
Differential Revision: http://reviews.llvm.org/D15325
llvm-svn: 256760
2016-01-05 00:16:01 +08:00
|
|
|
int StillPendingState =
|
|
|
|
getTryAncestor(FuncInfo, CurrentState, StateChange.NewState);
|
|
|
|
while (CurrentState != StillPendingState) {
|
|
|
|
assert(CurrentState != NullState &&
|
|
|
|
"Failed to find still-pending state!");
|
2015-10-14 04:18:27 +08:00
|
|
|
// Close the pending clause
|
|
|
|
Clauses.push_back({CurrentStartLabel, StateChange.PreviousEndLabel,
|
|
|
|
CurrentState, FuncletState});
|
[WinEH] Update CoreCLR EH state numbering
Summary:
Fix the CLR state numbering to generate correct tables, and update the lit
test to verify them.
The CLR numbering assigns one state number to each catchpad and
cleanuppad.
It also computes two tree-like relations over states:
1) Each state has a "HandlerParentState", which is the state of the next
outer handler enclosing this state's handler (same as nearest ancestor
per the ParentPad linkage on EH pads, but skipping over catchswitches).
2) Each state has a "TryParentState", which:
a) for a catchpad that's not the last handler on its catchswitch, is
the state of the next catchpad on that catchswitch.
b) for all other pads, is the state of the pad whose try region is the
next outer try region enclosing this state's try region. The "try
regions are not present as such in the IR, but will be inferred
based on the placement of invokes and pads which reach each other
by exceptional exits.
Catchswitches do not get their own states, but each gets mapped to the
state of its first catchpad.
Table generation requires each state's "unwind dest" state to have a lower
state number than the given state.
Since HandlerParentState can be computed as a function of a pad's
ParentPad, and TryParentState can be computed as a function of its unwind
dest and the TryParentStates of its children, the CLR state numbering
algorithm first computes HandlerParentState in a top-down pass, then
computes TryParentState in a bottom-up pass.
Also reword some comments/names in the CLR EH table generation to make the
distinction between the different kinds of "parent" clear.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: AndyAyers, llvm-commits
Differential Revision: http://reviews.llvm.org/D15325
llvm-svn: 256760
2016-01-05 00:16:01 +08:00
|
|
|
// Now the next-outer try region is current
|
|
|
|
CurrentState = FuncInfo.ClrEHUnwindMap[CurrentState].TryParentState;
|
2015-10-14 04:18:27 +08:00
|
|
|
// Pop the new start label from the handler stack if we've exited all
|
[WinEH] Update CoreCLR EH state numbering
Summary:
Fix the CLR state numbering to generate correct tables, and update the lit
test to verify them.
The CLR numbering assigns one state number to each catchpad and
cleanuppad.
It also computes two tree-like relations over states:
1) Each state has a "HandlerParentState", which is the state of the next
outer handler enclosing this state's handler (same as nearest ancestor
per the ParentPad linkage on EH pads, but skipping over catchswitches).
2) Each state has a "TryParentState", which:
a) for a catchpad that's not the last handler on its catchswitch, is
the state of the next catchpad on that catchswitch.
b) for all other pads, is the state of the pad whose try region is the
next outer try region enclosing this state's try region. The "try
regions are not present as such in the IR, but will be inferred
based on the placement of invokes and pads which reach each other
by exceptional exits.
Catchswitches do not get their own states, but each gets mapped to the
state of its first catchpad.
Table generation requires each state's "unwind dest" state to have a lower
state number than the given state.
Since HandlerParentState can be computed as a function of a pad's
ParentPad, and TryParentState can be computed as a function of its unwind
dest and the TryParentStates of its children, the CLR state numbering
algorithm first computes HandlerParentState in a top-down pass, then
computes TryParentState in a bottom-up pass.
Also reword some comments/names in the CLR EH table generation to make the
distinction between the different kinds of "parent" clear.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: AndyAyers, llvm-commits
Differential Revision: http://reviews.llvm.org/D15325
llvm-svn: 256760
2016-01-05 00:16:01 +08:00
|
|
|
// inner try regions of the corresponding try region.
|
2015-10-14 04:18:27 +08:00
|
|
|
if (HandlerStack.back().second == CurrentState)
|
|
|
|
CurrentStartLabel = HandlerStack.pop_back_val().first;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (StateChange.NewState != CurrentState) {
|
|
|
|
// For each clause we're starting, update the MinClauseMap so we can
|
|
|
|
// know which is the topmost funclet containing a clause targeting
|
|
|
|
// it.
|
|
|
|
for (int EnteredState = StateChange.NewState;
|
|
|
|
EnteredState != CurrentState;
|
[WinEH] Update CoreCLR EH state numbering
Summary:
Fix the CLR state numbering to generate correct tables, and update the lit
test to verify them.
The CLR numbering assigns one state number to each catchpad and
cleanuppad.
It also computes two tree-like relations over states:
1) Each state has a "HandlerParentState", which is the state of the next
outer handler enclosing this state's handler (same as nearest ancestor
per the ParentPad linkage on EH pads, but skipping over catchswitches).
2) Each state has a "TryParentState", which:
a) for a catchpad that's not the last handler on its catchswitch, is
the state of the next catchpad on that catchswitch.
b) for all other pads, is the state of the pad whose try region is the
next outer try region enclosing this state's try region. The "try
regions are not present as such in the IR, but will be inferred
based on the placement of invokes and pads which reach each other
by exceptional exits.
Catchswitches do not get their own states, but each gets mapped to the
state of its first catchpad.
Table generation requires each state's "unwind dest" state to have a lower
state number than the given state.
Since HandlerParentState can be computed as a function of a pad's
ParentPad, and TryParentState can be computed as a function of its unwind
dest and the TryParentStates of its children, the CLR state numbering
algorithm first computes HandlerParentState in a top-down pass, then
computes TryParentState in a bottom-up pass.
Also reword some comments/names in the CLR EH table generation to make the
distinction between the different kinds of "parent" clear.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: AndyAyers, llvm-commits
Differential Revision: http://reviews.llvm.org/D15325
llvm-svn: 256760
2016-01-05 00:16:01 +08:00
|
|
|
EnteredState =
|
|
|
|
FuncInfo.ClrEHUnwindMap[EnteredState].TryParentState) {
|
2015-10-14 04:18:27 +08:00
|
|
|
int &MinEnclosingState = MinClauseMap[EnteredState];
|
|
|
|
if (FuncletState < MinEnclosingState)
|
|
|
|
MinEnclosingState = FuncletState;
|
|
|
|
}
|
|
|
|
// Save the previous current start/label on the stack and update to
|
|
|
|
// the newly-current start/state.
|
|
|
|
HandlerStack.emplace_back(CurrentStartLabel, CurrentState);
|
|
|
|
CurrentStartLabel = StateChange.NewStartLabel;
|
|
|
|
CurrentState = StateChange.NewState;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
assert(HandlerStack.empty());
|
|
|
|
}
|
|
|
|
|
|
|
|
// Now emit the clause info, starting with the number of clauses.
|
|
|
|
OS.EmitIntValue(Clauses.size(), 4);
|
|
|
|
for (ClrClause &Clause : Clauses) {
|
|
|
|
// Emit a CORINFO_EH_CLAUSE :
|
|
|
|
/*
|
|
|
|
struct CORINFO_EH_CLAUSE
|
|
|
|
{
|
|
|
|
CORINFO_EH_CLAUSE_FLAGS Flags; // actually a CorExceptionFlag
|
|
|
|
DWORD TryOffset;
|
|
|
|
DWORD TryLength; // actually TryEndOffset
|
|
|
|
DWORD HandlerOffset;
|
|
|
|
DWORD HandlerLength; // actually HandlerEndOffset
|
|
|
|
union
|
|
|
|
{
|
|
|
|
DWORD ClassToken; // use for catch clauses
|
|
|
|
DWORD FilterOffset; // use for filter clauses
|
|
|
|
};
|
|
|
|
};
|
|
|
|
|
|
|
|
enum CORINFO_EH_CLAUSE_FLAGS
|
|
|
|
{
|
|
|
|
CORINFO_EH_CLAUSE_NONE = 0,
|
|
|
|
CORINFO_EH_CLAUSE_FILTER = 0x0001, // This clause is for a filter
|
|
|
|
CORINFO_EH_CLAUSE_FINALLY = 0x0002, // This clause is a finally clause
|
|
|
|
CORINFO_EH_CLAUSE_FAULT = 0x0004, // This clause is a fault clause
|
|
|
|
};
|
|
|
|
typedef enum CorExceptionFlag
|
|
|
|
{
|
|
|
|
COR_ILEXCEPTION_CLAUSE_NONE,
|
|
|
|
COR_ILEXCEPTION_CLAUSE_FILTER = 0x0001, // This is a filter clause
|
|
|
|
COR_ILEXCEPTION_CLAUSE_FINALLY = 0x0002, // This is a finally clause
|
|
|
|
COR_ILEXCEPTION_CLAUSE_FAULT = 0x0004, // This is a fault clause
|
|
|
|
COR_ILEXCEPTION_CLAUSE_DUPLICATED = 0x0008, // duplicated clause. This
|
|
|
|
// clause was duplicated
|
|
|
|
// to a funclet which was
|
|
|
|
// pulled out of line
|
|
|
|
} CorExceptionFlag;
|
|
|
|
*/
|
|
|
|
// Add 1 to the start/end of the EH clause; the IP associated with a
|
|
|
|
// call when the runtime does its scan is the IP of the next instruction
|
|
|
|
// (the one to which control will return after the call), so we need
|
|
|
|
// to add 1 to the end of the clause to cover that offset. We also add
|
|
|
|
// 1 to the start of the clause to make sure that the ranges reported
|
|
|
|
// for all clauses are disjoint. Note that we'll need some additional
|
|
|
|
// logic when machine traps are supported, since in that case the IP
|
|
|
|
// that the runtime uses is the offset of the faulting instruction
|
|
|
|
// itself; if such an instruction immediately follows a call but the
|
|
|
|
// two belong to different clauses, we'll need to insert a nop between
|
|
|
|
// them so the runtime can distinguish the point to which the call will
|
|
|
|
// return from the point at which the fault occurs.
|
|
|
|
|
|
|
|
const MCExpr *ClauseBegin =
|
|
|
|
getOffsetPlusOne(Clause.StartLabel, FuncBeginSym);
|
|
|
|
const MCExpr *ClauseEnd = getOffsetPlusOne(Clause.EndLabel, FuncBeginSym);
|
|
|
|
|
2015-11-18 05:10:25 +08:00
|
|
|
const ClrEHUnwindMapEntry &Entry = FuncInfo.ClrEHUnwindMap[Clause.State];
|
2015-10-14 04:18:27 +08:00
|
|
|
MachineBasicBlock *HandlerBlock = Entry.Handler.get<MachineBasicBlock *>();
|
|
|
|
MCSymbol *BeginSym = getMCSymbolForMBB(Asm, HandlerBlock);
|
|
|
|
const MCExpr *HandlerBegin = getOffset(BeginSym, FuncBeginSym);
|
|
|
|
MCSymbol *EndSym = EndSymbolMap[Clause.State];
|
|
|
|
const MCExpr *HandlerEnd = getOffset(EndSym, FuncBeginSym);
|
|
|
|
|
|
|
|
uint32_t Flags = 0;
|
|
|
|
switch (Entry.HandlerType) {
|
|
|
|
case ClrHandlerType::Catch:
|
|
|
|
// Leaving bits 0-2 clear indicates catch.
|
|
|
|
break;
|
|
|
|
case ClrHandlerType::Filter:
|
|
|
|
Flags |= 1;
|
|
|
|
break;
|
|
|
|
case ClrHandlerType::Finally:
|
|
|
|
Flags |= 2;
|
|
|
|
break;
|
|
|
|
case ClrHandlerType::Fault:
|
|
|
|
Flags |= 4;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (Clause.EnclosingState != MinClauseMap[Clause.State]) {
|
|
|
|
// This is a "duplicate" clause; the handler needs to be entered from a
|
|
|
|
// frame above the one holding the invoke.
|
|
|
|
assert(Clause.EnclosingState > MinClauseMap[Clause.State]);
|
|
|
|
Flags |= 8;
|
|
|
|
}
|
|
|
|
OS.EmitIntValue(Flags, 4);
|
|
|
|
|
|
|
|
// Write the clause start/end
|
|
|
|
OS.EmitValue(ClauseBegin, 4);
|
|
|
|
OS.EmitValue(ClauseEnd, 4);
|
|
|
|
|
|
|
|
// Write out the handler start/end
|
|
|
|
OS.EmitValue(HandlerBegin, 4);
|
|
|
|
OS.EmitValue(HandlerEnd, 4);
|
|
|
|
|
|
|
|
// Write out the type token or filter offset
|
|
|
|
assert(Entry.HandlerType != ClrHandlerType::Filter && "NYI: filters");
|
|
|
|
OS.EmitIntValue(Entry.TypeToken, 4);
|
|
|
|
}
|
|
|
|
}
|