llvm dev - Dec 2021 - 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:
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.

Thanks,
Chuanqi
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211201/152f7c41/attachment.html>

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?



On Wed, Dec 1, 2021 at 2:36 AM chuanqi.xcq via cfe-dev <
cfe-dev at lists.llvm.org> 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.
>
> Thanks,
> Chuanqi
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211201/1dd61846/attachment.html>

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/20211201/8a50df66/attachment.html>