In article <200201291337.NAA16231@cam-mail2.cambridge.arm.com>,
Richard Earnshaw <Richard.Earnshaw@arm.com> wrote:
>> On Mon, 28 Jan 2002, Nick Hudson wrote:
>> 
>> > On Tuesday 01 January 2002 1:42 pm, Ben Harris wrote:
>> > > Needed before any port changes to ELF:
>> > > * make system build with -fshort-enums. [bjh21]
>> > > * (gcc) check precise enum ABI, and implement it. [rearnsha]
>> >
>> > Any progress on this issue?
>> 
>> Basically, I've got a set of patches that make the system build, and
>> Richard has found out the current draft ABI.  The only question is whether
>> we implement it or not (see the recent "enums on ARM" thread), and there
>> are arguments both ways there.  rearnsha thinks we should follow ARM, tv
>> and I think we should follow other NetBSD ports and everyone else was more
>> interested in discussing the existence or otherwise of ILP64 Alphas.
>> 
>
>Yep, I've discussed the situation with colleagues here at ARM.  The ARM 
>ABI will not be changing in this respect: it will be using packed enums.
>
>So the question now is whether NetBSD will be using the ARM ABI or 
>something else.  What the something else is really doesn't matter, because 
>as soon as one part has been abandoned you might as well consider 
>everything open...
>
>Of course, as soon as you abandon the common ABI you loose the ability to 
>use other compilers, or pre-compiled libraries from other sources external 
>to the project.
>
>> Given the current impasse, I think we need someone in authority to make a
>> decision one way or the other.  Isn't this what <core@netbsd.org> are for?
>
>Indeed.

I am not an ARM or toolchain expert, but I think we should be going with
packed enums. My reasoning is:

- This is the official ARM abi. If you violate one aspect of it, you might
  throw the whole thing out. We want to be able to use externally supplied
  libraries, so we'll do what we have to.
- You can avoid the issue of library compatibility, if you never use enum
  declarations in function arguments; use int's instead. Looking at our
  header files, there is only a dozen or so functions that take enum foo
  as a parameter.
- Paying attention to short enums makes the code more portable, and fixing
  the code to work with short enums is trivial.
- If you really want to use enums in function parameters and maintain
  software compatibility you can force the compiler not to pack the enums.

christos