llvm dev - Mar 2014 - [LLVMdev] Unwind, exception handling, debuggers and profilers

On 21 March 2014 18:47, Logan Chien <tzuhsiang.chien at gmail.com>
wrote:
> * There's the table for ARM target:
>
> - no attribute => emit unwind table
> - with nounwind => emit unwind table with cantunwind
> - with uwtable => emit unwind table
> - with uwtable+nounwind => emit unwind table WITHOUT the cantunwind
>
> The cantunwind record will stop the unwinder, and cantunwind will conflict
> with the stack unwind information according to EHABI.  Thus, we should not
> emit cantunwind for the function with uwtable.
Logan,

Based on the current behaviour, you only need one flag: nounwind,
which should only be emitted if -fno-unwind-tables is chosen AND the
function can't unwind.

Also, do not assume that EHABI behaviour in LLVM is currently correct,
especially related to uwtable and nounwind. Those were made with the
x86_64's ABI in mind, and have only interoperated seriously with
DwarfCFIException until very recently.

There has to be a way to disable unwind tables, so either the "no
attribute" behaviour above is wrong or we need a new attribute
"noehtable".

There has to be a way to emit CantUnwind, so if the behaviour above is
right, the "uwtables" attribute is only related to forced unwind
(debug, profiler), not exception handling.

There has to be a way to map "throw()" into IR, and
"nounwind" seems
to be the one to use. The fact that CantUnwind is only emitted without
"uwtable" reinforces the idea that "uwtable" is forced
unwind.

cheers,
--renato

Hi Renato,
> Based on the current behaviour, you only need one flag: nounwind,
> which should only be emitted if -fno-unwind-tables is chosen AND the
> function can't unwind.
I don't quite understand what do you mean here.

I was trying to say: due to the design of .ARM.exidx, you won't be possible
to emit both the cantunwind directive and the stack unwinding information
at the same time (they share the same word.)  Thus, if -funwind-tables is
available, then we should ignore the nounwind attribute.  Otherwise, the
force unwind simply won't work.  That's the reason why I said that if
the
function has uwtable attribute, then we should not emit cantunwind
directive.

> There has to be a way to disable unwind tables, so either the "no
> attribute" behaviour above is wrong or we need a new attribute
> "noehtable".
IMO, `noehtable` attribute won't solve the issue.  In my article, I was
using ehtable to provide the guarantee of the information to
throw-and-catch the exception, but you are using in the converse way.  In
fact, uwtable and ehtable means almost the SAME table in ARM EHABI (except
the LSDA.)

Furthermore, no exception handling table (LSDA) will be generated for the
functions without the landingpad instruction, even -funwind-tables are
given.  IMO, adding `noehtable` attribute won't reach your goal to remove
the unnecessary unwind table.

> Also, do not assume that EHABI behaviour in LLVM is currently correct,
> especially related to uwtable and nounwind. Those were made with the
> x86_64's ABI in mind, and have only interoperated seriously with
> DwarfCFIException until very recently.
If you don't care about the backward compatibility at LLVM assembly level
at all, then the simplest solution is to determine whether we should
generate unwind table by the existence of the uwtable function attribute.
The result should be:

- no attribute => no table generated
- with nounwind attribute => no table generated
- with uwtable attribute => generate unwind table (with LSDA)
- with uwtable+nounwind attribute => generate unwind table (without
cantunwind)

This combination will work (including the interleaving of C and C++
programs).  The will be only a little difference when the function really
throws an exception and the front-end did not generate the landingpad
instruction.  Since clang will transform "throw ()" or
"noexpect(true)" to:

define void @_Z3foov() nounwind {
  invoke void @_Z9may_throwv() to label %1 unwind label
%2

; <label>:1
  ret void

; <label>:2
  %3 = landingpad { i8*, i32 } personality i8* bitcast (i32 (...)*
@__gxx_personality_v0 to i8*)
          filter [0 x i8*] zeroinitializer
  %4 = extractvalue { i8*, i32 } %3, 0
  tail call void @__cxa_call_unexpected(i8* %4)
  unreachable
}

