[lfs-support] Invalid instruction compiling kernel

Ken Moffat zarniwhoop at ntlworld.com
Mon Aug 1 12:04:39 PDT 2016

On Mon, Aug 01, 2016 at 10:41:50AM -0700, Paul Rogers wrote:
> So -march=i686 wasn't a magic cure-all.  I went back to googling to
> learn
> more and got here (if any of this triggers an idea, don't hesitate): 
> https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/i386-and-x86-64-Options.html

Did you read William's reply yesterday ?

> It occurred to me to try to find out what arguments gcc was actually
> using.  Going back to the first version, running fine on this Conroe,
> elsewhere in this manual I found the following command:
> #> gcc -Q --help=target -c |grep -v "\[disabled\]"
> The following options are target specific:

[ snipping, but thanks for posting the details, they look
interesting - on x86_64 there is much less variation for most of
these things ]
> This seems to verify it's basic code will be compatible with any i686,
> it's using original 387 rather than any SSE, specifically not SSE4 that
> the i7 has.  But possibly that -mtune=generic might be an issue?
> That webpage says:
> ...
> "-march=cpu-type
>     Generate instructions for the machine type cpu-type. In contrast to
> -mtune=cpu-type, which merely tunes the generated code for the specified
> cpu-type, -march=cpu-type allows GCC to generate code that may not run
> at
> all on processors other than the one indicated. Specifying
> -march=cpu-type
> implies -mtune=cpu-type. 
> ...
> ‘i686’
>     When used with -march, the Pentium Pro instruction set is used, so
>     the
> code runs on all i686 family chips. When used with -mtune, it has the
> same
> meaning as ‘generic’.
> ...
> -mtune=cpu-type
>     Tune to cpu-type everything applicable about the generated code,
>     except
> for the ABI and the set of available instructions. While picking a
> specific
> cpu-type schedules things appropriately for that particular chip, the
> compiler does not generate any code that cannot run on the default
> machine
> type unless you use a -march=cpu-type option. For example, if GCC is
> configured for i686-pc-linux-gnu then -mtune=pentium4 generates code
> that
> is tuned for Pentium 4 but still runs on i686 machines.

Yes, -mtune will tune things for the specified cpu-type, but it
won't alter the generated instructions.
>     The choices for cpu-type are the same as for -march. In addition,
> -mtune supports 2 extra choices for cpu-type:
>     ‘generic’
>         Produce code optimized for the most common IA32/AMD64/EM64T
> processors. If you know the CPU on which your code will run, then you
> should use the corresponding -mtune or -march option instead of
> -mtune=generic. But, if you do not know exactly what CPU users of your
> application will have, then you should use this option.
>         As new processors are deployed in the marketplace, the behavior
>         of
> this option will change. Therefore, if you upgrade to a newer version of
> GCC, code generation controlled by this option will change to reflect
> the
> processors that are most common at the time that version of GCC is
> released."
> ...
> This all looks OK, but how does one interpret, "code generation
> controlled
> by this option will change to reflect the processors that are most
> common
> at the time that version of GCC is released."  Could that possibly mean
> that instead of allowing such "changes" I should be specific,
> "-mtune=pentiumpro"?

I think it is to do with the details of which instructions run
fastest on which processor variants.  So -march specifies the
minimum supported CPU, and limits the choice of possible
instructions, but -mtune prefers whichever of the possible
instructions are thought to be fastest on the CPU you specified for
mtune (and they will run, but perhaps much more slowly, on other
CPUs supported by what you specified in -march).

> All that said, the command above suggests even the original gcc I built
> shouldn't have tried to use (or is it just "make"?) an instruction the
> Tualatin couldn't handle, though paradoxically this Conroe can.  If we
> can
> take it at its word, then the flaw would be something/somewhere else.
> Possibly old i7 host contamination?  Possibly the 3.9.11 kernel
> supporting
> the host I was ssh-ing to and chroot-ing?

Both sound unlikely.  'gmp is probably your enemy' ;-)

Why I mentioned memtest86 is because I can recall one time (maybe it
was on my pIII, or more likely on an early AMD x86_64) where things
started to fail when I booted a new LFS system on it (during chroot,
everything had been fine).  And one of the memory sticks had failed,
perhaps in the previous boot the bad part had been used for something
less critical than in the next boot.
>  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-(

That sounds worthwhile.

`I shall take my mountains', said Lu-Tze. `The climate will be good
for them.'     -- Small Gods

More information about the lfs-support mailing list