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