zmodem wrote: > Re: sroa/mem2reg, that's a valid concern with Hans's intrinsic approach.
Is it still a concern in the latest version, which makes mem2reg aware of the intrinsic? I don't have a good feel for whether putting a flag on `AllocaInst` or using an intrinsic is less disruptive. Happy to take input on that one. > Going back to the beginning, why do we end up in a UAF situation? IIUC, the > ramp function should do the following: > * store the bytes of the trivial abi argument into an alloca > * call the move ctor into the coro frame > * co_return > * destroy the coro frame objects, matching the move ctor call > * destroy the alloca, matching the construction from earlier in the caller > > What is coro split doing that breaks this? It sounds like it's rewriting the > second destructor to destroy the variable in the frame, but that's incorrect. The problem is that the "parameter alloca" (first bullet point) incorrectly gets "promoted" to the coroutine frame. CoroSplit assumes it may be accessed across suspension points (I think it has to, as the address escapes via the "src" argument in the move ctor call). > What's different between the case where we suspend and the case where there > are no suspend points? The parameter's destructor runs at the end of the ramp function (last bullet point). If we're suspending, the coro frame is still alive at this point (for use when resuming). If the coro finished without suspending, the coro frame has been destroyed at this point, and we get UAF. https://github.com/llvm/llvm-project/pull/127653 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
