> Errm, how can a file format cause/trigger a processor bug?  That's an 
> execution problem.  I'm not reading any of the Linux lists, so I've no 

More likely the OMF change exposed a bug by breaking an implicit assumption
elsewhere. The phrase "processor bug" sounds unlikely to me too...

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

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

Todd Whitesel
toddpw @ best.com