This is the mail archive of the
mailing list for the GCC project.
Re: [ARM] EABI and the default to short enums
On 02/14/2012 06:51 PM, Ian Lance Taylor wrote:
Sebastian Huber<email@example.com> writes:That's what Sebastian is trying to do.
On 02/14/2012 04:05 PM, Ian Lance Taylor wrote:
Sebastian Huber<firstname.lastname@example.org> writes:
the default ARM EABI configuration uses short enums by default (from
/* AAPCS based ABIs use short enums by default. */
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
email@example.com rather than firstname.lastname@example.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
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.
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?
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.
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.