ARM-only [Patch] Allow 4 byte enum size (-fno-short-enums) | Remove hard coded short enum flag from the build scripts?

[Richard Earnshaw (lists)]

On 31/08/16 08:55, Schwarz, Konrad wrote:
>> -----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.
> 


GCC/GAS/LD on ARM systems emit Build Attributes[1].  One of these
attributes describes the way in which the file depends on how enum types
are handled (since in an ABI it *can* affect whether the files are
compatible with each other).  Unfortunately, GCC has a limitation in
that it only supports two of the four possible attribute values for this
particular attribute since we can't get at enough details in the
mid/front end to validate the user's code complies with the attribute
settings.

Note that with recent GCC you could use the following trick to limit the
size of the internal enums without changing the public interface model.

#pragma GCC push_options
#pragma GCC optimize ("-fshort-enums")
enum {
  a, b, c
} w;
#pragma GCC pop_options

int x = sizeof (w);


enum {
  d, e, f
} y;

int z = sizeof (y);

R.


[1]
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0045e/IHI0045E_ABI_addenda.pdf