binary compatibity (mixing different gcc versions) in modules

binary compatibity (mixing different gcc versions) in modules

[Emmanuel Michon]

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  

Re: binary compatibity (mixing different gcc versions) in modules

[Richard B. Johnson]

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.

Re: binary compatibity (mixing different gcc versions) in modules

[J Sloan]

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 majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>  
>

Re: binary compatibity (mixing different gcc versions) in modules

[Andi Kleen]

Emmanuel Michon <emmanuel_michon@realmagic.fr> 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

Re: binary compatibity (mixing different gcc versions) in modules

[andrew may]

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.