This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ARM] EABI and the default to short enums

On 02/14/2012 06:51 PM, Ian Lance Taylor wrote:
Sebastian Huber<> writes:

On 02/14/2012 04:05 PM, Ian Lance Taylor wrote:
Sebastian Huber<> 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 rather than 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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]