This is the mail archive of the
mailing list for the GCC project.
Re: [ARM] EABI and the default to short enums
Sebastian Huber <firstname.lastname@example.org> writes:
> On 02/14/2012 04:05 PM, Ian Lance Taylor wrote:
>> Sebastian Huber<email@example.com> writes:
>>> the default ARM EABI configuration uses short enums by default (from
>>> /* 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
>> firstname.lastname@example.org rather than email@example.com. 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
> 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. 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.
But I am not an ARM expert.