This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Selecting the correct default ABI for the iWMMXt processor
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Ian Lance Taylor <ian at wasabisystems dot com>
- Cc: Nick Clifton <nickc at redhat dot com>, gcc-patches at gcc dot gnu dot org, Richard Earnshaw <rearnsha at arm dot com>
- Date: Thu, 15 Apr 2004 10:13:34 +0100
- Subject: Re: Selecting the correct default ABI for the iWMMXt processor
- Organization: ARM Ltd.
- Reply-to: Richard Earnshaw <rearnsha at arm dot com>
> Nick Clifton <nickc@redhat.com> writes:
>
> > Attempting to build the xscale-elf target in the current gcc sources
> > fails because the iwmmxt multilib does not build. This is because
> > specifying -mcpu=iwmmxt on the command line in not enough. GCC will
> > report "iwmmxt requires an AAPCS compliant ABI".
> > I have fixed this by altering the code to chose the default ABI if no
> > -mabi= command line switch is used. The code now checks to see if the
> > iWMMXt processor has been specified and if so it selects the AAPCS ABI.
>
> Hmmm.
>
> It seems very strange to me that a -mcpu option will change the ABI.
> People using iWMMXt in practice can use --with-abi to set their
> default ABI.
I agree, it's wrong. -mcpu must NOT change the default ABI. An OS
defines the ABI in use, not the -mcpu option. If a user knows what they
are doing sufficiently well to be adding -mcpu=iwmmxt, then they can
easily enough add a -mabi=aapcs option as well.
Note that the compiler should really be fixed so that -mcpu=iwmmxt can
generate code that will run on a pre-AAPCS ABI (for example by not using
LDRD in those circumstances).
> I think we should try to fix the multilib problem in a
> different way. Unfortunately, the current multilibs are expressed in
> terms of single options, so there is no obvious way to express
> -mcpu=iwmmxt -mabi=iwmmxt as a single multilib option. This could be
> fixed.
The current multilib infrastructure is rather inflexible. There's no way
to express that it would often be possible to build a single library that
could satisfy several multilib variants (for example, a library with
'-marm -mthumb-interwork' is 100% compatible with '-mthumb
-mthumb-interwork', but because -marm and -mthumb are not compatible and
we need those libraries we can't use the multilib exceptions mechanism to
just leave them out). We also really need a way to say, 'when building a
multilib with option '-mfoo' then add options '-mbar -mwombat' to the
command line. This would satisfy your above problem (the multilib option
would then be -mabi, and the extra flag would be -mcpu=iwmmxt). It would
also allow us to remove the somewhat gross hacks in the compiler that
causes -mthumb to force -mcpu=arm7tdmi.
R.