[ARM] EABI and the default to short enums

[Ralf Corsepius]

On 02/14/2012 06:51 PM, Ian Lance Taylor wrote:
> Sebastian Huber<sebastian.huber@embedded-brains.de>  writes:
>
>> On 02/14/2012 04:05 PM, Ian Lance Taylor wrote:
>>> Sebastian Huber<sebastian.huber@embedded-brains.de>   writes:
>>>
>>>> the default ARM EABI configuration uses short enums by default (from
>>>> "gcc/config/arm/arm.c":
>>>>
>>>> /* AAPCS based ABIs use short enums by default.  */
>>>>
>>>> static bool
>>>> arm_default_short_enums (void)
>>>> {
>>>>     return TARGET_AAPCS_BASED&&   arm_abi != ARM_ABI_AAPCS_LINUX;
>>>> }
>>>>
>>>> This causes a major headache for me since some libraries assume that
>>>> sizeof(any enum)>   1, e.g. the standard XDR library.  Is the only
>>>> possible way to disable short enums to set the ABI to
>>>> ARM_ABI_AAPCS_LINUX?  Which side effects does this have?
>>>
>>> This question would be better asked on the mailing list
>>> gcc-help@gcc.gnu.org rather than gcc@gcc.gnu.org.  The gcc@ mailing list
>>> is for issues related to the development of gcc itself.  Please take any
>>> followups to gcc-help.  Thanks.
>>>
>>> You can use -fno-short-enums.  However, see the note about ABI
>>> compatibility in the -fshort-enums doc.
>>
>> The problem is that I need a proper GCC ARM configuration for the
>> RTEMS tool chain.  To do this I have to provide the right definitions
>> in
>>
>> gcc/config/arm/rtems-eabi.h
>> gcc/config/arm/t-rtems-eabi
>>
>> and this is clearly not a GCC user problem.  The so called ARM ELF
>> configuration didn't use short enums by default.  It seems that Linux
>> faced this problem before and now we have this exception in the
>> arm_default_short_enums() function above.  I want to preserve the ARM
>> ELF behavior with respect to enums also in the ARM EABI configuration.
>> The question is now who to achieve this.  One option is to set the ABI
>> to ARM_ABI_AAPCS_LINUX also for the RTEMS tool chain, but I am not
>> sure that this is the right thing.
>
>
> I would recommend that RTEMS change to the ARM EABI if possible.  That
> is the current standard ABI on ARM platforms.
That's what Sebastian is trying to do.

> It's true that the ARM
> EABI is different from the previous ABIs in some respect.  I believe
> that would mean using ARM_ABI_AAPCS.
>
> However, if you want to retain GNU/Linux compatibility, then using
> ARM_ABI_AAPCS_LINUX is likely to be correct.
So you would recommend RTEMS to throw away ARM_ABI_AAPCS and to use 
ARM_ABI_AAPCS_LINUX, which as far as I see is a 
Linux-specific/proprietaty deviation from EABI?

To me, this seems "hacking" - I am actually leaning towards considering 
the issues Sebastian mentions to be portability bugs in the non-GCC 
components he faces this issue with.

> But I am not an ARM expert.
Neither am I.

Ralf