Patchwork scripts: add support for overriding the arch name in the tuple

login
register
mail settings
Submitter willy tarreau
Date Jan. 20, 2013, 10:58 p.m.
Message ID <20130120225822.GS6838@1wt.eu>
Download mbox | patch
Permalink /patch/213994/
State Changes Requested
Headers show

Comments

willy tarreau - Jan. 20, 2013, 10:58 p.m.
Hello,

it sometimes happens that I need to build toolchains for several variants
of a CPU and I want to have the variant name in the arch tuple. In fact,
this is very similar to what is done with i386/i486/i586/i686, all of them
being variants of the x86 arch family.

On arm, we commonly see armv5/armv6/armv7 and with v7 there are two common
cpus which are cortex a8 and a9.

So I'm used to build my toolchains with a prefix which is 'armv5te',
'armv7a8', 'armv7a9' etc...

For this I wrote the small patch below for ct-ng-1.15.3, which still works
with 1.17.0.

On one of my machines, the toolchain directory looks like this, which is
quite convenient to use :

  arm-gcc43_glibc29-linux-gnueabi/
  arm-gcc44_glibc29-linux-gnueabi/
  arm-gcc45_glibc29-linux-gnueabi/
  armv7a8-gcc43_glibc29-linux-gnueabi/
  armv7a9-gcc44_glibc29-linux-gnueabi/
  armv7a9-gcc47_glibc29-linux-gnueabi/
  armv7a9-gcc47_glibc29-linux-gnueabihf/
  i386-gcc34_glibc23-linux-gnu/
  x86_64-gcc34_glibc23-linux-gnu/

Hoping someone finds the patch useful.

Please keep me CC of any response as I'm not subscribed to the list.

Regards,
Willy

---


--
For unsubscribe information see http://sourceware.org/lists.html#faq
Yann E. MORIN - Jan. 20, 2013, 11:30 p.m.
Willy, All,

On Sunday 20 January 2013 Willy Tarreau wrote:
> it sometimes happens that I need to build toolchains for several variants
> of a CPU and I want to have the variant name in the arch tuple. In fact,
> this is very similar to what is done with i386/i486/i586/i686, all of them
> being variants of the x86 arch family.
> 
> On arm, we commonly see armv5/armv6/armv7 and with v7 there are two common
> cpus which are cortex a8 and a9.
> 
> So I'm used to build my toolchains with a prefix which is 'armv5te',
> 'armv7a8', 'armv7a9' etc...
> 
> For this I wrote the small patch below for ct-ng-1.15.3, which still works
> with 1.17.0.
> 
> On one of my machines, the toolchain directory looks like this, which is
> quite convenient to use :
> 
>   arm-gcc43_glibc29-linux-gnueabi/
>   arm-gcc44_glibc29-linux-gnueabi/
>   arm-gcc45_glibc29-linux-gnueabi/
>   armv7a8-gcc43_glibc29-linux-gnueabi/
>   armv7a9-gcc44_glibc29-linux-gnueabi/
>   armv7a9-gcc47_glibc29-linux-gnueabi/
>   armv7a9-gcc47_glibc29-linux-gnueabihf/

How do you managfed to have a '*-gnueabihf' with crosstool-NG?
Last I tested, gcc broke because it did not recognise it as an EABI
variant, and would not include the EABI file in gcc/config/arm/ .

Even with a bit of patching, I ended up in a few hiccups here and there,
so that's why ct-ng does not set the tuple to '*-gnueabihf' for now for
ARM hard-float ABI.

>   i386-gcc34_glibc23-linux-gnu/
>   x86_64-gcc34_glibc23-linux-gnu/
> 
> Hoping someone finds the patch useful.

A few comments:
  - missing SoB line
  - provide a more terse commit-log, eg something like:
    ---8<---
    arch: provide a arch-override for the tuple

    For some architectures, it is legit to have an alternate value in the
    'architecture' part of the tuple. For example:
        armv5te-*
        armv7a8-*

    Besides, some packages expect the tuple to reflect the arch variant
    (eg. openMPI) to detect the variant's capabilities (eg. atomic
    primitives).

    We already have this for x86 (i[3456]86-*), but it is not possible
    for other archs.

    This patch provides an overide mechanism

    Signed-off-by: You you@there
    ---8<---
    
