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

2012-02-28 Thread Sebastian Huber

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 Taylori...@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.hu...@embedded-brains.de
PGP : Public key available on request.

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


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

2012-02-27 Thread Daniel Jacobowitz
Sorry for being late to the party.

On Wed, Feb 15, 2012 at 9:55 AM, Ian Lance Taylor i...@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


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

2012-02-15 Thread Sebastian Huber

On 02/15/2012 07:07 AM, Ralf Corsepius wrote:

On 02/14/2012 06:51 PM, Ian Lance Taylor wrote:

Sebastian Hubersebastian.hu...@embedded-brains.de writes:


On 02/14/2012 04:05 PM, Ian Lance Taylor wrote:

Sebastian Hubersebastian.hu...@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.hu...@embedded-brains.de
PGP : Public key available on request.

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


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

2012-02-15 Thread Ian Lance Taylor
Sebastian Huber sebastian.hu...@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


[ARM] EABI and the default to short enums

2012-02-14 Thread Sebastian Huber

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.hu...@embedded-brains.de
PGP : Public key available on request.

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


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

2012-02-14 Thread Ian Lance Taylor
Sebastian Huber sebastian.hu...@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-h...@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


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

2012-02-14 Thread Sebastian Huber

On 02/14/2012 04:05 PM, Ian Lance Taylor wrote:

Sebastian Hubersebastian.hu...@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-h...@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.hu...@embedded-brains.de
PGP : Public key available on request.

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


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

2012-02-14 Thread Ian Lance Taylor
Sebastian Huber sebastian.hu...@embedded-brains.de writes:

 On 02/14/2012 04:05 PM, Ian Lance Taylor wrote:
 Sebastian Hubersebastian.hu...@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-h...@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


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

2012-02-14 Thread Ralf Corsepius

On 02/14/2012 06:51 PM, Ian Lance Taylor wrote:

Sebastian Hubersebastian.hu...@embedded-brains.de  writes:


On 02/14/2012 04:05 PM, Ian Lance Taylor wrote:

Sebastian Hubersebastian.hu...@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-h...@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