Red Hat Bugzilla – Bug 57413
kernel 2.4.16 compiled by gcc-3.1-10 oopses on boot
Last modified: 2008-05-01 11:38:01 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120
Description of problem:
When I use gcc-3.1-10 to compile stock kernel 2.4.16, the resulting kernel
oopses during booting, just after init is executed. gcc-2.96-101.9
compiles the same kernel tree without any problems.
The earlier gcc3 packages also worked fine.
I will attach the two decoded oopses in do_signal(), the gdb disassembly of
do_signal for the two versions of gcc, and a short diff of the prepocessed
arch/i386/kernal/signal.c file (home of do_signal()). This diff is due to
include/linux/spinlock.h testing the gcc version for 3 or higher, but as I
say, earlier RedHat Rawhide gcc3 versions worked OK.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Compile kernel 2.4.16 with gcc-3.1-10.
2. Boot the new kernel
Actual Results: It oopses during the boot, just after init is started, in
Expected Results: It should not have oopsed. :-) Presumably gcc-3.1.10 is
Thanks to Ben LaHaise for telling me what information to include here.
Created attachment 40387 [details]
See do_signal() at the end of the file
Created attachment 40388 [details]
gdb's dissambly of do_signal() as compiled by gcc-2.96-101.9
Created attachment 40389 [details]
gdb's dissambly of do_signal() as compiled by gcc-3.1-10
Created attachment 40390 [details]
The semantic differences between the cpp output of signal.c for gcc 2.96-101.9 and 3.1-10
Created attachment 40391 [details]
The output of kymoops that started all this, I almost forgot. :-)
I had truouble completing a compile of 2.4.16.
The compile died in the linking stage with some unrecognized
stuff in net/network.o. Unfortunately I did not save the output, but
reinstalled gcc-2.96-101.i386.rpm and the kernel compiled fine.
I have also previously tried gcc3, which worked also.
Created attachment 40467 [details]
This quick patch may solve email@example.com compile problem
The do signal thing is a kernel bug. Using:
asmlinkage int FASTCALL(do_signal(struct pt_regs *regs, sigset_t *oldset));
which is in fact
__attribute__((regparm(0))) int do_signal(struct pt_regs *, sigset_t *) __attribute__((regparm(3)));
means: I really don't care what calling convention will it use, let's see.
Apparently gcc will prefer regparm(0) while older gcc's prefered regparm(3).
Likewise with save_x86_state.
I think gcc is free to pick anything here, gcc documentation never talks about
what is done when conflicting attributes are attached to the same function.
Will post a patch to lkml.
The kernel's declaration of do_signal in arch/i386/kernel/signal.c was fixed in
2.4.18-pre1 and the original problem no longer occurs. So I'm closing this bug,
I hope NOTABUG is the right resolution (since it was a kernel bug, not a gcc bug).