Hi,
looking at nvidia proprietary driver, the makefile warns
the user against insmod'ing a module compiled with a gcc
version different from the one that was used to compile
the kernel.
This sounds strange to me, since I never encountered this
problem.
As a counterpart, what I'm sure of, is that you easily get system
crashes when insmod'ing a module resulting of the linking together
(with ld -r) of object files (.o) that were not produced by the same gcc.
Can someone give me a clue on what happens?
Everything is compiled with:
cc
-O2
-DDEBUG=1
-D__KERNEL__
-DMODULE
-fomit-frame-pointer
-fno-strict-aliasing
-fno-common
-pipe
-mpreferred-stack-boundary=2
-Wno-import
-Wimplicit
-Wmain
-Wreturn-type
-Wswitch
-Wtrigraphs
-Wchar-subscripts
-Wuninitialized
-Wparentheses
-Wpointer-arith
-Wcast-align
-fcheck-new
One gcc is
gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98)
the other one is 2.95-2.
Would -O1 be a safer choice?
Sincerely yours,
PS. Let's avoid to fall in a open source vs. binary only dialectics
here, it's not really the point ;-)
--
Emmanuel Michon
Chef de projet
REALmagic France SAS
Mobile: 0614372733 GPGkeyID: D2997E42
On 17 Jun 2002, Emmanuel Michon wrote:
> Hi,
>
> looking at nvidia proprietary driver, the makefile warns
> the user against insmod'ing a module compiled with a gcc
> version different from the one that was used to compile
> the kernel.
>
> This sounds strange to me, since I never encountered this
> problem.
>
> As a counterpart, what I'm sure of, is that you easily get system
> crashes when insmod'ing a module resulting of the linking together
> (with ld -r) of object files (.o) that were not produced by the same gcc.
>
> Can someone give me a clue on what happens?
>
Nothing happens if you don't use -fcaller-saves or some other such
optimization(s). Even -fomit-frame-pointer is safe across called
functions so there should not be a problem mixing and matching.
Note that your 'C' runtime library was probably not created by your
current C Compiler and your user-mode C programs probably run just
fine.
Very old GNU C compilers followed the "M$" convention of prepending
an underscore on a global variable. Therefore "main:" became "_main:".
With such a compiler output, the linker will have trouble.
If you link together certain objects to make a module, you must
ascertain that the objects were produced using the same kernel
structures (read identical kernel version). As an example, the
main module structure, used by the kernel to find out where your
module's procedures are, is called: "struct file_operations".
The first structure member used to be a pointer to lseek(), now
it's an opaque object of type THIS_MODULE.
Imagine the fun if you made a module with this mixup!
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Windows-2000/Professional isn't.
I always compile the nvidia tarball against
whatever kernel I'm running - it has been
quite stable thus used, and I've used it with
stock RH kernels, -ac kernels, -aa kernels
and 2.5 kernels...
Joe
Richard B. Johnson wrote:
>On 17 Jun 2002, Emmanuel Michon wrote:
>
>
>
>>Hi,
>>
>>looking at nvidia proprietary driver, the makefile warns
>>the user against insmod'ing a module compiled with a gcc
>>version different from the one that was used to compile
>>the kernel.
>>
>>This sounds strange to me, since I never encountered this
>>problem.
>>
>>As a counterpart, what I'm sure of, is that you easily get system
>>crashes when insmod'ing a module resulting of the linking together
>>(with ld -r) of object files (.o) that were not produced by the same gcc.
>>
>>Can someone give me a clue on what happens?
>>
>>
>>
>
>Nothing happens if you don't use -fcaller-saves or some other such
>optimization(s). Even -fomit-frame-pointer is safe across called
>functions so there should not be a problem mixing and matching.
>
>Note that your 'C' runtime library was probably not created by your
>current C Compiler and your user-mode C programs probably run just
>fine.
>
>Very old GNU C compilers followed the "M$" convention of prepending
>an underscore on a global variable. Therefore "main:" became "_main:".
>With such a compiler output, the linker will have trouble.
>
>If you link together certain objects to make a module, you must
>ascertain that the objects were produced using the same kernel
>structures (read identical kernel version). As an example, the
>main module structure, used by the kernel to find out where your
>module's procedures are, is called: "struct file_operations".
>The first structure member used to be a pointer to lseek(), now
>it's an opaque object of type THIS_MODULE.
>
>Imagine the fun if you made a module with this mixup!
>
>Cheers,
>Dick Johnson
>
>Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
>
> Windows-2000/Professional isn't.
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
Emmanuel Michon <[email protected]> writes:
> Hi,
>
> looking at nvidia proprietary driver, the makefile warns
> the user against insmod'ing a module compiled with a gcc
> version different from the one that was used to compile
> the kernel.
>
> This sounds strange to me, since I never encountered this
> problem.
Some earlier obsolete gcc versions had problems with empty types. This lead
to an #if based on the compiler version that added a dummy field
to spinlocks even for UP kernels. This made structure offsets of
structures with spinlocks change based on gcc version.
Should be long gone with recent compilers.
Still there are enough other variables to structure offsets depending
on the configuration.
-Andi
On Mon, Jun 17, 2002 at 02:36:25PM +0200, Emmanuel Michon wrote:
> Hi,
>
> looking at nvidia proprietary driver, the makefile warns
> the user against insmod'ing a module compiled with a gcc
> version different from the one that was used to compile
> the kernel.
>
> This sounds strange to me, since I never encountered this
> problem.
Really strange since most of the NVidia driver is binary already.
So another question would be if their binary part is compiled with
the same compiler as you have.
So as most of the other people said it probably doesn't matter but
there is a good chance NVidia is already forcing you to break their
own advice.