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

[Logan Chien]

Hi Renato,

> Current behaviour can be simplified by...

I am slightly confused by your goal.  What are you trying to achieve?  It
will be good to fill in the following table so that we can have some common
basis for discussion.

- no attribute => _____
- with nounwind attribute => _____
- with uwtable attribute => _____
- with uwtable+nounwind attribute => _____

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

>From your reply, it seems to me that you are suggesting following mapping
(correct me if I am wrong.)

- no attribute => emit unwind table
- with nounwind attribute => emit cant unwind
- with uwtable attribute => emit unwind table
- with uwtable+nounwind attribute => emit unwind table

But what's the difference between the existing behavior?


>> 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.

IIRC, the C++ "throw ()" does not imply "we won't need forced unwind".  Is
there any document (or existing implementation) mandating this?  Usually,
Clang stops the stack unwinder by catching all exception with landingpad
instruction, which is not directly related to nounwind attribute.  Thus,
IMO, there won't be any problem to ignore cantunwind in the
"uwtable+nounwind" case.

Furthermore, it will be incorrect to emit "cantunwind" in the
"uwtable+nounwind" case, since all of the C functions will get nouwind
attribute by default.  To get the program work with exception, we will add
-funwind-tables option to Clang, which will emit uwtable as well.  If you
emit cantunwind in "uwtable+nounwind" case, then the exception unwinder
will always stop at the C function.


> 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.

Sorry for my wordings.  I am only trying to propose a possible solution
which may break the backward compatibility.  I should use the sentence like
"If the backward compatibility is not a main concern, ..."  I apologize if
you feel offensive.


>> - 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 tables" == "can't unwind table".

IIRC, they will be the same in the libgcc implementation, and it seems to
be specified in EHABI.  Although, I can't find the source code at the
moment.


Sincerely,
Logan


On Mon, Mar 24, 2014 at 12:53 AM, Renato Golin <renato.golin at linaro.org>wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140326/0cd4f560/attachment.html>