> diff -urN ./config/target.in ./config/target.in
> --- ./config/target.in.orig	2012-07-17 22:39:55.000000000 +0200
> +++ ./config/target.in	2012-07-27 12:02:08.682588639 +0200
> @@ -5,6 +5,17 @@
>  config ARCH
>      string
>  
> +config ARCH_OVERRIDE
> +    string
> +    prompt "Arch name to use in the resulting tuple instead of ${CT_ARCH}"
> +    help
> +      Some architectures have multiple variants and being able to specify
> +      the variant instead of the arch is quite convenient. This is commonly
> +      seen for instance when "armv5tel-" is used as a prefix instead of the
> +      more generic "arm-", or with "alphaev6-" instead of "alpha-".
> +
> +      If you're not sure about what this is, leave it blank.
> +

I think we should not allow the user to completely overide the arch-part.
We should just allow for appending to the arch-part. This would be added
to the default tuple, and would not create symlinks as the two other
options currently do, so it would be possible to install more than one
toolchain in the same place, as the default tuples would all be different
(maybe that's what I did not completely explain during our private
exchange).

Thus, CT_TARGET_ARCH_SUFFIX="v5te" would give a tuple starting with
"armv5te-".

IMHO, giving the user the ability to completely overide the arch-part is
opening the door to complete mayhem. I'm a bit uneasy with that.

[--SNIP--]
> diff -urN ./scripts/functions ./scripts/functions
> --- ./scripts/functions.orig	2012-07-17 22:39:55.000000000 +0200
> +++ ./scripts/functions	2012-07-27 11:57:19.903088370 +0200
> @@ -982,7 +982,7 @@
>      esac
>  
>      # Build the default architecture tuple part
> -    CT_TARGET_ARCH="${CT_ARCH}"
> +    CT_TARGET_ARCH="${CT_ARCH_OVERRIDE:-${CT_ARCH}}"

Here, we'd have:
    CT_TARGET_ARCH="${CT_ARCH}${CT_TARGET_ARCH_SUFFIX}"

And similar for the architectures. Which would ensure the default tuple
will include this arch-part suffix.

Regards,
Yann E. MORIN.
willy tarreau - Jan. 20, 2013, 11:48 p.m.
On Mon, Jan 21, 2013 at 12:30:18AM +0100, Yann E. MORIN wrote:
> Willy, All,
> 
> On Sunday 20 January 2013 Willy Tarreau wrote:
> > it sometimes happens that I need to build toolchains for several variants
> > of a CPU and I want to have the variant name in the arch tuple. In fact,
> > this is very similar to what is done with i386/i486/i586/i686, all of them
> > being variants of the x86 arch family.
> > 
> > On arm, we commonly see armv5/armv6/armv7 and with v7 there are two common
> > cpus which are cortex a8 and a9.
> > 
> > So I'm used to build my toolchains with a prefix which is 'armv5te',
> > 'armv7a8', 'armv7a9' etc...
> > 
> > For this I wrote the small patch below for ct-ng-1.15.3, which still works
> > with 1.17.0.
> > 
> > On one of my machines, the toolchain directory looks like this, which is
> > quite convenient to use :
> > 
> >   arm-gcc43_glibc29-linux-gnueabi/
> >   arm-gcc44_glibc29-linux-gnueabi/
> >   arm-gcc45_glibc29-linux-gnueabi/
> >   armv7a8-gcc43_glibc29-linux-gnueabi/
> >   armv7a9-gcc44_glibc29-linux-gnueabi/
> >   armv7a9-gcc47_glibc29-linux-gnueabi/
> >   armv7a9-gcc47_glibc29-linux-gnueabihf/
> 
> How do you managfed to have a '*-gnueabihf' with crosstool-NG?
> Last I tested, gcc broke because it did not recognise it as an EABI
> variant, and would not include the EABI file in gcc/config/arm/ .

In fact only the directory has the extension name. "ls" caught it while
it was building but it's not usable for me. Sorry for the confusion.

