thorpej@wasabisystems.com said:
> Actually, as I understand the semantics of EI_OSABI, if we conform
> with the ARM eABI, we'd want to use ELFOSABI_ARM, not ELFOSABI_NETBSD.
>  This field is not meant to identify the OS used, but e.g. the calling
> conventions (i.e. the very ABI issues we're banging through right
> now). 

I've talked with the colleague who's handling the ELF side of things, and 
I understand that using ELFOSABI_NETBSD wouldn't be a problem.  Normally, 
conforming ARM EABI images will set the top byte of the E_FLAGS field to 
the ABI version that they are conforming to (gnu tools currently leave 
this as zero, and then have their own weird interpretation of the lower 
bits).  Once we get a finalized ABI, I'd like to see the GNU tools setting 
the E_FLAGS field correctly to indicate the EABI version, which leaves the 
EI_OSABI field free for OS use.

Our feeling is that EI_OSABI should normally be left at zero in object 
files, unless there is some reason to wish to restrict an object file to a 
particular OS.  The field is most useful in executables and shared 
libraries as a way of indicating to the OS how the file should be 
interpreted.

R.