public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* [ARM] EABI and the default to short enums
@ 2012-02-14 13:23 Sebastian Huber
  2012-02-14 15:27 ` Ian Lance Taylor
  0 siblings, 1 reply; 9+ messages in thread
From: Sebastian Huber @ 2012-02-14 13:23 UTC (permalink / raw)
  To: gcc

Hello,

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?

Have a nice day!

-- 
Sebastian Huber, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax     : +49 89 18 90 80 79-9
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [ARM] EABI and the default to short enums
  2012-02-14 13:23 [ARM] EABI and the default to short enums Sebastian Huber
@ 2012-02-14 15:27 ` Ian Lance Taylor
  2012-02-14 16:41   ` Sebastian Huber
  0 siblings, 1 reply; 9+ messages in thread
From: Ian Lance Taylor @ 2012-02-14 15:27 UTC (permalink / raw)
  To: Sebastian Huber; +Cc: gcc

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.

Ian

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [ARM] EABI and the default to short enums
  2012-02-14 15:27 ` Ian Lance Taylor
@ 2012-02-14 16:41   ` Sebastian Huber
  2012-02-14 18:12     ` Ian Lance Taylor
  0 siblings, 1 reply; 9+ messages in thread
From: Sebastian Huber @ 2012-02-14 16:41 UTC (permalink / raw)
  To: gcc; +Cc: Ian Lance Taylor

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.

-- 
Sebastian Huber, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax     : +49 89 18 90 80 79-9
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [ARM] EABI and the default to short enums
  2012-02-14 16:41   ` Sebastian Huber
@ 2012-02-14 18:12     ` Ian Lance Taylor
  2012-02-15  8:31       ` Ralf Corsepius
  0 siblings, 1 reply; 9+ messages in thread
From: Ian Lance Taylor @ 2012-02-14 18:12 UTC (permalink / raw)
  To: Sebastian Huber; +Cc: gcc

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.  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.

Ian

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [ARM] EABI and the default to short enums
  2012-02-14 18:12     ` Ian Lance Taylor
@ 2012-02-15  8:31       ` Ralf Corsepius
  2012-02-15  9:30         ` Sebastian Huber
  0 siblings, 1 reply; 9+ messages in thread
From: Ralf Corsepius @ 2012-02-15  8:31 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: Sebastian Huber, gcc

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [ARM] EABI and the default to short enums
  2012-02-15  8:31       ` Ralf Corsepius
@ 2012-02-15  9:30         ` Sebastian Huber
  2012-02-15 15:19           ` Ian Lance Taylor
  0 siblings, 1 reply; 9+ messages in thread
From: Sebastian Huber @ 2012-02-15  9:30 UTC (permalink / raw)
  To: Ralf Corsepius; +Cc: Ian Lance Taylor, gcc

On 02/15/2012 07:07 AM, Ralf Corsepius wrote:
> 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:
[...]
>> 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.

Yes, exactly.

>
>> 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.

I mean the ABI described in "Procedure Call Standard for the ARM Architecture" 
document number "ARM IHI 0042D, current through ABI release 2.08".  In GCC this 
is ARM_ABI_AAPCS and ARM_ABI_AAPCS_LINUX?

>>
>> 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.

This is not hacking.  It is making a choice between two alternatives described 
in the document issued by ARM.  See also section 7.1.3 "Enumerated Types"

http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042d/IHI0042D_aapcs.pdf

For RTEMS it is surely not the worst choice to use the Linux variant of the 
EABI since a lot of software is developed for and tested with it.

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

Yes, this is also my problem.

-- 
Sebastian Huber, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax     : +49 89 18 90 80 79-9
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [ARM] EABI and the default to short enums
  2012-02-15  9:30         ` Sebastian Huber
@ 2012-02-15 15:19           ` Ian Lance Taylor
  2012-02-28  3:19             ` Daniel Jacobowitz
  0 siblings, 1 reply; 9+ messages in thread
From: Ian Lance Taylor @ 2012-02-15 15:19 UTC (permalink / raw)
  To: Sebastian Huber; +Cc: Ralf Corsepius, gcc

Sebastian Huber <sebastian.huber@embedded-brains.de> writes:

> I mean the ABI described in "Procedure Call Standard for the ARM
> Architecture" document number "ARM IHI 0042D, current through ABI
> release 2.08".  In GCC this is ARM_ABI_AAPCS and ARM_ABI_AAPCS_LINUX?