> Even with a bit of patching, I ended up in a few hiccups here and there,
> so that's why ct-ng does not set the tuple to '*-gnueabihf' for now for
> ARM hard-float ABI.

Indeed, I've read some of your posts on the subject. I'm going to move
the "hf" into the cpu part on the left, because most scripts check for
"arm*-<anything>" thanks to the many variants that exist.

> >   i386-gcc34_glibc23-linux-gnu/
> >   x86_64-gcc34_glibc23-linux-gnu/
> > 
> > Hoping someone finds the patch useful.
> 
> A few comments:
>   - missing SoB line

Sorry, I just attached this old patch and didn't think about it being
used as a commit e-mail.

>   - provide a more terse commit-log, eg something like:
>     ---8<---
>     arch: provide a arch-override for the tuple
> 
>     For some architectures, it is legit to have an alternate value in the
>     'architecture' part of the tuple. For example:
>         armv5te-*
>         armv7a8-*
> 
>     Besides, some packages expect the tuple to reflect the arch variant
>     (eg. openMPI) to detect the variant's capabilities (eg. atomic
>     primitives).
> 
>     We already have this for x86 (i[3456]86-*), but it is not possible
>     for other archs.
> 
>     This patch provides an overide mechanism
> 
>     Signed-off-by: You you@there
>     ---8<---

Do you want me to repost the whole mail or are you OK with me just adding
my SOB here, since you rebuilt the whole commit message above ?

    =>  Signed-off-by: Willy Tarreau <w@1wt.eu>
    
> > diff -urN ./config/target.in ./config/target.in
> > --- ./config/target.in.orig	2012-07-17 22:39:55.000000000 +0200
> > +++ ./config/target.in	2012-07-27 12:02:08.682588639 +0200
> > @@ -5,6 +5,17 @@
> >  config ARCH
> >      string
> >  
> > +config ARCH_OVERRIDE
> > +    string
> > +    prompt "Arch name to use in the resulting tuple instead of ${CT_ARCH}"
> > +    help
> > +      Some architectures have multiple variants and being able to specify
> > +      the variant instead of the arch is quite convenient. This is commonly
> > +      seen for instance when "armv5tel-" is used as a prefix instead of the
> > +      more generic "arm-", or with "alphaev6-" instead of "alpha-".
> > +
> > +      If you're not sure about what this is, leave it blank.
> > +
> 
> I think we should not allow the user to completely overide the arch-part.
> We should just allow for appending to the arch-part. This would be added
> to the default tuple, and would not create symlinks as the two other
> options currently do, so it would be possible to install more than one
> toolchain in the same place, as the default tuples would all be different
> (maybe that's what I did not completely explain during our private
> exchange).
> 
> Thus, CT_TARGET_ARCH_SUFFIX="v5te" would give a tuple starting with
> "armv5te-".
> 
> IMHO, giving the user the ability to completely overide the arch-part is
> opening the door to complete mayhem. I'm a bit uneasy with that.

Well, I thought about it differently. The x86 mess is a good example of
something where the very first chars are replaced. The CPUs are not named
x86_i386 but just i386 for example. I don't know if other archs are used
to have completely different names in their tuple for small variants of
the CPU. For example, I don't know if there will be any intent to force
names between arm* and aarch64* (just an example).

I would say that using an ARCH_SUFFIX as you suggest satisfies my needs
*at the moment*. I'm just not certain it's the case for everyone :-/
Maybe someone else has any opinion on this based on another experience ?

Regards,
Willy


--
For unsubscribe information see http://sourceware.org/lists.html#faq
Yann E. MORIN - Jan. 21, 2013, 6:10 p.m.
Willy, All,

On Monday 21 January 2013 Willy Tarreau wrote:
> On Mon, Jan 21, 2013 at 12:30:18AM +0100, Yann E. MORIN wrote:
[--SNIP--]
> > A few comments:
> >   - missing SoB line
[--SNIP--]
> Do you want me to repost the whole mail or are you OK with me just adding
> my SOB here, since you rebuilt the whole commit message above ?
>     =>  Signed-off-by: Willy Tarreau <w@1wt.eu>

OK, thank you. I'll add it locally.

