Re: Illegal instruction trap in libgcc_s.so

[christos%astron.com@localhost (Christos Zoulas)]

In article <20150206.180532.365546151.jarle%uninett.no@localhost>,
Jarle Greipsland  <jarle%uninett.no@localhost> wrote:
>Hi,
>
>I was in the process of upgrading an old i486-system to a current
>NetBSD/i386 (sources from about January 12th), when bad things
>started to happen.  I had previously built a new kernel,
>installed and booted successfully.  I then started to extract the
>newly built sets, and after having extracted base.tgz, I was in a
>bad place.  All dynamically linked programs core dumped with an
>Illegal instruction trap.  After some investigations I brought
>back an old copy of libgcc_s.so, and things started to work
>again.
>
>I have since set up a gdb sysroot with the required libraries and
>run gdb on /bin/ls with one of the many ls.core files to be
>found.  A printout of my gdb session can be found below.
>
>A few observations:
>o The Illegal instruction is the 'cpuid' instruction, which is not
>  present on older i486 CPUs.
>o The code segment preceeding the spot where things break seems
>  to be from a set of inlined functions found in the compiler's
>  cpuid.h file.  And from the pushfl/popfl patterns the culprit
>  looks likely to be the __get_cpuid_max function.  According to
>  the comments in the source file the preceeding code is there to
>  detect the lack of the cpuid instruction, and then return 0,
>  without ever trying to use the instruction.  Evidently this no
>  longer works correctly.
>o I also note that the variable names used in the inline assembly
>  part of this function (__eax and __ebx), which I would think is
>  meant to indicate the CPU registers in some way, is not the ones
>  that gdb's disassembled code shows as used (eax and edx).  I
>  have no idea whether this is significant or not.
>
>Any thoughts as to why this is happening?

All the code is in /usr/src/external/gpl3/gcc/dist/gcc/config/i386/cpuid.h
Why don't you write a simple program and test it?

christos