That is my understanding, yes.


> This is not hacking.  It is making a choice between two alternatives
> described in the document issued by ARM.  See also section 7.1.3
> "Enumerated Types"
>
> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042d/IHI0042D_aapcs.pdf
>
> For RTEMS it is surely not the worst choice to use the Linux variant
> of the EABI since a lot of software is developed for and tested with
> it.

Ouch, I did not know that the EABI left this open.  That seems like a
bug, because it prevents code from being interoperable.  This is
precisely the kind of thing an ABI should address.  Does anybody know
why they did this?

Ian

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [ARM] EABI and the default to short enums
  2012-02-15 15:19           ` Ian Lance Taylor
@ 2012-02-28  3:19             ` Daniel Jacobowitz
  2012-02-28 17:05               ` Sebastian Huber
  0 siblings, 1 reply; 9+ messages in thread
From: Daniel Jacobowitz @ 2012-02-28  3:19 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: Sebastian Huber, Ralf Corsepius, gcc

Sorry for being late to the party.

On Wed, Feb 15, 2012 at 9:55 AM, Ian Lance Taylor <iant@google.com> wrote:
> Ouch, I did not know that the EABI left this open.  That seems like a
> bug, because it prevents code from being interoperable.  This is
> precisely the kind of thing an ABI should address.  Does anybody know
> why they did this?

It's a matter of platform variants.  There are a sufficient number of
ARM use cases where the extra bytes matter (or else, there are a
sufficient number of ARM vendors / customers who feel that it
matters).  But there's also cases like Linux where the advantages of
int-sized enums outweigh the space cost.  So the platform ABI
supplement is supposed to decide.

I believe that the Linux variant has other deviations from base than
just this.  The one I remember in particular is TLS models but there
may be others.  Please check the full range of differences before you
decide which would be a better base for RTEMS.

-- 
Thanks,
Daniel

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [ARM] EABI and the default to short enums
  2012-02-28  3:19             ` Daniel Jacobowitz
@ 2012-02-28 17:05               ` Sebastian Huber
  0 siblings, 0 replies; 9+ messages in thread
From: Sebastian Huber @ 2012-02-28 17:05 UTC (permalink / raw)
  To: Daniel Jacobowitz; +Cc: Ian Lance Taylor, Ralf Corsepius, gcc

On 02/27/2012 10:33 PM, Daniel Jacobowitz wrote:
> Sorry for being late to the party.
>
> On Wed, Feb 15, 2012 at 9:55 AM, Ian Lance Taylor<iant@google.com>  wrote:
>> Ouch, I did not know that the EABI left this open.  That seems like a
>> bug, because it prevents code from being interoperable.  This is
>> precisely the kind of thing an ABI should address.  Does anybody know
>> why they did this?
>
> It's a matter of platform variants.  There are a sufficient number of
> ARM use cases where the extra bytes matter (or else, there are a
> sufficient number of ARM vendors / customers who feel that it
> matters).  But there's also cases like Linux where the advantages of
> int-sized enums outweigh the space cost.  So the platform ABI
> supplement is supposed to decide.
>
> I believe that the Linux variant has other deviations from base than
> just this.  The one I remember in particular is TLS models but there
> may be others.  Please check the full range of differences before you
> decide which would be a better base for RTEMS.
>

Thanks for the comment.  I just figured out, that in GCC 4.7 
ARM_ABI_AAPCS_LINUX is used for other stuff (e.g. Linux kernel support for 
atomic operations) and not only the enums.  Newlib makes also problems (some 
files of libc are compilied with -fshort-enums).  All in all its probably 
better to fix the XDR library and other things (the assumption that an enum is 
an int is quite common).

-- 
Sebastian Huber, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax     : +49 89 18 90 80 79-9
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2012-02-28 16:54 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-02-14 13:23 [ARM] EABI and the default to short enums Sebastian Huber
2012-02-14 15:27 ` Ian Lance Taylor
2012-02-14 16:41   ` Sebastian Huber
2012-02-14 18:12     ` Ian Lance Taylor
2012-02-15  8:31       ` Ralf Corsepius
2012-02-15  9:30         ` Sebastian Huber
2012-02-15 15:19           ` Ian Lance Taylor
2012-02-28  3:19             ` Daniel Jacobowitz
2012-02-28 17:05               ` Sebastian Huber

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).