[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
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

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
  mcpu=                                 
  mfancy-math-387                       [enabled]
  mfentry                               [enabled]
  mfp-ret-in-387                        [enabled]
  mfpmath=                              387          <----
  mfused-madd                           
  mglibc                                [enabled]
  mhard-float                           [enabled]
  mieee-fp                              [enabled]
  mincoming-stack-boundary=             0
  mintel-syntax                         
  mlarge-data-threshold=                0x10000
  mlong-double-80                       [enabled]
  mmemcpy-strategy=                             
  mmemset-strategy=                             
  mno-sse4                              [enabled]    <----
  mpreferred-stack-boundary=            0
  mpush-args                            [enabled]
  mrecip=                                       
  mred-zone                             [enabled]
  mregparm=                             0
  msse5                                 
  mstack-protector-guard=               tls
  mstackrealign                         [enabled]
  mstringop-strategy=                   [default]
  mtls-dialect=                         gnu
  mtls-direct-seg-refs                  [enabled]
  mtune-ctrl=                           
  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=
  option):
        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=
  option):
        global tls

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

  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:
...
"-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.

    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"?

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?  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-(

(The cores for PentiumPro, Pentium II, and Pentium /// were all very
much
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