The landingpad instruction will be emitted to catch every exceptions, and
call __cxa_call_unexpected() to stop the unwinding procedure.

BUT, this means that all of the front-ends should be updated if they was
not emitting uwtable attribute.  I am afraid that this won't be a viable
solution.

Best regards,
Logan

# Footnote
[1] To be precise, one additional word will be emit to mark the absence of
LSDA but this word should be emitted anyway.


On Sat, Mar 22, 2014 at 3:07 AM, Renato Golin <renato.golin at
linaro.org>wrote:
> On 21 March 2014 18:47, Logan Chien <tzuhsiang.chien at gmail.com>
wrote:
> > * There's the table for ARM target:
> >
> > - no attribute => emit unwind table
> > - with nounwind => emit unwind table with cantunwind
> > - with uwtable => emit unwind table
> > - with uwtable+nounwind => emit unwind table WITHOUT the cantunwind
> >
> > The cantunwind record will stop the unwinder, and cantunwind will
> conflict
> > with the stack unwind information according to EHABI.  Thus, we should
> not
> > emit cantunwind for the function with uwtable.
>
> Logan,
>
> Based on the current behaviour, you only need one flag: nounwind,
> which should only be emitted if -fno-unwind-tables is chosen AND the
> function can't unwind.
>
> Also, do not assume that EHABI behaviour in LLVM is currently correct,
> especially related to uwtable and nounwind. Those were made with the
> x86_64's ABI in mind, and have only interoperated seriously with
> DwarfCFIException until very recently.
>
> There has to be a way to disable unwind tables, so either the "no
> attribute" behaviour above is wrong or we need a new attribute
> "noehtable".
>
> There has to be a way to emit CantUnwind, so if the behaviour above is
> right, the "uwtables" attribute is only related to forced unwind
> (debug, profiler), not exception handling.
>
> There has to be a way to map "throw()" into IR, and
"nounwind" seems
> to be the one to use. The fact that CantUnwind is only emitted without
> "uwtable" reinforces the idea that "uwtable" is forced
unwind.
>
> cheers,
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140324/4d22f81e/attachment.html>

On 23 March 2014 16:37, Logan Chien <tzuhsiang.chien at gmail.com>
wrote:
>> Based on the current behaviour, you only need one flag: nounwind,
>> which should only be emitted if -fno-unwind-tables is chosen AND the
>> function can't unwind.
>
> I don't quite understand what do you mean here.
Current behaviour can be simplified by:

* just nounwind: emit can't unwind
* anything else: emit unwind tables

Since you have only two states, a single boolean flag is enough to
represent them.

> That's the reason why I said that if the
> function has uwtable attribute, then we should not emit cantunwind
> directive.
This is not about the existence of different tables (thus why I
rejected Rafael's -arm-eh-tables idea), but the fact that we should
emit cant-unwind when we have throw() in C++ and we won't need forced
unwind, such as release binaries with exception handling.

> If you don't care about the backward compatibility at LLVM assembly
level at
> all, then the simplest solution is to determine whether we should generate
> unwind table by the existence of the uwtable function attribute.
I never said I don't care about backward compatibility, what I said is
that what's there now is not necessarily correct. This is the
behaviour that the x86_64 ABI demands, but not the ARM ABI, and we
can't implement the ARM ABI as if it was the x86_64 one.

> - no attribute => no table generated
> - with nounwind attribute => no table generated
Wouldn't the lack of table in a function just break the EH unwind? It
might be an implementation detail, but I wouldn't be surprised if the
personality routine would just bail and crash the program if it
couldn't find the previous frame.

Ie. I don't think "no tablles" == "can't unwind
table".


> BUT, this means that all of the front-ends should be updated if they was
not
> emitting uwtable attribute.  I am afraid that this won't be a viable
> solution.
The whole point was to change the semantics of the function attributes
uwtable and nounwind.

If this is out of the question, than this whole discussion is moot and
we should just force the x86_64 ABI on all EH targets, ie. always emit
the tables regardless of the attributes. And this is exactly how it is
now, so there's nothing to change.

cheers,
--renato