<div dir="ltr"><div><div><div><div><div><div><div><div>Hi Renato,<br><br>> Current behaviour can be simplified by...<br><br></div>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.<br>
<br></div>- no attribute => _____<br></div>- with nounwind attribute => _____</div>- with uwtable attribute => _____</div>- with uwtable+nounwind attribute => _____<br><br>> * just nounwind: emit can't unwind<br>
> * anything else: emit unwind tables<br>
<br></div><div>From your reply, it seems to me that you are suggesting following mapping (correct me if I am wrong.)<br></div><br>- no attribute => emit unwind table<br>- with nounwind attribute => emit cant unwind<br>
- with uwtable attribute => emit unwind table<br>- with uwtable+nounwind attribute => emit unwind table<br><br></div>But what's the difference between the existing behavior?<br><br><br>
>> That's the reason why I said that if the<br>
>> function has uwtable attribute, then we should not emit cantunwind<br>
>> directive.<br>
><br>> This is not about the existence of different tables (thus why I<br>
> rejected Rafael's -arm-eh-tables idea), but the fact that we should<br>
> emit cant-unwind when we have throw() in C++ and we won't need forced<br>
> unwind, such as release binaries with exception handling.<br>
</div><div><br></div><div>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.<br>
<br></div><div>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.<br>
<br><br>
> I never said I don't care about backward compatibility, what I said is<br>> that what's there now is not necessarily correct. This is the<br>> behaviour that the x86_64 ABI demands, but not the ARM ABI, and we<br>

> can't implement the ARM ABI as if it was the x86_64 one.<br>
<br></div><div>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.<br>
<br><br>>> - no attribute => no table generated<br>
>> - with nounwind attribute => no table generated<br>
> Wouldn't the lack of table in a function just break the EH unwind? It<br>
> might be an implementation detail, but I wouldn't be surprised if the<br>
> personality routine would just bail and crash the program if it<br>
> couldn't find the previous frame.<br>
> Ie. I don't think "no tables" == "can't unwind table".<br>
<br></div><div>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.<br><br></div><div><br></div><div>Sincerely,<br>Logan<br>

</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 24, 2014 at 12:53 AM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 23 March 2014 16:37, Logan Chien <<a href="mailto:tzuhsiang.chien@gmail.com">tzuhsiang.chien@gmail.com</a>> wrote:<br>

>> Based on the current behaviour, you only need one flag: nounwind,<br>
>> which should only be emitted if -fno-unwind-tables is chosen AND the<br>
>> function can't unwind.<br>
><br>
> I don't quite understand what do you mean here.<br>
<br>
</div>Current behaviour can be simplified by:<br>
<br>
* just nounwind: emit can't unwind<br>
* anything else: emit unwind tables<br>
<br>
Since you have only two states, a single boolean flag is enough to<br>
represent them.<br>
<div class=""><br>
<br>
> That's the reason why I said that if the<br>
> function has uwtable attribute, then we should not emit cantunwind<br>
> directive.<br>
<br>
</div>This is not about the existence of different tables (thus why I<br>
rejected Rafael's -arm-eh-tables idea), but the fact that we should<br>
emit cant-unwind when we have throw() in C++ and we won't need forced<br>
unwind, such as release binaries with exception handling.<br>
<div class=""><br>
<br>
> If you don't care about the backward compatibility at LLVM assembly level at<br>
> all, then the simplest solution is to determine whether we should generate<br>
> unwind table by the existence of the uwtable function attribute.<br>
<br>
</div>I never said I don't care about backward compatibility, what I said is<br>
that what's there now is not necessarily correct. This is the<br>
behaviour that the x86_64 ABI demands, but not the ARM ABI, and we<br>
can't implement the ARM ABI as if it was the x86_64 one.<br>
<div class=""><br>
<br>
> - no attribute => no table generated<br>
> - with nounwind attribute => no table generated<br>
<br>
</div>Wouldn't the lack of table in a function just break the EH unwind? It<br>
might be an implementation detail, but I wouldn't be surprised if the<br>
personality routine would just bail and crash the program if it<br>
couldn't find the previous frame.<br>
<br>
Ie. I don't think "no tablles" == "can't unwind table".<br>
<div class=""><br>
<br>
<br>
> BUT, this means that all of the front-ends should be updated if they was not<br>
> emitting uwtable attribute.  I am afraid that this won't be a viable<br>
> solution.<br>
<br>
</div>The whole point was to change the semantics of the function attributes<br>
uwtable and nounwind.<br>
<br>
If this is out of the question, than this whole discussion is moot and<br>
we should just force the x86_64 ABI on all EH targets, ie. always emit<br>
the tables regardless of the attributes. And this is exactly how it is<br>
now, so there's nothing to change.<br>
<br>
cheers,<br>
--renato<br>
</blockquote></div><br></div>