It appears that the stage3-i486-20180423T214502Z.tar.xz autobuild tarball does not work properly on a K6-233. gcc and a few other programs report "invalid instruction" when they are run. Currently I have found that gcc and groff seem to not work properly. I have not gotten an instruction trace to see what it's trying to execute, alas, I'll need to figure out how to build gdb on this machine. # gcc Illegal instruction # groff Illegal instruction # nroff /usr/bin/nroff: line 136: 2251 Illegal instruction PATH="$GROFF_RUNTIME$PATH" groff -mtty-char $T $opts ${1+"$@"} # uname -rmsv Linux 3.4.110 #1 Tue Feb 16 10:49:01 MST 2016 i586
I'm not saying there is no bug here, but FWIW I'm not able to reproduce this problem on a qemu with "-cpu 486" or "-cpu pentium". I'd be very curious to see what the bad instruction is, afaik that K6 should support a superset of what i486 does.
Indeed, I did a cursory validation of my install in qemu with -cpu 486 to ensure booting. I also did not observe this issue on qemu, but saw it on real hardware. So the easy solution: I tried to build gdb through QEMU... Except I see this while running emerge gdb with CFLAGS="-Os -march=i486 -pipe": i486-pc-linux-gnu-g++ -O2 -march=i686 -pipe -I. -I. ... This will probably not turn out well once I move this to real hardware. I can't think of any other ways real quick to get the offending instruction, have any hints?
Ignore that last comment about CFLAGS - I did not have CXXFLAGS set in /etc/make.conf (it was picking up default) as it probably uses that for C++. Will try this version once I get a chance to move to the real hardware.
Yikes, since catalyst no longer writes CXXFLAGS="${CFLAGS}" to make.conf, the profile's i686 flags get applied
A bit of related info here, as to why CXXFLAGS is missing and how we can fix it https://bugs.gentoo.org/575446#c4
Setting CXXFLAGS to -march=486 still seemed to generate a bad binary or at least has something to do with a library somewhere. While gdb itself will illegal instruction, I was able to finally get a dump from gdb groff: 0x8000d1a8 <+24>: test %eax,%eax => 0x8000d1aa <+26>: cmove %edx,%eax 0x8000d1ad <+29>: mov %eax,(%esp) Yes it's compiled wrong, cmove was introduced on the PPro it seems. https://en.wikipedia.org/wiki/X86_instruction_listings#Added_with_Pentium_Pro Root cause determined.
Did you rebuild the entire stage3 (eg emerge -e @world) with the new proper cflags?
Not yet. I was hoping to collect data before doing an empty world rebuild that would ideally fix the problem. Will start that soon, hopefully the i7 won't take too long to complete this in QEMU or chroot (though I'm quite hesitant doing it in chroot...)
Okay, for a rush job I ended up rebuilding with the i7 with CXXFLAGS=-march=486. It looks like gcc and groff are working now, but gdb is still broken, perhaps more broken than before. The gdb brokenness is probably outside the scope of this bug however, but it would make debug more difficult.
After a self-hosting build (i.e., using the K6 itself to build gdb - took overnight) I have a fully working machine: gdb now works. Still some leakage of processor capabilities into the build environment it seems. I wish things like -march=native is never assumed. Other than getting the autobuilder to build working i486 tarballs, at least for me I'm good and running now. Thanks.
I think this should be fixed in http://distfiles.gentoo.org/releases/x86/autobuilds/20181019T143649Z/stage3-i486-20181019T143649Z.tar.xz , are you able to test?
I dumped it on my server, nfs mounted it, and chrooted to it - hopefully this is sufficient: littlefoot ~ # uname -a Linux littlefoot 3.4.110 #1 Tue Feb 16 10:49:01 MST 2016 i586 GNU/Linux littlefoot ~ # mount subaru:/raid/tmp/1 /mnt0 littlefoot ~ # chroot /mnt0 littlefoot / # echo 'main(){printf("Hello World.\n");}' > /tmp/foo.c littlefoot / # gcc -o /tmp/fff /tmp/foo.c /tmp/foo.c:1:8: warning: incompatible implicit declaration of built-in function ‘printf’ /tmp/foo.c:1:8: note: include ‘<stdio.h>’ or provide a declaration of ‘printf’ littlefoot / # /tmp/fff Hello World. littlefoot / # groff < /dev/null littlefoot / # Looks like it's working now, at least these commands no longer SIGILL! Thanks! I think this probably can be marked resolved now if you feel that this should "stick". Then again, it's hard to hit a moving target...
Yep this change will stick, it was a regression in catalyst-3.x (from 2.x), fixed in 3.0.3. Thanks for testing!
