llvm dev - Dec 2021 - What's the difference between llvm `resume` instruction and `__cxa_rethrow`?

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/llvm-dev/attachments/20211202/09a07a89/attachment.html>

On 1 Dec 2021, at 22:00, chuanqi.xcq wrote:
> 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.
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.