[PATCH] D125645: [ARM SEH 3] [ARM] [MC] Add support for writing ARM WinEH unwind info
Martin Storsjö via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu May 19 00:31:46 PDT 2022
mstorsjo added inline comments.
================
Comment at: llvm/lib/MC/MCWin64EH.cpp:1431
+ streamer.emitValue(
+ MCBinaryExpr::createOr(FuncLengthExpr,
+ MCConstantExpr::create(row1, context), context),
----------------
efriedma wrote:
> mstorsjo wrote:
> > efriedma wrote:
> > > mstorsjo wrote:
> > > > How do I make this into an ARM specific fixup, which could do range checking for `FuncLengthExpr` and error out if the function is too long?
> > > See llvm/lib/Target/ARM/MCTargetDesc/ARMMCExpr.h.
> > >
> > > I'd prefer not to put any substantial effort into infrastructure we won't need if we implement splitting, though. Zhaoshi is currently looking into that.
> > Oh, ok. Sure, I'll stop worrying about that aspect then! (As I've never hit that limit in practice on ARM64 so far, I'm not very worried about it for ARM either. But for implementing splitting, the fact that ARM functions often won't have their length fixed at this point might be problematic...)
> If we need to, we can put off emitting the unwind info until the layout is fixed. See the giant FIXME near the beginning of ARM64EmitUnwindInfo.
Ah, I see! (I've read it a couple times before but never really confidently understood all the alternatives - but now I think I get the part about a relaxable fragment too).
Anyway, the current code should be fine for practical cases here, and whenever we get support for delaying emitting the unwind info for ARM64, we can apply the same to ARM too.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D125645/new/
https://reviews.llvm.org/D125645
More information about the llvm-commits
mailing list