[cfe-dev] What's the difference between llvm `resume` instruction and `__cxa_rethrow`?

[chuanqi.xcq via cfe-dev]

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 https://eel.is/c++draft/dcl.fct.def.coroutine#5,
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: https://godbolt.org/z/8j4bce9jd. 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



------------------------------------------------------------------
From:John McCall <rjmccall at apple.com>
Send Time:2021年12月2日(星期四) 05:38
To:chuanqi.xcq <yedeng.yd at linux.alibaba.com>
Cc:llvm-dev <llvm-dev at lists.llvm.org>; clang developer list <cfe-dev at lists.llvm.org>; "Fāng-ruì Sòng" <maskray at google.com>
Subject:Re: What's the difference between llvm `resume` instruction and `__cxa_rethrow`?

On 1 Dec 2021, at 2:36, chuanqi.xcq wrote:
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: https://eel.is/c++draft/dcl.fct.def.coroutine#5, 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:

 ```C++
 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:

 ```LLVM
 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.
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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20211202/09a07a89/attachment-0001.html>