This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problem Installing Linux Kernel Module compiled with gcc-3.2.x


On Fri, May 30, 2003 at 09:26:51AM -0600, Kendrick Hamilton wrote:
> Hello,
> 	I have a module for a custom developped PCI card. The device 
> driver is written for the Linux 2.4 series kernels. When I build the 
> module and the Linux kernel with gcc-2.95.3, the module installs 
> correctly. When I build the module and the Linux kernel with gcc-3.2.3 
> (also other gcc-3.2.x), the module installs but the Linux kernel crashes 
> in random places outside of the module. Do you have any suggestions of 
> what to look for? I can email you the complete module source code. I have 
> not tried gcc-3.3 because I cannot compile the current Linux kernel with 
> it (there is a known bug that is being fixed and should be out in 
> Linux-2.4.21).

I'm assuming that you get a clean compile with -Wall.  If not, start
by fixing that.

The crashes outside the module might be caused by memory corruption.

When two compilers (2.95.3 and 3.2.3) give you code that produces
different results, there are two possibilities: a compiler bug, or
(more likely) some bug in the source code that results in indeterminate
behavior, like an uninitialized variable, multiple side-effects with
no intervening sequence point, like "a[i++] = i++;", etc.  I say
"more likely" because, while compilers do have bugs, most of the time
the symptoms you describe come from the input to to the compiler.

Also, GCC 3.x does more aggressive optimization based on the ISO C
type-aliasing rules, so if the driver does casts to read, say, int
data as unsigned short (not allowed according to the standard unless
you use unions), the code may malfunction.  If you suspect this, you
can give the -fno-strict-aliasing flag to gcc 3.x.

So, I suggest:
1) try -fno-strict-aliasing
2) read the code, looking for bad stuff

If these fail, and you suspect a compiler bug, you could use a binary
search strategy.  Try to isolate the source file that is miscompiled
(compile that one file with 3.2.3, others with 2.95.3).  If you want,
you could then try to isolate the bad function in that file (by splitting
the file).  At that point, report the bug to the GCC folks (see
http://gcc.gnu.org/ ).



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]