[PATCH] D86528: [4/5] [MC] [Win64EH] Fill in FuncletOrFuncEnd if missing
Martin Storsjö via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Aug 27 23:46:33 PDT 2020
mstorsjo added inline comments.
================
Comment at: llvm/lib/MC/MCStreamer.cpp:696
+ if (!CurFrame->FuncletOrFuncEnd)
+ CurFrame->FuncletOrFuncEnd = CurFrame->End;
}
----------------
efriedma wrote:
> Instead of setting FuncletOrFuncEnd here, should we be calling EmitWinCFIFuncletOrFuncEnd somewhere?
I don't think so. EmitWinCFIEndProc is essentially called from two places; either from lib/CodeGen/AsmPrinter/WinException.cpp, which also does call EmitWinCFIFuncletOrFuncEnd properly, so there it shouldn't be possible to reach EndProc without FuncletOrFuncEnd being set. The only other case is MC/MCParser/COFFAsmParser.cpp, which has a 1:1 mapping between directives and calling these methods.
================
Comment at: llvm/lib/MC/MCWin64EH.cpp:531
+ // This can happen if unwind info is forced to be generated (with a
+ // .seh_handlerdata directive) directly after the start of the function.
RawFuncLength = 0;
----------------
efriedma wrote:
> With the other changes in this patch, is it still possible for FuncletOrFuncEnd to be null?
Ah, right, yes, it shouldn't be possible. Even if we'd trigger `.seh_handlerdata` immediately, we would have a FuncletOrFuncEnd symbol (with a zero distance from the start), and we'd skip writing this due to it being empty anyway. So we should be able to make this a `report_fatal_error`, as it shouldn't be triggerable even with specially crafted input.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D86528/new/
https://reviews.llvm.org/D86528
More information about the llvm-commits
mailing list