llvm dev - Dec 2014 - [LLVMdev] [cfe-dev] Question about '-fno-exceptions' option and 'ExceptionsType' on MCAsmInfo with ARM.

Hi all

I have a question about the '-fno-exceptions' option with clang and 
'ExceptionsType' on MCAsmInfo.

I am looking for a way to avoid generating stack unwinding codes when 
compiling with the "armv7-none-linux-gnu" triple using clang. I tried 
the '-fno-exceptions' option in order to do that, but unwinding function
symbols like '__aeabi_unwind_cpp_pr0' were still present. I think 
'ExceptionType' of MCAsmInfo is set to ExceptionType::ARM with the above
target triple and it is not affected by the '-fno-exceptions' option. Am
I missing something about this, or do we need to provide an interface to 
disable generation of exception codes?

Thanks,
JinGu Kang

On 8 December 2014 at 06:33, JinGu Kang <jingu at codeplay.com>
wrote:
> Hi all
>
> I have a question about the '-fno-exceptions' option with clang and
> 'ExceptionsType' on MCAsmInfo.
>
> I am looking for a way to avoid generating stack unwinding codes when
> compiling with the "armv7-none-linux-gnu" triple using clang. I
tried the
> '-fno-exceptions' option in order to do that, but unwinding
function symbols
> like '__aeabi_unwind_cpp_pr0' were still present. I think
'ExceptionType' of
> MCAsmInfo is set to ExceptionType::ARM with the above target triple and it
> is not affected by the '-fno-exceptions' option. Am I missing
something
> about this, or do we need to provide an interface to disable generation of
> exception codes?
At the MC layer I think we just have a bad name. The flag actually
controls what unwind table format is used. Those are used for
exceptions, but also have other uses.

At least for x86_64 and the .eh_frame section, you can exclude a
function by not including the uwtable attribute. At the clang level
that is done with the -fno-asynchronous-unwind-tables option.

Cheers,
Rafael

Hi Rafael,

Thanks for your response. I feel I need to learn ARM's unwind table's 
mechanism first. I saw ARM backend checks uwtable attribute and it 
generates '.cantunwind' directive, sets CantUnwind variable and etc... 
but it does not seems to avoid generation of the table. If someone knows 
it well, please guide me.

Thanks,
JinGu Kang

On 12/08/2014 02:36 PM, Rafael Espíndola wrote:
> On 8 December 2014 at 06:33, JinGu Kang <jingu at codeplay.com>
wrote:
>> Hi all
>>
>> I have a question about the '-fno-exceptions' option with clang
and
>> 'ExceptionsType' on MCAsmInfo.
>>
>> I am looking for a way to avoid generating stack unwinding codes when
>> compiling with the "armv7-none-linux-gnu" triple using clang.
I tried the
>> '-fno-exceptions' option in order to do that, but unwinding
function symbols
>> like '__aeabi_unwind_cpp_pr0' were still present. I think
'ExceptionType' of
>> MCAsmInfo is set to ExceptionType::ARM with the above target triple and
it
>> is not affected by the '-fno-exceptions' option. Am I missing
something
>> about this, or do we need to provide an interface to disable generation
of
>> exception codes?
> At the MC layer I think we just have a bad name. The flag actually
> controls what unwind table format is used. Those are used for
> exceptions, but also have other uses.
>
> At least for x86_64 and the .eh_frame section, you can exclude a
> function by not including the uwtable attribute. At the clang level
> that is done with the -fno-asynchronous-unwind-tables option.
>
> Cheers,
> Rafael