As mentioned on the standup call this morning, I've been trying to get my head around the way different parts of the toolchain using the config scripts and the triplets. I'd appreciate some thoughts on what the right thing to do is, especially since there was some unease at some of the ideas.
My aim here is to add an armv7 specific set of routines to the eglibc ports and get this picked up only when eglibc is built for armv7; but it's getting a bit tricky.
eglibc shares with gcc and binutils a script called config.sub (that lives in a separate repository) which munges the triplet into a $basic_machine and validates it for a set of known triplets.
So for example it has the (shell) pattern:
arm | arm[bl]e | arme[lb] | armv[2345] | armv[345][lb]
to recognise triplets of the form arm- armbe- armle- armel- armbe- armv5- armv5l- or armv5b-
It also knows more obscure things such as if you're configuring for a netwinder it's an armv4l- system running linux - but frankly most of that type of thing are a decade or two out of date. Note it doesn't yet know about armv6 or armv7.
eglibc builds a search path that at the moment includes a path under the 'ports' directory of the form
arm/eabi/$machine
where $machine is typically the first part of your triplet; however at the moment eglibc doesn't have any ARM version specific subdirectories.
If I just added an ports/sysdeps/arm/eabi/armv7 directory it wouldn't use it because it searches in arm/eabi/arm if configured with the triplet arm-linux-gnueabi or
--with-cpu sets $submachine (NOT $machine) - so if you pass --with-cpu=armv7 it ends up searching
arm/eabi/arm/armv7
if you used the triplet arm-linux-gnueabi. If you had a triplet like armel then I think it would be searching
arm/eabi/armel/armv7
So my original patch ( http://old.nabble.com/-ARM--architecture-specific-subdirectories,-optimised-... ) did the following:
* Modified the paths searched to be arm/eabi (rather than arm/eabi/$machine) * If $submachine hadn't been set by --with-cpu then autodetect it from gcc's #defines
which meant that it ignored the start of the triplet and let you specify --with-cpu=armv7
After some discussion with Joseph Myers, he's convinced me that isn't what eglibc is expecting (see later in the thread linked above); what it should be doing is that $machine should be armv7 and $submachine should be used if we wanted say a cortex-a8 or cortext-a9 specific version.
My current patch: * adds armv6 and armv7 to config.sub * adds arm/eabi/armv7 and arm/eabi/armv6t2 and one assembler routine in there. * If $machine is just 'arm' then it autodetects from gcc's #defines * else if $machine is armv.... then that's still $machine
So if you use:
a triplet like arm-linux-gnueabi it looks at gcc and if that's configured for armv7-a it searches arm/eabi/armv7
a triplet like armv7-linux-gnueabi then it searches arm/eabi/armv7 irrespective of what gcc was configured for
a triplet like armv7-linux-gnueabi and --with-cpu=cortex-a9 then it searches arm/eabi/armv7/cortex-a9 then arm/eabi/armv7
As far as I can tell gcc ignores the first part of the triplet, other than noting it's arm and spotting if it ends with b for big endian; (i.e. configuring gcc with armv4-linux-gnueabi and armv7-linux-gnueabi ends up with the same compiler).
binutils also mostly ignores the 1st part of the triple - although is a bit of a mess with different parts parsing it differently (it seems to spot arm9e for some odd reason); as far as I can tell gold will accept armbe* for big endian where as ld takes arm*b !
If you're still reading, then the questions are: 1) Does the approach I've suggested make sense - in particular that the machine directory chosen is based either on the triplet or where the triplet doesn't specify the configuration of gcc; that's my interpretation of what Joseph is suggesting.
2) Doing (1) would seem to suggest I should give config.sub armv6t2 and some of the other complex names.
Dave