This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Selecting the correct default ABI for the iWMMXt processor


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]