Re: Illegal instruction trap in libgcc_s.so

["William D. Jones" <thor0505%comcast.net@localhost>]

Better late than never, but I had been meaning to respond to this. I did a 
fresh install on my 486 recently and am not able to reproduce your issue. 
However, in the case that something similar should go wrong with my install, 
I was wondering if you had any luck fixing your errors with CPUID? I've 
found from experience that sometimes the CPUID instruction leaks into 
userland or the kernel because someone forgot to add 486 guards.

-----Original Message----- 
From: Jarle Greipsland
Sent: Friday, February 06, 2015 12:05 PM
To: port-i386%netbsd.org@localhost
Subject: Illegal instruction trap in libgcc_s.so

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?

-jarle

# gdb
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486--netbsdelf".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) set sysroot /tmp/sysroot
(gdb) file /bin/ls
Reading symbols from /bin/ls...(no debugging symbols found)...done.
(gdb) core /tmp/ls.core
[New process 1]
warning: Can't read pathname for load map: Input/output error.
Core was generated by `ls'.
Program terminated with signal 4, Illegal instruction.
#0  0xbbbca502 in ?? () from /tmp/sysroot/lib/libgcc_s.so.1
(gdb) where
#0  0xbbbca502 in ?? () from /tmp/sysroot/lib/libgcc_s.so.1
#1  0xbbbca578 in __cpu_indicator_init () from 
/tmp/sysroot/lib/libgcc_s.so.1
#2  0xbbbc3938 in ?? () from /tmp/sysroot/lib/libgcc_s.so.1
#3  0xbbbf21c3 in ?? ()
#4  0x00000003 in ?? ()
#5  0xbfbfeb4c in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) x/30i __cpu_indicator_init
  0xbbbca528 <__cpu_indicator_init>:   push   %ebp
  0xbbbca529 <__cpu_indicator_init+1>: push   %edi
  0xbbbca52a <__cpu_indicator_init+2>: push   %esi
  0xbbbca52b <__cpu_indicator_init+3>: push   %ebx
  0xbbbca52c <__cpu_indicator_init+4>: sub    $0x24,%esp
  0xbbbca52f <__cpu_indicator_init+7>:
   call   0xbbbca7be <__x86.get_pc_thunk.bx>
  0xbbbca534 <__cpu_indicator_init+12>:        add    $0x37c0,%ebx
  0xbbbca53a <__cpu_indicator_init+18>:        mov    -0xc(%ebx),%eax
  0xbbbca540 <__cpu_indicator_init+24>:        mov    (%eax),%eax
  0xbbbca542 <__cpu_indicator_init+26>:        test   %eax,%eax
  0xbbbca544 <__cpu_indicator_init+28>:
   je     0xbbbca550 <__cpu_indicator_init+40>
  0xbbbca546 <__cpu_indicator_init+30>:        xor    %eax,%eax
  0xbbbca548 <__cpu_indicator_init+32>:        add    $0x24,%esp
  0xbbbca54b <__cpu_indicator_init+35>:        pop    %ebx
  0xbbbca54c <__cpu_indicator_init+36>:        pop    %esi
  0xbbbca54d <__cpu_indicator_init+37>:        pop    %edi
  0xbbbca54e <__cpu_indicator_init+38>:        pop    %ebp
  0xbbbca54f <__cpu_indicator_init+39>:        ret
  0xbbbca550 <__cpu_indicator_init+40>:        lea    0x14(%esp),%esi
  0xbbbca554 <__cpu_indicator_init+44>:        lea    0x20(%esp),%ecx
  0xbbbca558 <__cpu_indicator_init+48>:        mov    %ecx,0x8(%esp)
  0xbbbca55c <__cpu_indicator_init+52>:        mov    %ecx,0xc(%esp)
  0xbbbca560 <__cpu_indicator_init+56>:        lea    0x1c(%esp),%ebp
  0xbbbca564 <__cpu_indicator_init+60>:        mov    %ebp,0x4(%esp)
  0xbbbca568 <__cpu_indicator_init+64>:        lea    0x18(%esp),%edi
  0xbbbca56c <__cpu_indicator_init+68>:        mov    %edi,(%esp)
  0xbbbca56f <__cpu_indicator_init+71>:        mov    %esi,%edx
  0xbbbca571 <__cpu_indicator_init+73>:        xor    %eax,%eax
  0xbbbca573 <__cpu_indicator_init+75>:        call   0xbbbca4d3
  0xbbbca578 <__cpu_indicator_init+80>:        test   %eax,%eax
(gdb) x/50i 0xbbbca4d3
  0xbbbca4d3:  push   %ebp
  0xbbbca4d4:  push   %edi
  0xbbbca4d5:  push   %esi
  0xbbbca4d6:  mov    %eax,%edi
  0xbbbca4d8:  mov    %edx,%ebp
  0xbbbca4da:  pushf
  0xbbbca4db:  pushf
  0xbbbca4dc:  pop    %eax
  0xbbbca4dd:  mov    %eax,%edx
  0xbbbca4df:  xor    $0x200000,%eax
  0xbbbca4e4:  push   %eax
  0xbbbca4e5:  popf
  0xbbbca4e6:  pushf
  0xbbbca4e7:  pop    %eax
  0xbbbca4e8:  popf
  0xbbbca4e9:  xor    %edx,%eax
  0xbbbca4eb:  and    $0x200000,%eax
  0xbbbca4f0:  je     0xbbbca4fa
  0xbbbca4f2:  xor    %eax,%eax
  0xbbbca4f4:  xchg   %ebx,%esi
  0xbbbca4f6:  cpuid
  0xbbbca4f8:  xchg   %ebx,%esi
  0xbbbca4fa:  cmp    %eax,%edi
  0xbbbca4fc:  ja     0xbbbca524
  0xbbbca4fe:  mov    %edi,%eax
  0xbbbca500:  xchg   %ebx,%esi
=> 0xbbbca502:  cpuid
  0xbbbca504:  xchg   %ebx,%esi
  0xbbbca506:  mov    %eax,0x0(%ebp)
  0xbbbca509:  mov    0x10(%esp),%eax
  0xbbbca50d:  mov    %esi,(%eax)
  0xbbbca50f:  mov    0x14(%esp),%eax
  0xbbbca513:  mov    %ecx,(%eax)
  0xbbbca515:  mov    0x18(%esp),%eax
  0xbbbca519:  mov    %edx,(%eax)
  0xbbbca51b:  mov    $0x1,%eax
  0xbbbca520:  pop    %esi
  0xbbbca521:  pop    %edi
  0xbbbca522:  pop    %ebp
  0xbbbca523:  ret
  0xbbbca524:  xor    %eax,%eax
  0xbbbca526:  jmp    0xbbbca520

--
William D. Jones
thor0505%comcast.net@localhost