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

Rafael EspĂ­ndola rafael.espindola at gmail.com
Tue Feb 18 05:54:50 PST 2014


> 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



More information about the cfe-dev mailing list