[--SNIP--]
> > IMHO, giving the user the ability to completely overide the arch-part is
> > opening the door to complete mayhem. I'm a bit uneasy with that.
> 
> Well, I thought about it differently. The x86 mess is a good example of
> something where the very first chars are replaced. The CPUs are not named
> x86_i386 but just i386 for example. I don't know if other archs are used
> to have completely different names in their tuple for small variants of
> the CPU. For example, I don't know if there will be any intent to force
> names between arm* and aarch64* (just an example).
> 
> I would say that using an ARCH_SUFFIX as you suggest satisfies my needs
> *at the moment*. I'm just not certain it's the case for everyone :-/
> Maybe someone else has any opinion on this based on another experience ?

OK, no need to over-engineer this. I'll change your patch to add a suffix.

Then, *when* and *of* the case arises, we'll see what to do for those
architectures that want to replace the arch-part of their tuple.

Regards,
Yann E. MORIN.
willy tarreau - Jan. 21, 2013, 6:58 p.m.
On Mon, Jan 21, 2013 at 07:10:19PM +0100, Yann E. MORIN wrote:
> OK, no need to over-engineer this. I'll change your patch to add a suffix.
> 
> Then, *when* and *of* the case arises, we'll see what to do for those
> architectures that want to replace the arch-part of their tuple.

OK, seems reasonable to me indeed.

Thanks!
Willy


--
For unsubscribe information see http://sourceware.org/lists.html#faq
Yann E. MORIN - Jan. 22, 2013, 12:11 a.m.
willy, All,

Your patch:
    arch: allow adding a suffix to the arch-part of a tuple

has been applied as: #9d0b37f08a10
    http://crosstool-ng.org/hg/crosstool-ng/rev/9d0b37f08a10

Thank you!

Regards,
Yann E. MORIN.



--
For unsubscribe information see http://sourceware.org/lists.html#faq

Patch

diff -urN ./config/target.in ./config/target.in
--- ./config/target.in.orig	2012-07-17 22:39:55.000000000 +0200
+++ ./config/target.in	2012-07-27 12:02:08.682588639 +0200
@@ -5,6 +5,17 @@ 
 config ARCH
     string
 
+config ARCH_OVERRIDE
+    string
+    prompt "Arch name to use in the resulting tuple instead of ${CT_ARCH}"
+    help
+      Some architectures have multiple variants and being able to specify
+      the variant instead of the arch is quite convenient. This is commonly
+      seen for instance when "armv5tel-" is used as a prefix instead of the
+      more generic "arm-", or with "alphaev6-" instead of "alpha-".
+
+      If you're not sure about what this is, leave it blank.
+
 # Pre-declare target optimisation variables
 config ARCH_SUPPORTS_BOTH_MMU
 config ARCH_SUPPORTS_BOTH_ENDIAN
diff -urN ./scripts/build/arch/alpha.sh ./scripts/build/arch/alpha.sh
--- ./scripts/build/arch/alpha.sh.orig	2012-07-17 22:39:55.000000000 +0200
+++ ./scripts/build/arch/alpha.sh	2012-07-27 11:58:57.190090149 +0200
@@ -2,5 +2,5 @@ 
 
 CT_DoArchTupleValues () {
     # The architecture part of the tuple:
-    CT_TARGET_ARCH="${CT_ARCH}${CT_ARCH_ALPHA_VARIANT}"
+    CT_TARGET_ARCH="${CT_ARCH_OVERRIDE:-${CT_ARCH}${CT_ARCH_ALPHA_VARIANT}}"
 }
diff -urN ./scripts/build/arch/arm.sh ./scripts/build/arch/arm.sh
--- ./scripts/build/arch/arm.sh.orig	2012-07-17 22:39:55.000000000 +0200
+++ ./scripts/build/arch/arm.sh	2012-07-27 11:58:50.607102794 +0200
@@ -2,7 +2,7 @@ 
 
 CT_DoArchTupleValues() {
     # The architecture part of the tuple:
-    CT_TARGET_ARCH="${CT_ARCH}${target_endian_eb}"
+    CT_TARGET_ARCH="${CT_ARCH_OVERRIDE:-${CT_ARCH}${target_endian_eb}}"
 
     # The system part of the tuple:
     case "${CT_LIBC},${CT_ARCH_ARM_EABI}" in
diff -urN ./scripts/build/arch/avr32.sh ./scripts/build/arch/avr32.sh
--- ./scripts/build/arch/avr32.sh.orig	2012-07-17 22:39:55.000000000 +0200
+++ ./scripts/build/arch/avr32.sh	2012-07-27 11:58:04.299089005 +0200
@@ -2,7 +2,7 @@ 
 
 CT_DoArchTupleValues() {
     # The architecture part of the tuple:
-    CT_TARGET_ARCH="${CT_ARCH}"
+    CT_TARGET_ARCH="${CT_ARCH_OVERRIDE:-${CT_ARCH}}"
 
     # gcc ./configure flags
     CT_ARCH_WITH_ARCH=
diff -urN ./scripts/build/arch/blackfin.sh ./scripts/build/arch/blackfin.sh
--- ./scripts/build/arch/blackfin.sh.orig	2012-07-17 22:39:55.000000000 +0200
+++ ./scripts/build/arch/blackfin.sh	2012-07-27 11:58:12.670588818 +0200
@@ -2,7 +2,7 @@ 
 
 CT_DoArchTupleValues() {
     # The architecture part of the tuple:
-    CT_TARGET_ARCH="bfin"
+    CT_TARGET_ARCH="${CT_ARCH_OVERRIDE:-bfin}"
 
     # gcc ./configure flags
     CT_ARCH_WITH_ARCH=
diff -urN ./scripts/build/arch/mips.sh ./scripts/build/arch/mips.sh
--- ./scripts/build/arch/mips.sh.orig	2012-07-17 22:39:55.000000000 +0200
+++ ./scripts/build/arch/mips.sh	2012-07-27 11:58:40.919091367 +0200
@@ -3,10 +3,10 @@ 
 CT_DoArchTupleValues() {
     # The architecture part of the tuple, override only for 64-bit
     if [ "${CT_ARCH_64}" = "y" ]; then
-        CT_TARGET_ARCH="mips64${target_endian_el}"
+        CT_TARGET_ARCH="${CT_ARCH_OVERRIDE:-mips64${target_endian_el}}"
     else
         # The architecture part of the tuple:
-        CT_TARGET_ARCH="${CT_ARCH}${target_endian_el}"
+        CT_TARGET_ARCH="${CT_ARCH_OVERRIDE:-${CT_ARCH}${target_endian_el}}"
     fi
 
     # Override CFLAGS for endianness:
diff -urN ./scripts/build/arch/powerpc.sh ./scripts/build/arch/powerpc.sh
--- ./scripts/build/arch/powerpc.sh.orig	2012-07-17 22:39:55.000000000 +0200
+++ ./scripts/build/arch/powerpc.sh	2012-07-27 11:59:15.611087634 +0200
@@ -3,7 +3,7 @@ 
 CT_DoArchTupleValues () {
     # The architecture part of the tuple, override only for 64-bit
     if [ "${CT_ARCH_64}" = "y" ]; then
-        CT_TARGET_ARCH="powerpc64"
+        CT_TARGET_ARCH="${CT_ARCH_OVERRIDE:-powerpc64}"
     fi
 
     # Only override values when ABI is not the default
diff -urN ./scripts/build/arch/s390.sh ./scripts/build/arch/s390.sh
--- ./scripts/build/arch/s390.sh.orig	2012-07-17 22:39:55.000000000 +0200
+++ ./scripts/build/arch/s390.sh	2012-07-27 11:59:22.603588053 +0200
@@ -3,6 +3,6 @@ 
 CT_DoArchTupleValues() {
     # That's the only thing to override
     if [ "${CT_ARCH_64}" = "y" ]; then
-        CT_TARGET_ARCH="s390x"
+        CT_TARGET_ARCH="${CT_ARCH_OVERRIDE:-s390x}"
     fi
 }
diff -urN ./scripts/build/arch/sh.sh ./scripts/build/arch/sh.sh
--- ./scripts/build/arch/sh.sh.orig	2012-07-17 22:39:55.000000000 +0200
+++ ./scripts/build/arch/sh.sh	2012-07-27 11:59:32.815087642 +0200
@@ -2,7 +2,7 @@ 
 
 CT_DoArchTupleValues () {
     # The architecture part of the tuple:
-    CT_TARGET_ARCH="${CT_ARCH_SH_VARIANT}${target_endian_eb}"
+    CT_TARGET_ARCH="${CT_ARCH_OVERRIDE:-${CT_ARCH_SH_VARIANT}${target_endian_eb}}"
 
     # gcc ./configure flags
     CT_ARCH_WITH_ARCH=
diff -urN ./scripts/build/arch/sparc.sh ./scripts/build/arch/sparc.sh
--- ./scripts/build/arch/sparc.sh.orig	2012-07-17 22:39:55.000000000 +0200
+++ ./scripts/build/arch/sparc.sh	2012-07-27 11:59:39.655111756 +0200
@@ -2,7 +2,7 @@ 
 CT_DoArchTupleValues() {
     # That's the only thing to override
     if [ "${CT_ARCH_64}" = "y" ]; then
-        CT_TARGET_ARCH="${CT_ARCH}64"
+        CT_TARGET_ARCH="${CT_ARCH_OVERRIDE:-${CT_ARCH}64}"
     fi
 
 }
diff -urN ./scripts/build/arch/x86.sh ./scripts/build/arch/x86.sh
--- ./scripts/build/arch/x86.sh.orig	2012-07-17 22:39:55.000000000 +0200
+++ ./scripts/build/arch/x86.sh	2012-07-27 12:00:52.942587401 +0200
@@ -6,18 +6,18 @@ 
 
     # Override the architecture part of the tuple:
     if [ "${CT_ARCH_64}" = "y" ]; then
-        CT_TARGET_ARCH=x86_64
+        CT_TARGET_ARCH="${CT_ARCH_OVERRIDE:-x86_64}"
     else
         arch="${CT_ARCH_ARCH}"
         [ -z "${arch}" ] && arch="${CT_ARCH_TUNE}"
         case "${arch}" in
-            "")                           CT_TARGET_ARCH=i386;;
-            i386|i486|i586|i686)          CT_TARGET_ARCH="${arch}";;
-            winchip*)                     CT_TARGET_ARCH=i486;;
-            pentium|pentium-mmx|c3*)      CT_TARGET_ARCH=i586;;
-            pentiumpro|pentium*|athlon*)  CT_TARGET_ARCH=i686;;
-            prescott)                     CT_TARGET_ARCH=i686;;
-            *)                            CT_TARGET_ARCH=i586;;
+            "")                           CT_TARGET_ARCH="${CT_ARCH_OVERRIDE:-i386}";;
+            i386|i486|i586|i686)          CT_TARGET_ARCH="${CT_ARCH_OVERRIDE:-${arch}}";;
+            winchip*)                     CT_TARGET_ARCH="${CT_ARCH_OVERRIDE:-i486}";;
+            pentium|pentium-mmx|c3*)      CT_TARGET_ARCH="${CT_ARCH_OVERRIDE:-i586}";;
+            pentiumpro|pentium*|athlon*)  CT_TARGET_ARCH="${CT_ARCH_OVERRIDE:-i686}";;
+            prescott)                     CT_TARGET_ARCH="${CT_ARCH_OVERRIDE:-i686}";;
+            *)                            CT_TARGET_ARCH="${CT_ARCH_OVERRIDE:-i586}";;
         esac
     fi
 }
diff -urN ./scripts/functions ./scripts/functions
--- ./scripts/functions.orig	2012-07-17 22:39:55.000000000 +0200
+++ ./scripts/functions	2012-07-27 11:57:19.903088370 +0200
@@ -982,7 +982,7 @@ 
     esac
 
     # Build the default architecture tuple part
-    CT_TARGET_ARCH="${CT_ARCH}"
+    CT_TARGET_ARCH="${CT_ARCH_OVERRIDE:-${CT_ARCH}}"
 
     # Set defaults for the system part of the tuple. Can be overriden
     # by architecture-specific values.