This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
RE: ARM-only [Patch] Allow 4 byte enum size (-fno-short-enums) | Remove hard coded short enum flag from the build scripts?
> -----Original Message-----
> From: newlib-owner@sourceware.org [mailto:newlib-owner@sourceware.org]
> On Behalf Of Corinna Vinschen
> > I'm unclear where newlib uses enums in its ABI, but the AAPCS
> > suggestion of enforcing minimal enum sizes via appropriately sized
> > integer constants (and ensuring that all enums in newlib have exactly
> > 32 bits) and using the right Tag_ABI_enum_size should allow code
> > compiled with -fshort-enums or with -fno-short-enums to link to
> > newlib.
>
> Given that, per Richard, the enum usage in the affected files is
> internal a change here is apparently not ABI-relevant. From my rather
> neutral stance it looks like a pretty safe change so far...
My admittedly theoretical understanding is that if the change affects
only the implementation, not the ABI, it would equally be possible
to mark the object files in newlib as, for example, not using enums
in its ABI. This would allow for space-efficient representation
of internal tables and would seem the best solution and the one
intended by the AAPCS.
However, Richard seems to indicate that the GCC tool chain does
not support this. I'm not sure what is missing here -- e.g.,
it is often possible to slip in an __asm__ to create an entry
in some section used solely by the linker, but maybe this
trick doesn't work in this case, or ld doesn't understand the
special semantics.