From: michaels@jungo.com
To: Keith Owens <kaos@melbourne.sgi.com>
Cc: Tom Appermont <tea@sonycom.com>, linux-mips@oss.sgi.com
Subject: Re: ELF header kernel module wrong?
Date: Mon, 26 Feb 2001 13:17:42 +0200 [thread overview]
Message-ID: <3A9A3B56.B0141D21@jungo.com> (raw)
In-Reply-To: 11701.983148650@kao2.melbourne.sgi.com
Keith,
If what you say is correct, then any module created by this toolchain
would be impossible to 'insmod', and that is not the case. As I said, we
have one module which we managed to install, and it was compiled with
exactly the same toolchain. The module is quite large, has a lot of
symbols, and was NOT taken from the kernel tree. I would suspect that
there is some problem with kernel module linkage that is incompatible
with mips toolchain.
Besides that, in "old" modultils there IS a check for symtab size, and
it did work as expected. So, what you say is only part of the truth.
Keith Owens wrote:
>
> On Sun, 25 Feb 2001 11:06:29 +0200,
> michaels@jungo.com wrote:
> >I have seen this problem too. My kernel is 2.2.14 though, using modutils
> >2.3.x.
> >I tried to do many things with modutils, tried even not to check the
> >boundary, but that caused crashes. The only solution that worked for me
> >was to step downwards to modutils 2.2.2. Even then, depmod segfaults
> >unless you put a remark on obj_free in some place... Hope you get a
> >better solution.
>
> All you are doing by using old modutils is hiding the problem and
> risking storage corruption. modutils follows the ELF specification
>
> "A symbol table section's sh_info section header member holds the
> symbol table index for the first non-local symbol."
>
> The mips toolchain is generating local symbols with index numbers
> greater than sh_info. Old modutils did not check for that and silently
> created corrupt modules. New modutils check this field for
> correctness. Fix the mips toolchain.
--
Sincerely yours,
Michael Shmulevich
______________________________________
Software Developer
Jungo - R&D
email: michaels@jungo.com
web: http://www.jungo.com
Phone: 1-877-514-0537(USA) +972-9-8859365(Worldwide) ext. 233
Fax: 1-877-514-0538(USA) +972-9-8859366(Worldwide)
next prev parent reply other threads:[~2001-02-26 11:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-02-23 14:13 ELF header kernel module wrong? Tom Appermont
2001-02-23 17:20 ` Jun Sun
2001-02-23 18:13 ` Tom Appermont
2001-02-25 9:06 ` michaels
2001-02-26 0:50 ` Keith Owens
2001-02-26 11:17 ` michaels [this message]
2001-02-26 23:39 ` Keith Owens
2001-02-26 18:07 ` Brady Brown
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=3A9A3B56.B0141D21@jungo.com \
--to=michaels@jungo.com \
--cc=kaos@melbourne.sgi.com \
--cc=linux-mips@oss.sgi.com \
--cc=tea@sonycom.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.