Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 654080 - i486 stage3 components does not run on K6-233
Summary: i486 stage3 components does not run on K6-233
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Release Media
Classification: Unclassified
Component: Stages (show other bugs)
Hardware: x86 Linux
: Normal normal (vote)
Assignee: Gentoo Release Team
URL:
Whiteboard:
Keywords:
Depends on: 469490
Blocks:
  Show dependency tree
 
Reported: 2018-04-25 15:37 UTC by Ben
Modified: 2018-10-22 00:59 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ben 2018-04-25 15:37:25 UTC
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
Comment 1 Ben Kohler gentoo-dev 2018-04-25 18:25:42 UTC
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.
Comment 2 Ben 2018-04-25 19:09:13 UTC
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?
Comment 3 Ben 2018-04-25 19:19:45 UTC
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.
Comment 4 Ben Kohler gentoo-dev 2018-04-25 19:22:45 UTC
Yikes, since catalyst no longer writes CXXFLAGS="${CFLAGS}" to make.conf, the profile's i686 flags get applied
Comment 5 Ben Kohler gentoo-dev 2018-04-25 19:32:09 UTC
A bit of related info here, as to why CXXFLAGS is missing and how we can fix it 
 https://bugs.gentoo.org/575446#c4
Comment 6 Ben 2018-04-26 01:36:33 UTC
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.
Comment 7 Ben Kohler gentoo-dev 2018-04-26 01:46:04 UTC
Did you rebuild the entire stage3 (eg emerge -e @world) with the new proper cflags?
Comment 8 Ben 2018-04-26 02:46:31 UTC
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...)
Comment 9 Ben 2018-04-26 05:32:05 UTC
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.
Comment 10 Ben 2018-04-26 14:16:14 UTC
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.
Comment 11 Ben Kohler gentoo-dev 2018-10-21 16:33:43 UTC
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?
Comment 12 Ben 2018-10-21 21:02:02 UTC
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...
Comment 13 Ben Kohler gentoo-dev 2018-10-22 00:59:34 UTC
Yep this change will stick, it was a regression in catalyst-3.x (from 2.x), fixed in 3.0.3.

Thanks for testing!