> So, even after much work to deal with the packed-enum issue, there are
> still problems in the source tree with packed-enums.  Finding them all
> is going to take a long time.
> 
> In addition, ARM still hasn't finalized the eABI.  We'd like to comply
> with it, but at this point, we have no guarantees that ARM won't flip-flop
> on packed-enums, thread-local-storage, etc.
> 

Arm won't be "flip-flopping" on packed enums.  This is not up for debate.

As for TLS, then it has already been pointed out that we can for now nail 
down both r9 and r10 and be completely compatible with any choice made.  
Re-enabling either (or both, should a TLS register not be allocated) is 
perfectly possible, and since both are call-save registers there would be 
no code incompatibility.

> I did not anticipate this much lossage when I previously advocated sticking
> to the ARM eABI.
> 
> So, after discussing this situation with Ben today, I'd like to propose
> the following:
> 
> 	* Effectively reject the ARM eABI at this time, instead picking
> 	  our own sane ABI.  This means not using packed-enums (I actually
> 	  backed out the packed-enum change to the compiler a few minutes
> 	  ago), and picking our own thread-local-storage register now.

I think this is a bad move, based on inverted priorities -- ie short term 
advantage over long-term gain.

> 	* Mark our ELF objects/execuables as ELFOSABI_NETBSD, to distinguish
> 	  it from the official ARM ABI.  This is the correct use of the
> 	  EI_OSABI field in the ELF header.

It would be correct no-matter what.  However, in the end it only really 
affects executables.

> 	* When the ARM eABI is finalized, add support in our dynamic linker
> 	  for allowing only objects of the same EI_OSABI to be linked.
> 	  This allows us to support the ARM eABI in the future.

Except that it wouldn't, since then to interwork with any code compiled 
with ABI conforming compilers you would need a complete set of system 
libraries compiled with the same base ABI conventions.  By adopting the 
changes you propose would lock us into only using GCC, or some other 
compiler where we could control the generated code.

> Ben pretty much agreed with this proposal.  I'd like to get buy-in on this
> SOON so that we can actually release all of our ARM platforms in 1.6.

Speaking personally, I think this is backwards, and I've said so before.  
It would be far better to accept the fact that we aren't going to make it 
in time for 1.6 and do the job properly for 1.7.

> If we do decide to go this way, the only thing to do is pick the thread
> local storage register... sounded like ARM was thinking of r9 or r10.
> I say we just pick r10.

No, nail down both as was suggested earlier.

I have to say, that you appear to be presenting this as a fait accompli.  
Given that this has always been discussed openly on the list before, I 
can't help feeling that you've been somewhat underhand about this.

R.