https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94794
--- Comment #4 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Andrew Pinski from comment #3) > I wonder if this could be described as a thunk. My mental image is more of a trampoline.. .. since the fundamental issue is that some ABIs need registers updated for cross-DSO calls (e.g. TOC or secure plt). Since the indirect call always has access to the frame pointer, we already have somewhere to stash the necessary data (which is always associated with the context that created the frame).. so my sketch is to set aside some space before the current resume/destroy pointers - and to define a built-in that the target can define to say if/how much space is needed. The data is then (like the resume/destroy and promise) always at a Well Known offset from the frame pointer, which is always available to the calls (since the call is an indirect call through the frame pointer - which points to the resume(frame*) function). The resume would then become a call to a __builtin_resume() which would resolve to nothing on platforms that can do indirect tail calls, and to the trampoline in the case of those that need it. The signature of the resume builtin would be void __builtin_resume (frame*) [i.e. identical to the call]. No code so far, just thinking aloud - and this needs to be discussed with the clang folks so that we end up with an ABI that supports resuming coroutines built by either compiler.
