[PATCH] D124680: [WinEHPrepare] Fix accidental truncation of EH funclets with GNUstep ObjC runtime

[Stefan Gränitz via Phabricator via llvm-commits]

sgraenitz added a comment.

There is a second attempt here, that I am more uncertain about: https://github.com/weliveindetail/llvm-project/commit/93e830eb1b9280d08e3f082b746a8d1343d413ac

However, the behavior of `CodeGenFunction::getBundlesForFunclet()` appears related. It works, because all the relevant ObjC ARC calls will have the "funclet" entry in their bundle list. I had to extend the respective WinEHPrepare condition, because sometimes funclet pads had disappeared (via optimizations I assume?).

I don't fully understand the intended behavior of the existing code and so I can't say which one might be closer to a correct solution (or whether they are both far away).



================
Comment at: llvm/lib/CodeGen/PreISelIntrinsicLowering.cpp:113
+    if (CI->hasFnAttr(Attribute::NoUnwind))
+      NewCI->addFnAttr(Attribute::NoUnwind);
 
----------------
efriedma wrote:
> Are all these functions actually nounwind?  Destroying objects can call into user code.
You mean all intrinsics lowered pre-ISel? Not sure, so far we observed the following ones to trigger truncation and from the IR I looked at they all were all declared nounwind:
objc_destroyWeak, objc_release, objc_retain, objc_retainAutoreleasedReturnValue, objc_storeStrong

Yes destruction likely calls back into user code. In C++ throwing from destructors is undefined behavior. Is that the case in ObjC as well?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D124680/new/

https://reviews.llvm.org/D124680