Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 17 Jun 2002 09:09:31 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 17 Jun 2002 09:09:30 -0400 Received: from chaos.analogic.com ([204.178.40.224]:9346 "EHLO chaos.analogic.com") by vger.kernel.org with ESMTP id ; Mon, 17 Jun 2002 09:09:30 -0400 Date: Mon, 17 Jun 2002 09:11:19 -0400 (EDT) From: "Richard B. Johnson" Reply-To: root@chaos.analogic.com To: Emmanuel Michon cc: linux-kernel@vger.kernel.org Subject: Re: binary compatibity (mixing different gcc versions) in modules In-Reply-To: <7w3cvmdquu.fsf@avalon.france.sdesigns.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1988 Lines: 53 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/