Re: [csl-arm] Tweaks to the linux-gnueabi configuration

[Richard Earnshaw <rearnsha at gcc dot gnu dot org>]

On Mon, 2005-03-07 at 14:19, Daniel Jacobowitz wrote:
> On Mon, Mar 07, 2005 at 10:14:24AM +0000, Richard Earnshaw wrote:
> > On Fri, 2005-03-04 at 21:26, Daniel Jacobowitz wrote:
> > > Tested by comparing the predefined macros and size of enums on arm-eabi
> > > and arm-linux-gnueabi.  Fixes various things I noticed while comparing.
> > > OK for csl-arm-branch?
> > 
> > This is OK apart from the SUBTARGET_CPU_DEFAULT change which doesn't
> > seem to belong in this patch (and wasn't mentioned in the ChangeLog).
> 
> 	* config/arm/linux-eabi.h (ARM_DEFAULT_ABI, SUBTARGET_CPU_DEFAULT)
> 
> The EABI really isn't applicable to anything before armv4t; I figure
> carrying around the Linux default of armv3 is a bit excessive.  I'll
> commit without that bit for now, but is that OK?  Should it be armv5?
> 
> Checked in like so - I missed the obvious documentation update.

It's true that the EABI isn't especially sympathetic to pre-v4t
processors (and in a shared-library type environment isn't especially
sympathetic to anything pre-v5t).  However, it isn't entirely
incompatible either (at the object level).

The ABI says that all objects should be interworking compatible, so for
strict ABI conformance objects that need to be compatible with ARMv4
should be built as v4t interworking, but with all bx instructions marked
with R_ARM_V4BX (so that a linker can fix them up).

And since there's no ABI compatibility issues between v3 and v4, then
supporting pre-v4 within the ABI is again simply a matter of avoiding
instructions that aren't available (other than the marked bx insns).

We thought very carefully about how a shared-library environment would
need to work and we concluded that the best set of rules were as
follows.

- All PLT sequences shall be in ARM state
- All PLT sequences shall end with an LDR into the PC (to call the
library)
- In a v4T object all dynamic entry points shall be in ARM state (so
that the above LDR instruction will arrive at the target in the correct
state).  Dynamic entry points can be added by the linker if needed;
there's not normally any need for the compiler to generate them.
- The dynamic resolver must be entered in ARM state.

We don't say how the dynamic resolver shall eventually call the target
function, but a trick does exist to ensure that a BX instruction will
never be executed on a pre-v4 core.  The exit sequence of resolver can
be done as (assuming the target address is in ip)

	ldmia ....  // restore all regs
	tst	ip, #1
	movne	pc, ip
	bx	ip

Since the bottom bit of IP will always be zero on a pre-v4 object this
will never fail.  It will also give the correct result on all later
cores.

So it really comes down to the non-technical issue of whether we can
afford to leave the v3/v4 cores out entirely.  While my personal
preference would be to try and move the world forward, I do wonder
whether the StrongARM legacy is sufficiently large to cause us to have
to hold back on this.

R.