On Tue, Mar 26, 2002 at 10:11:53AM +0000, Richard Earnshaw wrote:

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

Fair enough, I got the impression from Ben that packed-enums was not
set in stone.

 > 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.

Okay.  Guess we'd have to hack the compiler to pick another register for
PIC, then.

 > > 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.

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).

 > > 	* 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.

Err, if you can distinguish the objects, and you can build the entire system
with that other compiler, then you effectively CAN support the other ABI.

 > 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.

I'm not trying to be underhanded about this.  I posted this specifically
because I wanted your input on it.  I just happened that I was talking to
Ben about it via a different channel before I proposed it here, because it
was convenient at the time.  I'm not trying to roll over anybody, really...

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>