> > For example (note, this is only an example), ARM has been working on a new 
> > ATPCS (to replace the old APCS) which is much better suited to 
> > interworking between ARM and Thumb code -- ok we don't have thumb support 
> > in NetBSD yet, but it would be sensible to plan for it.  If we decided to 
> 
> Hmm, given this I would prefer if we wait for it to stabilize before we
> spend effort to track it. Odds are good that support for it will appear
> in EGCS without our having to do anything.
> 

Since I'm the EGCS/ARM port maintainer (well, one of the two), it will 
probably be me doing it....  Of course, if I start working on that, it 
would be nice to know that it was because someone wanted to use it :-)  It 
certainly won't happen by magic.

> > go with that, then one variant would make all code naturally PIC, much 
> > like the rs6000/AIX model.  But this would probably mean rewriting a large 
> > amount of the .S files.  At the other end of the spectrum, we could stick 
> > with the current ABI, and all we might need to do is change a few 
> > assembler directives -- I'm not entirely sure here, since I haven't tried 
> 
> Maybe this is labor intensive, but it doesn't strike me as difficult -- I'd
> volunteer for it in fact. Most assembly routines in libraries operate on
> pointer arguments (which should already have the PC added into them) and
> converting LDR's into something PIC-safe shouldn't be too mind taxing.
> Maybe you know something about that code which I don't?
> 
It's not especially hard, just a bit tedious.  Especially if the fixed 
registers have changed, since the code has to be checked for conflicts.  
Most of the entry and exit handling can probably be handled with macros.