[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