From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by oss.sgi.com id ; Mon, 23 Oct 2000 15:38:15 -0700 Received: from gatekeep.ti.com ([192.94.94.61]:55454 "EHLO gatekeep.ti.com") by oss.sgi.com with ESMTP id ; Mon, 23 Oct 2000 15:38:12 -0700 Received: from dlep8.itg.ti.com ([157.170.134.88]) by gatekeep.ti.com (8.11.0/8.11.0) with ESMTP id e9NMc6f18402; Mon, 23 Oct 2000 17:38:06 -0500 (CDT) Received: from dlep8.itg.ti.com (localhost [127.0.0.1]) by dlep8.itg.ti.com (8.9.3/8.9.3) with ESMTP id RAA21101; Mon, 23 Oct 2000 17:38:05 -0500 (CDT) Received: from dlep3.itg.ti.com (dlep3-maint.itg.ti.com [157.170.133.16]) by dlep8.itg.ti.com (8.9.3/8.9.3) with ESMTP id RAA21092; Mon, 23 Oct 2000 17:38:05 -0500 (CDT) Received: from ti.com (IDENT:bbrown@bbrowndt.sc.ti.com [158.218.100.180]) by dlep3.itg.ti.com (8.9.3/8.9.3) with ESMTP id RAA23723; Mon, 23 Oct 2000 17:38:04 -0500 (CDT) Message-ID: <39F4BEDA.C7A7D956@ti.com> Date: Mon, 23 Oct 2000 16:42:34 -0600 From: Brady Brown Organization: Texas Instruments X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jun Sun CC: Keith Owens , linux-mips@oss.sgi.com Subject: Re: problems with insmod ... References: <8345.972101539@ocs3.ocs-net> <39F48742.933941B8@mvista.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-mips@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-mips-outgoing Jun Sun wrote: > Keith Owens wrote: > > > > On Fri, 20 Oct 2000 19:50:03 -0700, > > Jun Sun wrote: > > >I am using modutils v2.1.121, generated by binutils 2.8.1/egcs > > >v1.0.3a/glibc 2.0.6. > > > > > >BTW, I seem to remember someone said the modutils 2.1.121 is not good > > >MIPS. Which version is good? > > > > 2.1.121 is over two years old and is missing several mips patches. > > There is no good reason to use 2.1.121, modutils 2.3 is backwards > > compatible. > > > > The last mips specific patch was in modutils 2.3.15. 2.3.18 ignores > > empty relocate sections which I believe were a problem for several > > architectures, possibly including mips. 2.3.19 will be released this > > weekend and includes a mips patch to fix a minor problem which I doubt > > anybody has ever hit. If you need modutils now, use 2.3.18, if you can > > wait 48 hours, wait for 2.3.19. > > > > ftp://ftp..kernel.org/pub/linux/kernel/utils/modutils/v2.3. > > I tried with 2.3.19, and now I am having problem with out of bound index > in symbol table. See the output below. > > --------- > sh-2.03# insmod hello.o > hello.o: local symbol gcc2_compiled. with index 10 exceeds > local_symtab_size 10 > hello.o: local symbol __gnu_compiled_c with index 11 exceeds > local_symtab_size 10 > hello.o: local symbol __module_kernel_version with index 12 exceeds > local_symtab_size 10 > --------- > > I took a look. It appears that there is bug fix in v2.3.19 that checks > the symbol index against the table size, which in turn discovers this > bug. > > Is this a ld bug? The sh_info field is indeed 10, but there are more > symbols. > > I included the symbol table below, and the command line that I generate > the module. > > ---------- > SYMBOL TABLE: > 00000000 l d .modinfo 00000000 > 00000000 l d .rodata 00000000 > 00000000 l d .text 00000000 > 00000000 l d .data 00000000 > 00000000 l d .bss 00000000 > 00000000 l d *ABS* 00000000 > 00000000 l d *ABS* 00000000 > 00000000 l d .note 00000000 > 00000000 l d .comment 00000000 > 00000000 l .text 00000000 gcc2_compiled. > 00000000 l .text 00000000 __gnu_compiled_c > 00000000 l O .modinfo 0000001b __module_kernel_version > 00000000 g F .text 00000048 init_module > 00000000 O *UND* 00000000 printk > 00000048 g F .text 00000040 cleanup_module > ----------- > > Make command: > > mips_5000_le-gcc -Wall -DMODULE -D__KERNEL__ -DLINUX -fno-pic -c hello.c > > Jun There is a known issue right now with the .elf format generated by the mips assembler. The assembler has the local symbol table ordering and size field out of sync, consequently when insmod tries to install it, it fails because there are more local symbols in the file than the 'inf' field in the file header indicates. I think this is being looked into. As a 'dirty' work around - the linker does appear to generate correct elf outputs so I am currently linking all of my modules using the -r command line switch so the output remains re-locatable. The readelf utility shows the symbol table stuff if you are interested. After the incremental link the files insmod's fine. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Brady Brown (bbrown@ti.com) Work:(801)619-6103 Texas Instruments: Broadband Access Group ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~