[cfe-dev] [LLVMdev] Unwind behaviour in Clang/LLVM

[Rafael Espíndola]

> Some careful reader might have noticed the problem here. The nounwind
> attribute is added to @_Z3foov() simply because the landingpad can catch the
> exception object. However, in my notation, only no-throw can be added to
> this function, and no-throw does not imply no-unwind. It is possible for
> @_Z3foov() to unwind the stack. For example, the function @_Z3barv() may
> call _Unwind_Backtrace() to get the backtrace.
>
> Besides, some optimization might make the situation even worse. AFAIK, most
> of the stack unwinding implementations rely on the value in the link
> register or the return address on the stack. However, there is an
> optimization in LLVM code generation which will not save the link register
> if the callee function has noreturn attribute [1].

Can we just call this a bug? I still don't see why we need more than 2
attributes. The semantics being:

* uwtable. We can unwind past this from a debugger or profiler. No
exception handling support guaranteed.
* nounwind. No need to output exception handling support.

In particular, if a function has uwtable, it should be invalid to drop
setting a link register if an ABI requires that for unwinding.

> define void @foo() uwtable nounwind {
> entry:
>   call void @bar()
>   ret void
> }
>
> The stack unwinder might continue to unwind the stack because there isn't
> any mark in the unwind table to stop the stack unwinding. And,
> unfortunately, according to the LLVM reference manual, this will result in
> undefined behavior.

We probably just have to explain better what is undefined behavior.
Passing an exception through this function is. Calling backtrace is
not.

Cheers,
Rafael