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
Sounds good to me FWIW. Just one comment...
David Gilbert david.gilbert@linaro.org writes:
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
I'm taking you literally here, but I think you want things like armeb-linux-gnueabi to be treated like arm-linux-gnueabi.
TBH, I think unconditionally using the autodetect (but setting $machine rather than $submachine, as you say) would be easier and more consistent across packages. gcc and eglibc will then agree on the target, whereas the extra complication in the current scheme is there simply to make eglibc and gcc disagree in certain cases. But I realise we might not want to fight that fight.
Richard
Richard Sandiford richard.sandiford@linaro.org wrote:
David Gilbert david.gilbert@linaro.org writes:
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
I'm taking you literally here, but I think you want things like armeb-linux-gnueabi to be treated like arm-linux-gnueabi.
TBH, I think unconditionally using the autodetect (but setting $machine rather than $submachine, as you say) would be easier and more consistent across packages. gcc and eglibc will then agree on the target, whereas the extra complication in the current scheme is there simply to make eglibc and gcc disagree in certain cases. But I realise we might not want to fight that fight.
FWIW I'd tend to agree that encoding the architecture level into the target triplet seems to lead to more confusion than that it helps ...
We certainly never did that on s390 (or powerpc, for that matter); instead, the way to select an architecture level is to build your system compiler to default to that level, and then build all your system libraries with that compiler; the libraries will detect the desired architecture level from GCC defines.
On the other hand, given that arm has already gone down the road of using the target triplet, I guess I can see why it might make sense to continue that. In the end, that's for the platform maintainers to decide ...
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
-- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294
On 16/09/11 15:12, Ulrich Weigand wrote:
Richard Sandiford richard.sandiford@linaro.org wrote:
David Gilbert david.gilbert@linaro.org writes:
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
I'm taking you literally here, but I think you want things like armeb-linux-gnueabi to be treated like arm-linux-gnueabi.
TBH, I think unconditionally using the autodetect (but setting $machine rather than $submachine, as you say) would be easier and more consistent across packages. gcc and eglibc will then agree on the target, whereas the extra complication in the current scheme is there simply to make eglibc and gcc disagree in certain cases. But I realise we might not want to fight that fight.
FWIW I'd tend to agree that encoding the architecture level into the target triplet seems to lead to more confusion than that it helps ...
Agreed. Especially as
1) It's incomplete -- doesn't cover FPU/Neon capabilities 2) It's generally mixed up with other things -- like endianness. This makes it all the more confusing 3) It's too ad-hoc -- sometimes it's an architecture, sometimes it's a CPU. This leads to all sorts of weird and wonderful names appearing in the config string which have to be understood.
We certainly never did that on s390 (or powerpc, for that matter); instead, the way to select an architecture level is to build your system compiler to default to that level, and then build all your system libraries with that compiler; the libraries will detect the desired architecture level from GCC defines.
I think it comes from the i[345]86 mess. I suspect it has origins in red-hat linux where the config triplet is built directly from the 'cpu' reported by the kernel uname -m component.
On the other hand, given that arm has already gone down the road of using the target triplet, I guess I can see why it might make sense to continue that. In the end, that's for the platform maintainers to decide ...
I'd prefer that we retrenched if possible. Let's not make the rat-hole even bigger.
R.
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
-- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
OK, so we seem to have agreement here that what we want is autodetect for eglibc and forget about the triplet; well technically that probably makes my life easier, and I don't think it's too hard a sell.
Dave
linaro-toolchain@lists.linaro.org
-
David Gilbert -
Richard Earnshaw -
Richard Sandiford -
Ulrich Weigand