[lfs-support] Invalid instruction compiling kernel

Paul Rogers paulgrogers at fastmail.fm
Mon Aug 1 15:51:05 PDT 2016

Combining replies to both Ken and WIlliam from today's digest...

> Since you are replying to me, I meant that you didn't tell us the
> exact error message from trying to compile the kernel.  Without that,
> every suggestion will be guesswork.

Ken, I thought an invalid instruction of itself was pretty clear. Either
1) a misconfiguration of the compiler to generate code for a CPU with
   more instructions than a Pentium /// has, or
2) trying to execute arbitrary garbage.

I also thought there might have been some legitimate questions about the
first, but subsequent information seems to suggest the compiler knows
what it's supposed to do.  The second doesn't exactly seem likely since
the same code doesn't produce the same error on a SSE, 64-bit capable
Conroe.  William thinks it's SSE, I'm not so sure it's not 64-bit, but
then I don't understand why it needs gmp at all!

> > I'm thinking it'd be a common problem for many cases of running LFS
> > on a less "capable" CPU, i.e. code built on a 64-bit capable CPU on
> > one that isn't, e.g. P4-Northwood.
> >
> If it was a common problem, I hope we would have heard about it.

Indeed so.  I was hoping you might have.

> That thought occurred to me afterwards, but deliberately building an
> old out-of-support kernel is only desirable if you are debugging a
> problem with a current kernel.

When I'm building a new version I follow the book, using that kernel,
i.e. 3.19.  I always keep that around, though later I may patch up.  I
     did patch this up to 3.19.8, i.e. not beyond the bug-fix territory,
     and that's what I was trying to recompile.

But that box has a 3.9.11 kernel in an earlier system.  You seem to
suggest trying to compile that.  That's an intriguing idea.  I may, just
to see what happens.  Maybe try just compiling something, anything else,
e.g. binutils, just to see if gcc is well and truly broken?

> I don't recall anybody wanting to add -march.  There was at least one

I didn't, initially.  I let the triplet take care of it.

> thread a while ago (probably in the last year) about gmp causing a
> problem, and the answer is to copy the configfsf.{guess,sub} scripts
> over gmp's own config.guess and config.sub.  Probably at least two
> threads, and one of them had a lot of detail along the way.

I'll see if I can find that.

> I haven't had the problem, so I don't know if adding -march will work:
> I've never really understood the details of why gmp is used, but
> telling gcc to create instructions for i686 might not alter what gmp
> is doing.

I recompiled gmp too!  It didn't change anything.  It's beginning to
look like the initial build is compiling PentiumPro code.  Not fast, of
course, but runnable on any i686.

> On reflection, I suggest you rebuild gmp on the i7, using the
> configfsf scripts, but do a DESTDIR install and then copy the DESTDIR
> over to the tualatin).  Then retry the chroot kernel compile.

I've never run into configfsf scripts before.  I'll have to get back to
you on that.

> If it works, this should be quicker than rebuilding gcc.

It didn't take all that long on the i7, though I didn't install dejagnu,
et al, to rerun the whole test suite once again, but I did redo that
last set of toolchain queries.

> I have a Dual P3 1.4GHz Tualatin and the problem will persist because
> i686 also includes those processors with sse2. Use -march=pentium3,
> and also when building GMP on x86_64 to be used with the pentium3, use
> pentium3 as the target ex: ./configure pentium3.

William, not to be argumentative--I'm still feeling my way through this,
trying to understand--but the compiler SAYS it's compiling code for a
PentiumPro and only 387 floating-point.  This was the original Chapter 6
version of gcc which compiled everything else from 6.17 on.  When I
recompiled with -march=i686 explicitly yesterday, I got no better
result.  I do NOT dismiss doing it once more as you suggest.

I certainly have no argument that using pentium3 code would be faster,
and since I skipped the whole Pentium Pro/II generation, the chances I'd
throw this at anything less than a Pentium /// is negligible.  I have in
the back of my mind maybe doing this yet.  Still the gcc-4.9.2 manual
says this OUGHT to work on any i686, and the gcc target seems to confirm
that.  (Yes, we all know documentation is often out of date.)  I'm
trying to keep an open mind about that, taking it at its word for the
moment and trying to entertain the idea it could be something else.

> SSE2/SSE3 is way after pentium 3. Most distros will build minimum of
> i586 for x86, as well. Be very careful, not all i686 are alike. Some
> have sse, sse2, and sse3, while others don't.

Indeed, well aware!  I think I have a Coppermine or two around, and even
a couple little mini-ITX's with C7's.  This is why I'm trying to start
with base i686 compatibility.

> Your illegal instruction is most likely due to sse2.

If so, I really want to understand how it got into my build!  I don't
regard a bug truly fixed until I get the whole picture.

> Even if you include CONFIG_MPENTIUMIII in the kernel config, it still
> relies on a gcc utilizing a gmp built from x86_64 for i686 and not an
> SSE only i686. Maybe you can figure it out, but it really depends on
> GMP at this point.

Then it must be in spite of recompiling it explicitly for a base i686
PPro with CFLAGS=-march=i686.  If that's not explicit enough for gmp...
But that give me a search to try.

> Possibly the 3.9.11 kernel supporting the host I was ssh-ing to and
> chroot-ing?  I guess I can try booting the system on its own and see
> if it's still there--if the whole system wasn't flawed by this gcc
> issue. 8-(

OK, did that.  Failed at exactly the same spot running the 3.19 kernel.
Kinda thought the ssh/chroot wasn't the cause.
Paul Rogers
paulgrogers at fastmail.fm
Rogers' Second Law: "Everything you do communicates."
(I do not personally endorse any additions after this line. TANSTAAFL :-)

http://www.fastmail.com - The way an email service should be

More information about the lfs-support mailing list