> What work actually needs to be done then on the toolchain front?  At a guess 
> it's mostly gcc, 

Depending on what we want, there's not much that needs to be done to gcc, 
other than a few ABI fixes which it would be good to slip in at this time 
(since the move to ELF is effectively a major flag day).  Most of the 
overrides that are in gcc/config/arm/netbsd.h and affect the ABI could 
probably be removed now.

> with some ld and ld.so_elf work.
Some.

>  Does it effect gas in 
> anyway?

Yes, though it may well just be a matter of reconfiguring it to assemble 
to ELF objects.

> 
> A while back you mentioned updating the ABI to something newer, which can do 
> thumb, arm26 and arm32 (or is that a bit like the holy grail of arm 
> processors :), do you have on docs on this or pointers to docs?  

Well, full support for thumb would require porting gcc to the ATPCS, this 
hasn't started yet, though it's possible I might be able to do it soon.

> Would the ARM linux abi work?  I believe that's in the 2.95.2 stuff 
> that's in the tree? 
It would be a good starting point.

> Are we better waiting for gcc 3?

From a C++ perspective yes (the C++ side of the ABI will be standardised 
as of 3.0 which should make C++ shared libs a more realistic proposition), 
other than that, there's no real reason to wait that I can think of off 
hand.  Since the ATPCS support won't be in 3.0 (at least, not in the 
official one), I don't think it is worth waiting for it at this time.

Slightly off topic, a cool project would be to build a kernel module that 
would allow ARMv4 chips (eg StrongARM) to emulate thumb instructions.  
Part of the ARMv4 architecture spec requires that the processor trap BX so 
that it can emulate thumb code.

R.