[lfs-support] Invalid instruction compiling kernel

Paul Rogers paulgrogers at fastmail.fm
Mon Aug 1 10:41:50 PDT 2016

So -march=i686 wasn't a magic cure-all.  I went back to googling to
more and got here (if any of this triggers an idea, don't hesitate): 


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:
  m32                                   [enabled]
  m80387                                [enabled]
  m96bit-long-double                    [enabled]
  mabi=                                 sysv
  maddress-mode=                        short
  malign-functions=                     0
  malign-jumps=                         0
  malign-loops=                         0
  malign-stringops                      [enabled]
  march=                                pentiumpro   <----
  masm=                                 att
  mbranch-cost=                         0
  mcmodel=                              32
  mfancy-math-387                       [enabled]
  mfentry                               [enabled]
  mfp-ret-in-387                        [enabled]
  mfpmath=                              387          <----
  mglibc                                [enabled]
  mhard-float                           [enabled]
  mieee-fp                              [enabled]
  mincoming-stack-boundary=             0
  mlarge-data-threshold=                0x10000
  mlong-double-80                       [enabled]
  mno-sse4                              [enabled]    <----
  mpreferred-stack-boundary=            0
  mpush-args                            [enabled]
  mred-zone                             [enabled]
  mregparm=                             0
  mstack-protector-guard=               tls
  mstackrealign                         [enabled]
  mstringop-strategy=                   [default]
  mtls-dialect=                         gnu
  mtls-direct-seg-refs                  [enabled]
  mtune=                                generic      <----
  mveclibabi=                           [default]

  Known assembler dialects (for use with the -masm-dialect= option):
        att intel

  Known ABIs (for use with the -mabi= option):
        ms sysv

  Known code models (for use with the -mcmodel= option):
        32 kernel large medium small

  Valid arguments to -mfpmath=:
        387 387+sse 387,sse both sse sse+387 sse,387

  Known vectorization library ABIs (for use with the -mveclibabi=
        acml svml

  Known address mode (for use with the -maddress-mode= option):
        long short

  Known stack protector guard (for use with the -mstack-protector-guard=
        global tls

  Valid arguments to -mstringop-strategy=:
        byte_loop libcall loop rep_4byte rep_8byte rep_byte

  Known TLS dialects (for use with the -mtls-dialect= option):
        gnu gnu2

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:
    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
all on processors other than the one indicated. Specifying
implies -mtune=cpu-type. 
    When used with -march, the Pentium Pro instruction set is used, so
code runs on all i686 family chips. When used with -mtune, it has the
meaning as ‘generic’.
    Tune to cpu-type everything applicable about the generated code,
for the ABI and the set of available instructions. While picking a
cpu-type schedules things appropriately for that particular chip, the
compiler does not generate any code that cannot run on the default
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
is tuned for Pentium 4 but still runs on i686 machines.

    The choices for cpu-type are the same as for -march. In addition,
-mtune supports 2 extra choices for cpu-type:

        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
this option will change. Therefore, if you upgrade to a newer version of
GCC, code generation controlled by this option will change to reflect
processors that are most common at the time that version of GCC is

This all looks OK, but how does one interpret, "code generation
by this option will change to reflect the processors that are most
at the time that version of GCC is released."  Could that possibly mean
that instead of allowing such "changes" I should be specific,

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
take it at its word, then the flaw would be something/somewhere else.
Possibly old i7 host contamination?  Possibly the 3.9.11 kernel
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
flawed by this gcc issue. 8-(

(The cores for PentiumPro, Pentium II, and Pentium /// were all very
the same.  Differences were mostly in cache architecture, MMX/SSE.  It
wasn't until the Pentium 4 that Intel went to the short-lived very deep
20/31-stage core.  I can see mtune might make a difference there.  The
Core-2/i's reverted to 14-stage cores much more like the original 686--
what Intel called the "Left-turn" internally.  So I don't think I'd lose
too much tuning for only a PentiumPro.)

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 - Same, same, but different...

More information about the lfs-support mailing list