[PATCH] D31140: [LLVMbugs] [Bug 18710] Only generate .ARM.exidx and .ARM.extab when needed in EHABI

[Christian Bruel via cfe-commits]

Just to add to our comments bellow,

One experiment I did is to use the nounwind/uwtable combination to 
achieve what we need.
e.g:

nounwind                = emit nothing
nounwind uwtable  = emit the .exidx .extab section with the CANTUNWIND

However I gave that up because of tests legacy. e.g

./CodeGen/ARM/ehabi.ll we test :

; (6) .cantunwind directive should be available if the function is 
marked with
;     nounwind function attribute.

So many tests would need to be rewritten as
; (6) .cantunwind directive should be available if the function is 
marked with
;     nounwind uwtable function attributes

So I'm not sure in which extend we can change attribute semantic if this 
implies adapting the regressions tests ?

But if this is acceptable I'm ready to try this... any other opinion ?

Cheers

Christian

Le 03/21/2017 à 09:11 PM, Jonathan Roelofs a écrit :
>
>
> On 3/21/17 1:53 PM, Christian Bruel via Phabricator wrote:
>> chrib added a comment.
>>
>> In https://reviews.llvm.org/D31140#706411, @jroelofs wrote:
>>
>>> Can you clarify the logic here? It's my understanding that:
>>>
>>> `-fno-exceptions` does *not* imply `-fno-unwind-tables`
>>>
>>> however:
>>>
>>> `-fno-unwind-tables` *does* imply that exceptions cannot be used on 
>>> targets that require the tables to do unwinding.
>>
>> Yes, (bad things might happen or (std::terminate will be called, or 
>> destructors not called.)...
>>
>> But -f[no]-unwind-tables implies the UWTable attribute, not NoUwind 
>> attribute. To toggle NoUnwind, use -fno-exceptions
>>
>> And this is getting worse with .canunwind which means DoesNotThrow :)
>>
>> in my understanding,  the logic is as follow:
>>
>> Since "An exception cannot propagate through a function with a 
>> nounwind table. The exception handling runtime environment terminates 
>> the program if it encounters a nounwind table during exception 
>> processing." (ARM Information Center)
>>
>> The "nounwind" LLVM attribute, which means "Function does not throw" 
>> translates as the EXIDX_CANTUNWIND value in the exception table index 
>> table which needs to be created for the purpose (for the function)
>
> I think the problem is here, actually. "nounwind" implies "does not 
> throw", but "does not throw" really should not imply "nounwind". This 
> is something that ought to be clarified in the langref with the 
> addition of a "does not throw" attribute. Then the optimizer should be 
> fixed to deduce "does not throw" instead of "nounwind", and we can let 
> "nounwind" continue to imply .cantunwind.
>
>>
>> And of course without exception runtime environment (the test here) 
>> we don't need this table. So I can see 3 cases:
>>
>> - nounwind set :                    Generate .cantunwind directive 
>> and unwind table
>> - nounwind set but not EH   Do not generate the .cantunwind directive 
>> and do not emit the unwind table
>> - uwtable set                         Need to generate the unwind 
>> table (even without EH)
>>
>> The  disable-arm-cantunwind flag means: without EH support if the 
>> function does not throw, do dot generate the exception tables and the 
>> EXIDX_CANTUNWIND value.
>
> I'm not a big fan of this workaround flag. I'd rather see this fixed 
> by clarifying/fixing the semantics of the IR.
>
>
> Jon
>
>>
>>
>> https://reviews.llvm.org/D31140
>>
>>
>>
>