weird sigill's ... anyone tried recent stage3 on old x86 hw?

[eccerr0r]

Weird...
Recently I've been building my x86 VM with CFLAGS="(possibly -m32) -mtune=i686 (or -march=i686) -O2 -pipe" in case I would need to transfer to a physical x86 box. I used the binaries for the install and swiped the binaries for my custom initramfs. I also had another x86 stage4 build that I maintained in a VM with xfce4.

Well, I wanted to see what my P2 would do with a modern up-to-date Gentoo...
IT SIGILLs on boot! Didn't seem to get into my initramfs so I assume the initramfs is tainted.

Tried the same install my Athlon XP (Barton).
IT SIGILLs too!

I found an old Gentoo install that I stopped using in 2015-ish and that machine booted on the Athlon XP just fine. I tried mounting the questionable hard disk and tried chrooting into it...

IT SIGILLs! (as soon as I pressed a button, usually; sometimes it sigills right away.) However if I run the binary by itself, it's fine - so something to do with libraries most likely, possibly libreadline. But an initial library path didn't seem to affect it...though I need to experiment with it some more to see where the illegal instruction is. Odd I didn't get a warning in dmesg.

Interesting. Wonder if anyone has tried old boxes recently? I'm currently trying to download another fresh stage3 and see what it does on the old Athlon and P2... Too bad I don't have a functional P4 anymore to help prove one way or another, though these installs seem to run fine on core2.

---

I have a feeling that -m32 might be causing problems, but haven't pinpointed where and what instructions are being fed into my distcc farm. I've been using -m32 as my 32/64 distcc boxes have been returning 64-bit object files to my 32-bit machines, and this might have some side effect I'm not aware of...

https://forum.osdev.org/viewtopic.php?f=1&t=44509&start=0

Now if this is the problem, how to work around, or perhaps I have to stop using distcc or perhaps have to somehow force portage to specify the whole i686-pc-gnu-linux-gcc instead of just gcc to the distcc hosts?
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[Hu]

If you can get a disassembly of the faulting instruction, that may help us understand their origin.

Yes, Portage ought to be invoking gcc locally using the qualified name i686-pc-linux-gnu-gcc, which should then work when passed to the build helpers. If it does not use the qualified name, then that is a bug in the ebuild or the upstream build system.

[eccerr0r]

Still not sure which file contains the offending opcode... but clearly my VM is infected with files that have non base-x86 opcodes...just not sure where it's coming from despite trying to re-emerge without -m32 and without -march ...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[Hu]

For the chroot case, can you get the kernel to write a core dump from the SIGILL, and then use gdb (possibly on a more current / capable system) to analyze that core file?