Re: Failure to build go on some 32bit port-i386 machines

[Greg Troxel <gdt%lexort.com@localhost>]

Alexander Schreiber <als%thangorodrim.ch@localhost> writes:

> On Mon, Apr 29, 2024 at 05:21:36PM -0400, Greg Troxel wrote:
>> "Jonathan A. Kollasch" <jakllsch%kollasch.net@localhost> writes:
>> 
>> > https://github.com/prometheus/node_exporter/issues/1568
>> 
>> I guess we should be doing some flavor of that.  I'm fuzzy because my
>> oldest machine is now not so old (only about 20 years), but I think
>> NetBSD/i386 supports 486 and up.  If so, pkgsrc should be fixing the
>> upstream bug of having a newer default and targeting 486.
>
> Grabbed the node_exporter binary package via pkgin and ran it on the
> Alix (AMD Geode LX). Died with SIGILL. So I ran it under gdb until it
> died (during early startup) and looked at the disassembly. It dies
> on:
>  0x08098c9b <+27>:    xorps  %xmm0,%xmm0
>
> Now xorps is Bitwise Logical XOR for Single-FP Values and was apparently
> introduced with the Pentium3, which is much newer than the i586 (OG
> Pentium) baseline that the Geode was built to provide.

Basically you will have to modify go to produce only instructions from
some earlier CPU architecture definition.

> Which would explain this exploding on qemu with -cpu=pentium, but being
> happy with -cpu=n270.
>
> Testing with qemu 9.0.0 and -cpu=pentium3, NetBSD 10.0 and current
> pkgsrc results in the go118 build exploding with SIGILL, specifically
> lang/go118/work/go/pkg/tool/netbsd_386/go_bootstrap. Running under
> gdb and disassembling yields:
>
> => 0x080a5a95 <+21>:    mfence 
>
> and the mfence instruction was introduced with the Pentium4, so of
> course it causes SIGILL on Pentium3.

So therefore go118 requires >= Pentium4.

The naming is very confusing.    As I understand it Pentium 3 and 4 are
within the "Pentium Pro" or P6 family, which I think is "i686" but the
compiler is using instructions valid on only some i686 family members.

> So, it looks like golang on port-i386 class machines (aka 32bit Intel
> and friends, which apparently goes down all the way to the i486) is
> basically no-can-do except for the very latest 32bit Intel CPUs.

I wouldn't call "chips introduced after about 2000" "the very latest"
but I guess your point is that these are the tail end of 32-bit-only
chips.

NetBSD's targeting of i486 is very unusual these days.

> Short of flagging golang as "forget it on port-i386", does anybody
> have any better ideas of making the golang toolchain actually work
> on some of the more, *cough* ancient 32bit Intel CPUs?

I would expect that go in i386 mode works fine when running port-i386 on
a machine which supports x86-64.  But that's not useful for your
situation.

The path to addressing this is to look at the code generation in the go
compiler and probably modify the target description to remove
instrucions that e.g. are not present in the i586/geode, and then debug
what's next.  I expect this to be very hard, but if you want to learn
enough to do it, it's probably quite the project.  It might be less
hard I think, where removing the instructions just works.

I still have one computer that has such a CPU (a soekris net5501) but
it's been powered off for a few years.   I think few people are still
trying to use such machines and this explains why thy the go people
haven't made it work.