The only thing that needs to be done before we can start moving the major
NetBSD/arm ports to ELF is to sort out what we're doing with enums.  So
let's do that.  First, some background:

At present, all NetBSD ports have fixed-size enumeration types, so all
enums on a given port are the same size.  The forthcoming ARM EABI-2001 is
very likely to specify variable-length enumeration types, where enums have
the same size as the smallest integer type that will contain all their
enumarators.  These are binary-incompatible, so we have to decide which
one we'll use for ARM ELF.  I've already built a compiler that uses
-fshort-enums (i.e. variable-size), and found all the changes necessary to
get NetBSD-current to compile with it, though I haven't committed all of
these yet.

Reasons why we should use -fshort-enums:
 * It's what EABI-2001 will specify.
 * It will reduce memory usage.

Reasons why we should not use -fshort-enums:
 * Enum membership changes cause ABI changes, and hence library major
   number changes at unexpected times.
 * Enums will tend to be types that are slow to load and store  on ARMv3,
   which is our default compiler target.
 * Much third-party software assumes -fno-short-enums.

My opinion is that we should actually keep our current ABI for enums.  I
don't think that following ARM's ABI is particularly desirable, since on
past experience it'll change at some point anyway (witness the
struct-alignment business), but I'd like to hear what other people think.

-- 
Ben Harris                                                   <bjh21@netbsd.org>
Portmaster, NetBSD/arm26               <URL:http://www.netbsd.org/Ports/arm26/>