What's the difference between llvm `resume` instruction and `__cxa_rethrow`?

Hi,

Recently I am checking the implementation of c++20 coroutine in clang and I am wondering if it is possible to mark its status as complete.
(Now the status is partial althought it’s been a while that the clang’s coroutine is used in production).

Here is the simple introduction, in the standard: [dcl.fct.def.coroutine], it says both initial_suspend().await_ready()
and initial_suspend().await_suspend() should be wrapped in try statement and if there is an exception happens, it would be rethown by
throw; statement. It may look like:

try {
auto init_suspend = promise.init_suspend();
if (!init_suspend.await_ready())
init_suspend.await_suspend();
} catch (...) {
throw;
}

And the implementation didn’t wrap them in try...catch statement. The code generated by clang would look like:

invoke promise.init_suspend()
to label %cont unwind label %lpad

invoke init_suspend.await_ready()
to label %cont1 unwind label %lpad1

invoke init_suspend.await_suspend()
to label %cont2 unwind label %lpad2
...
%lpad:
...
br label %eh.resume
%lpad1:
...
br label %eh.resume
%lpad2:
...
br label %eh.resume
eh.resume:
....
resume

And I know that clang would generate __cxa_rethrow for throw;. I did some simple test locally, the behavior now looks
good for me. (I could catch the exception in the caller of the coroutine). But I think it would be better to consult with the experts.
I am wondering what’s the difference and if it would be a block issue for conforming clang’s implementation.

Thanks,
Chuanqi

These are indeed different things: IR “resume” is for continuing an existing in-progress unwind, while “throw;” (aka “call @__cxa_rethrow”) starts a brand new unwind to find a new catch location – just using the same exception object.

Thus, you can only use resume to continue on from an intermediate cleanup. Once you’ve entered a landingpad having a exception type matching the “catch” clause, you can no longer resume. See also https://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html – noting that IR “resume” ends up as a call to “_Unwind_resume”.

Yet, it seems unlikely that Clang is actually getting the above incorrect – do you have a more complete test-case you think might be wrong?

The landing pad is a region of the containing function, but really, in terms of its interactions with the unwinder, it’s important to think of it almost as if it were a separate function that’s “called” by the unwinder, with certain expected preconditions on entry and postconditions on “exit”, where the “exits” are various calls back into the unwinder. Those pre/post-conditions are determined by the associated EH table and the exception selector. Specifically:

  • If the landing pad wants to be able to handle an exception, it needs the EH table for the covered region that leads to the landing pad to include an appropriate catch clause.
  • If the EH selector corresponds to a catch clause, the landing pad is supposed to actually handle the exception before exiting.
  • The landing pad handles an exception by calling the appropriate language routine for it, e.g. __cxa_begin_catch.
  • Calling __cxa_begin_catch creates an additional requirement that the landing pad will call __cxa_end_catch to exit. This call is an exit from the landing pad.
  • If the EH selector corresponds to “just run cleanups”, the landing pad must not attempt to handle the exception and must eventually call _Unwind_Resume.

The resume instruction continues unwinding when you haven’t handled an exception yet. Normally, it is run at the end of the landing pad after it’s checked for all of the exceptions that are caught there, so we know we’re not handling an exception, so it just turns into a call to _Unwind_Resume. But in order to satisfy the requirements above, the inliner has to potentially merge landing pads in the caller and callee. That means both (1) combining the EH entries for call sites in the inlined function with the EH entries for the inlined call site and (2) making the landing pads for the inlined function flow into the landing pad for the call site. As a result, resume in the callee flows to the landing pad for the caller’s call site, which might then handle other exceptions.

__cxa_rethrow has to be called while an exception is handled and doesn’t itself exit the landing pad. There’s supposed to be a cleanup to call __cxa_end_catch whenever you’re inside a catch block.

So it depends on what’s in the ellipses, but I believe this code is invalid, and landing pads are not supposed to do a resume when they’ve said they’re going to catch.

I assume the actual source code you’re processing doesn’t literally have a catch (...) { throw; }, and instead it calls some function that might do a throw;?

John.

Hi John,

Many thanks for your explanation of Exception Handling!

So it depends on what’s in the ellipses, but I believe this code is invalid, and landing pads are not supposed to do a resume when they’ve said they’re going to catch.

I assume the actual source code you’re processing doesn’t literally have a catch (...) { throw; }, and instead it calls some function that might do a throw;?

I guess I didn’t make things clear (or I misunderstood you). I think the code I posted might be valid. Here is my rational. First in [dcl.fct.def.coroutine],
it says the coroutine should be expanded into

{
promise-type promise promise-constructor-arguments ;
try {
co_await promise.initial_suspend() ;
function-body
} catch ( ... ) {
if (!initial-await-resume-called)
throw ;
promise.unhandled_exception() ;
}
final-suspend :
co_await promise.final_suspend() ;
}

Here initial-await-resume-called is initially false and is set to true immediately before the co-await-resume expression of the initial suspend.
So I understand the try-catch part of the codes above is equivalent to:

try {
auto init_awaiter = promise.initial_suspend();
if (!init_awaiter.await_ready())
init_awaiter.await_suspend();
} catch (...) {
throw; // throw anything the catch captured.
}
try {
init_awaiter.await_resume();
function-body
} catch(...) {
promise.unhandled_exception() ;
}

BTW, the code generated in clang now looks like:


// This is not captured by try-catch!

auto init_awaiter = promise.initial_suspend();
if (!init_awaiter.await_ready())
init_awaiter.await_suspend();
try {
init_awaiter.await_resume();

function-body

} catch(...) {
promise.unhandled_exception() ;
}

So it depends on what’s in the ellipses

Could I think that if there is nothing is elipses (catches all exceptions), then the behavior should be same?

Hi James,

Thanks for your explanation. So the different between resume and __cxa_rethrow should be the place they are used, right?

Yet, it seems unlikely that Clang is actually getting the above incorrect – do you have a more complete test-case you think might be wrong?

No, I don’t think the behavior is wrong. I just want to make sure if the behavior of clang is consistent with the standard.

The behavior now looks good to me from my simple test: Compiler Explorer. I could catch the exception from the caller.

I just found that the LLVM IR generated looks inconsistency with what I imaged. I image that it should generate __cxa_rethrow but it

generate resume actually. So I send this mail.

From the discussion above, it looks like this wouldn’t be a block issue to announce clang’s implementation for coroutine is conformed

(I know there are other issues)

Thanks,

Chuanqi

I mean that the generated IR is incorrect because, to correspond to that source code, it needs to be rethrowing within a catch body instead of simply resuming. That’s what I thought you were asking about.

Frankly, I just assumed the structure of your generated coroutine body was correct, or correct enough to show the intent.

John.

Oh, I got it now. Now there shouldn’t be misunderstanding.

Many Thanks,
Chuanqi