This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PR16350 patch ping - gcc doesn't understand big-endian ARM
On Thu, Mar 24, 2005 at 12:28:05PM +0000, Richard Earnshaw wrote:
> > [root@ixp12eb ~]# uname -a
> > Linux ixp12eb.wantstofly.org 2.6.12-rc1 #1 Sun Mar 20 19:24:18 CET 2005 armv4b armv4b armv4b GNU/Linux
> >
> > So.. config.guess should be mapping anything of the form "arm*b" to
> > 'armeb', then?
>
> The point of config.guess is to canonicalize this information so that
> it doesn't have to be done in every single gnu package. If just passing
> in uname(1) information causes ambiguity then config.guess isn't doing
> its job.
Sure, that makes sense -- there are clear advantages of not having
the arm architecture name as part of the target triple. Question
is, would rewriting to 'armeb' be a good thing to do? config.guess
returning 'armeb-unknown-linux-gnu' on big-endian ARMs, and something
like 'arm-unknown-linux-gnu' for little-endian seems clean enough.
(Should xscale* triples be deprecated as well, then, since they are
basically also just ARMs?)
> > And similarly, it ought to map all the "arm*l" archs that are out
> > there (armv3l, armv4l, armv5tel) to 'arm'? Or 'armel'?
>
> I'm less worried about these (because most ARM implementations default
> to little-endian) but a general clean-up should probably fix that too.
> Note the 'e' in armv5tel is part of the architecture, not part of the
> endianness spec.
Yeah. The 2.4 kernel just calls these 'armv5l', BTW.
> What happens if we have an ARM architecture 'armv7b' at some time in
> the future? Then we'd have to handle armv7bb and armv7bl.
[ But armv7bl still wouldn't match arm*b- :-) ]
--L