[cfe-dev] Unwind, exception handling, debuggers and profilers

[Renato Golin]

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