Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Brady Brown <bbrown@ti.com>
To: Jun Sun <jsun@mvista.com>
Cc: Keith Owens <kaos@melbourne.sgi.com>, linux-mips@oss.sgi.com
Subject: Re: problems with insmod ...
Date: Mon, 23 Oct 2000 16:42:34 -0600	[thread overview]
Message-ID: <39F4BEDA.C7A7D956@ti.com> (raw)
In-Reply-To: 39F48742.933941B8@mvista.com

Jun Sun wrote:

> Keith Owens wrote:
> >
> > On Fri, 20 Oct 2000 19:50:03 -0700,
> > Jun Sun <jsun@mvista.com> 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.<country>.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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

      parent reply	other threads:[~2000-10-23 22:38 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-10-21  2:50 problems with insmod Jun Sun
2000-10-21  3:11 ` Ralf Baechle
2000-10-21  4:12 ` Keith Owens
2000-10-23 18:45   ` Jun Sun
2000-10-23 22:32     ` Keith Owens
2000-10-24  0:40       ` Ralf Baechle
2000-10-24  1:08         ` Jun Sun
2000-10-24  1:18           ` Ralf Baechle
2000-10-24  1:18             ` Ralf Baechle
2000-10-23 22:42     ` Brady Brown [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=39F4BEDA.C7A7D956@ti.com \
    --to=bbrown@ti.com \
    --cc=jsun@mvista.com \
    --cc=kaos@melbourne.sgi.com \
    --cc=linux-mips@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox