Pass --build=<triplet> to native builds by default?

Pass --build=<triplet> to native builds by default?

[Mark H Weaver]

It turns out that on ARM systems, the result of 'config.guess' depends
on the result of 'uname -m'.  In other words, details of the kernel (and
perhaps processor?) on the build machine will determine the triplet of
our builds, which in turn may affect what set of instructions is used.

Therefore, I think that on ARM systems (and perhaps _all_ systems), we
should consider passing --build=<triplet> to configure by default.

What do you think?

    Mark

Re: Pass --build=<triplet> to native builds by default?

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> It turns out that on ARM systems, the result of 'config.guess' depends
> on the result of 'uname -m'.  In other words, details of the kernel (and
> perhaps processor?) on the build machine will determine the triplet of
> our builds, which in turn may affect what set of instructions is used.

Do you know how the ‘uname -m’ output is used in config.guess?  What
does it return on ARM?

Often (always?) config.guess runs the compiler, and I think that’s the
most important source of information that it uses.

Thanks,
Ludo’.

Re: Pass --build=<triplet> to native builds by default?

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> It turns out that on ARM systems, the result of 'config.guess' depends
>> on the result of 'uname -m'.  In other words, details of the kernel (and
>> perhaps processor?) on the build machine will determine the triplet of
>> our builds, which in turn may affect what set of instructions is used.
>
> Do you know how the ‘uname -m’ output is used in config.guess?  What
> does it return on ARM?

The output of 'uname -m' becomes the first (cpu) component of the GNU
triplet.  uname(1) gets its information from the kernel via the uname(2)
system call.  The field returned by 'uname -m' is described as "Hardware
identifier".  See <http://man7.org/linux/man-pages/man2/uname.2.html>.

Here's the relevant section of config.guess from gcc-4.8.4:

--8<---------------cut here---------------start------------->8---
    arm*:Linux:*:*)
	eval $set_cc_for_build
	if echo __ARM_EABI__ | $CC_FOR_BUILD -E - 2>/dev/null \
	    | grep -q __ARM_EABI__
	then
	    echo ${UNAME_MACHINE}-unknown-linux-${LIBC}
	else
	    if echo __ARM_PCS_VFP | $CC_FOR_BUILD -E - 2>/dev/null \
		| grep -q __ARM_PCS_VFP
	    then
		echo ${UNAME_MACHINE}-unknown-linux-${LIBC}eabi
	    else
		echo ${UNAME_MACHINE}-unknown-linux-${LIBC}eabihf
	    fi
	fi
	exit ;;
--8<---------------cut here---------------end--------------->8---

     Mark

Re: Pass --build=<triplet> to native builds by default?

[Mark H Weaver]

Mark H Weaver <mhw@netris.org> writes:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver <mhw@netris.org> skribis:
>>
>>> It turns out that on ARM systems, the result of 'config.guess' depends
>>> on the result of 'uname -m'.  In other words, details of the kernel (and
>>> perhaps processor?) on the build machine will determine the triplet of
>>> our builds, which in turn may affect what set of instructions is used.
>>
>> Do you know how the ‘uname -m’ output is used in config.guess?  What
>> does it return on ARM?
>
> The output of 'uname -m' becomes the first (cpu) component of the GNU
> triplet.  uname(1) gets its information from the kernel via the uname(2)
> system call.  The field returned by 'uname -m' is described as "Hardware
> identifier".  See <http://man7.org/linux/man-pages/man2/uname.2.html>.
>
> Here's the relevant section of config.guess from gcc-4.8.4:
>
>     arm*:Linux:*:*)
> 	eval $set_cc_for_build
> 	if echo __ARM_EABI__ | $CC_FOR_BUILD -E - 2>/dev/null \
> 	    | grep -q __ARM_EABI__
> 	then
> 	    echo ${UNAME_MACHINE}-unknown-linux-${LIBC}
> 	else
> 	    if echo __ARM_PCS_VFP | $CC_FOR_BUILD -E - 2>/dev/null \
> 		| grep -q __ARM_PCS_VFP
> 	    then
> 		echo ${UNAME_MACHINE}-unknown-linux-${LIBC}eabi
> 	    else
> 		echo ${UNAME_MACHINE}-unknown-linux-${LIBC}eabihf
> 	    fi
> 	fi
> 	exit ;;

I forgot to answer your second question.  On my Novena, 'uname -m'
returns "armv7l".  The problem is this: I suspect that if the build
machine has an armv8 processor, it will return something different like
"armv8l".

      Mark

Re: Pass --build=<triplet> to native builds by default?

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> Mark H Weaver <mhw@netris.org> writes:
>
>> ludo@gnu.org (Ludovic Courtès) writes:
>>
>>> Mark H Weaver <mhw@netris.org> skribis:
>>>
>>>> It turns out that on ARM systems, the result of 'config.guess' depends
>>>> on the result of 'uname -m'.  In other words, details of the kernel (and
>>>> perhaps processor?) on the build machine will determine the triplet of
>>>> our builds, which in turn may affect what set of instructions is used.
>>>
>>> Do you know how the ‘uname -m’ output is used in config.guess?  What
>>> does it return on ARM?
>>
>> The output of 'uname -m' becomes the first (cpu) component of the GNU
>> triplet.  uname(1) gets its information from the kernel via the uname(2)
>> system call.  The field returned by 'uname -m' is described as "Hardware
>> identifier".  See <http://man7.org/linux/man-pages/man2/uname.2.html>.
>>
>> Here's the relevant section of config.guess from gcc-4.8.4:
>>
>>     arm*:Linux:*:*)
>> 	eval $set_cc_for_build
>> 	if echo __ARM_EABI__ | $CC_FOR_BUILD -E - 2>/dev/null \
>> 	    | grep -q __ARM_EABI__
>> 	then
>> 	    echo ${UNAME_MACHINE}-unknown-linux-${LIBC}
>> 	else
>> 	    if echo __ARM_PCS_VFP | $CC_FOR_BUILD -E - 2>/dev/null \
>> 		| grep -q __ARM_PCS_VFP
>> 	    then
>> 		echo ${UNAME_MACHINE}-unknown-linux-${LIBC}eabi
>> 	    else
>> 		echo ${UNAME_MACHINE}-unknown-linux-${LIBC}eabihf
>> 	    fi
>> 	fi
>> 	exit ;;
>
> I forgot to answer your second question.  On my Novena, 'uname -m'
> returns "armv7l".  The problem is this: I suspect that if the build
> machine has an armv8 processor, it will return something different like
> "armv8l".

But how do the armv7 and armv8 ISAs differ?  If it’s more like
additional SIMD extensions, then indeed it would make sense to use the
same name for both; but if there’s more than that, perhaps using
different triplets is the right thing?

Ludo’.

Re: Pass --build=<triplet> to native builds by default?

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> Mark H Weaver <mhw@netris.org> writes:
>>
>>> ludo@gnu.org (Ludovic Courtès) writes:
>>>
>>>> Mark H Weaver <mhw@netris.org> skribis:
>>>>
>>>>> It turns out that on ARM systems, the result of 'config.guess' depends
>>>>> on the result of 'uname -m'.  In other words, details of the kernel (and
>>>>> perhaps processor?) on the build machine will determine the triplet of
>>>>> our builds, which in turn may affect what set of instructions is used.
>>>>
>>>> Do you know how the ‘uname -m’ output is used in config.guess?  What
>>>> does it return on ARM?
>>>
>>> The output of 'uname -m' becomes the first (cpu) component of the GNU
>>> triplet.  uname(1) gets its information from the kernel via the uname(2)
>>> system call.  The field returned by 'uname -m' is described as "Hardware
>>> identifier".  See <http://man7.org/linux/man-pages/man2/uname.2.html>.

[...]

>> I forgot to answer your second question.  On my Novena, 'uname -m'
>> returns "armv7l".  The problem is this: I suspect that if the build
>> machine has an armv8 processor, it will return something different like
>> "armv8l".
>
> But how do the armv7 and armv8 ISAs differ?  If it’s more like
> additional SIMD extensions, then indeed it would make sense to use the
> same name for both; but if there’s more than that, perhaps using
> different triplets is the right thing?

Using different triplets depending on the architecture revision of the
CPU in the build machine?  I thought we were aiming for deterministic
builds.

I may not have explained the issue clearly.  Please let me try again.

I don't see why it matters how the ISAs differ.  The important point is
that a build process may intentionally produce different build outputs
when the triplet is armv8l-* vs armv7l-*.

Even if we didn't care about deterministic builds, there's a more
serious problem.  Packages built for armv8l are free to use armv8 ISA
extensions that do not work at all on an armv7l processor.

As things stand now, we must ensure that none of our build machines
implement ISA extensions beyond the baseline requirements we've chosen
for armhf-linux.

      Mark

Re: Pass --build=<triplet> to native builds by default?

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver <mhw@netris.org> skribis:
>>
>>> Mark H Weaver <mhw@netris.org> writes:
>>>
>>>> ludo@gnu.org (Ludovic Courtès) writes:
>>>>
>>>>> Mark H Weaver <mhw@netris.org> skribis:
>>>>>
>>>>>> It turns out that on ARM systems, the result of 'config.guess' depends
>>>>>> on the result of 'uname -m'.  In other words, details of the kernel (and
>>>>>> perhaps processor?) on the build machine will determine the triplet of
>>>>>> our builds, which in turn may affect what set of instructions is used.
>>>>>
>>>>> Do you know how the ‘uname -m’ output is used in config.guess?  What
>>>>> does it return on ARM?
>>>>
>>>> The output of 'uname -m' becomes the first (cpu) component of the GNU
>>>> triplet.  uname(1) gets its information from the kernel via the uname(2)
>>>> system call.  The field returned by 'uname -m' is described as "Hardware
>>>> identifier".  See <http://man7.org/linux/man-pages/man2/uname.2.html>.
>
> [...]
>
>>> I forgot to answer your second question.  On my Novena, 'uname -m'
>>> returns "armv7l".  The problem is this: I suspect that if the build
>>> machine has an armv8 processor, it will return something different like
>>> "armv8l".
>>
>> But how do the armv7 and armv8 ISAs differ?  If it’s more like
>> additional SIMD extensions, then indeed it would make sense to use the
>> same name for both; but if there’s more than that, perhaps using
>> different triplets is the right thing?

[...]

> I don't see why it matters how the ISAs differ.  The important point is
> that a build process may intentionally produce different build outputs
> when the triplet is armv8l-* vs armv7l-*.

What I meant to say is that “x86_64” is pretty vague and doesn’t specify
extensions, but GMP’s sophisticated config.guess is able to determine
the available extensions using /proc/cpuinfo and similar tricks.  Yet,
we’re fine calling all the variants “x86_64” in practice.

In fact, it may be that:

  personality (PER_LINUX32_3GB)

on an armv8 machine enters pure armv7 mode.

What does “linux32 uname -m” return on armv8?

> Even if we didn't care about deterministic builds, there's a more
> serious problem.  Packages built for armv8l are free to use armv8 ISA
> extensions that do not work at all on an armv7l processor.
>
> As things stand now, we must ensure that none of our build machines
> implement ISA extensions beyond the baseline requirements we've chosen
> for armhf-linux.

OK, understood.

Thanks,
Ludo’.