Re: ARM BE8 linker support

[Richard Earnshaw <rearnsha at arm dot com>]

On Fri, 2004-04-02 at 16:04, Daniel Jacobowitz wrote:
> On Fri, Apr 02, 2004 at 11:03:08AM +0100, Richard Earnshaw wrote:
> > > If this were gcc I'd probably suggest something equivalent to -mabi=, and the 
> > > associated --with-abi= configure switch. There doesn't seem to be the same 
> > > precedent for this in binutils/ld though.
> > > 
> > 
> > I'm not entirely convinced by the --with-abi= in gcc.  It sort of makes
> > sense in the deeply embedded world, but it's generally pretty
> > meaningless in the platform space (a platform defines a fixed ABI, and
> > you can't generally mess with the configuration and expect things to
> > work).
> 
> Well, you can in surprisingly many cases.  That's where I use it and
> designed it for - not in the "deeply embedded" space, but in custom
> GNU/Linux target environments.  Obviously any libraries that are aware
> of the ABI (meaning just glibc, for me at the moment) need some custom
> work to make this happen.  But otherwise it works quite well, and it
> prevents all sorts of embarassing mistakes later in the development
> cycle (mysterious linker errors, mostly :).
> 

Don't be fooled into thinking that because you (who builds complete
systems) can get away with this that your average platform-level
developer will be able to do so.  Changing the ABI means rebuilding
*everything* if you don't want to risk running into subtle consistency
bugs at a later date.

> For instance, it's remarkably easy to build an ARM soft-fpa or soft-vfp
> userspace.  As it happens I had to hack the gas build process a bit
> to change the FP default for the assembler, since no
> --with-float/--with-abi was available.

We really need to be steering people away from the idea that Linux on
ARM comes with a selection of ABIs.  I'm really hoping that Linux on ARM
will adopt the EABI as its base standard (since clearly the existing FPA
based one doesn't scale to new systems) and then try to move forward
from there in one direction.  Only closed systems can afford to tinker
with the ABI for each instance; in the more general case of open (or
even semi-open) systems, where the user can install a new application at
a later date, the ABI needs to be concretely nailed down.

R.