Illegal instruction trap in libgcc_s.so

Jarle Greipsland <jarle <at> uninett.no>
2015-02-06 17:05:32 GMT

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

Urgent

Ms. Zou <payout1 <at> mail.com>
2015-01-08 18:10:38 GMT

Good-day
My name is Ms. Zou from Taiwan, i will like to make an inquiry on your product please inform me on (minimum and
maximum order quantity and latest product catalog) Send it asap so that we can place a trial order.
Regards.
Ms. Zou
Sales manager.

i386 boot1.c peculiarity while studying code

William D. Jones <thor0505 <at> comcast.net>
2015-01-07 19:39:11 GMT

Hello all,
Just for the sake of studying the source code, I'm looking over NetBSD's
boot process for i386 (in sys/arch/i386/stand). So far I'm not having too
much trouble, but one thing that is bothering me is the code that attempts
to open() the boot directory.
From what I understand, pbr.S, label.S, bootxx.S, and boot1.c all get linked
into a filesystem-dependent binary file that becomes the bootsector of a
hard disk or a floppy drive; Sector 0 belongs to pbr.S (what the MBR code
jumps to), Sector 1 belongs to label.S, and Sectors 2-15 belong to
everything else. On line 59 of boot1.c, there is an open "system call". From
what I can gather, this open function actually calls a dummy label in
bootxx.S, after initial setup, that JMPs unconditionally to file system
driver code in libsa. The filesystem driver actually loaded is based on
Makefile defines, so multiple bootloaders are created based upon the
kernel's destination filesystem.
However, boot1.c proper calls a wrapper function for open ob() three times:
line 80, 90, and 106. The ob() wrapper takes no arguments, does not access
global state, and hence open() always receives constant parameters "boot".
Between the calls, some static (keyword!) data structures are manipulated to
increment the sector at which to open the file. But since these data
structures are static, I'm having trouble visualizing how the filesystem
code eventually called by open() knows what region of the boot media to try
next. It seems like all three calls are redundant, since there's no state
changes that I'm aware of. So, does each call to open() actually check a
different region (sector) of the boot media? Am I missing a piece of
information or global state that libsa's filesystem drivers are aware of?
I'm a bit hung up on this, and I'd appreciate any help someone who has