From: Keith Owens <kaos@ocs.com.au>
To: "Adam J. Richter" <adam@yggdrasil.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: __ex_table vs. init sections bug in most architectures
Date: Thu, 04 Jul 2002 17:55:40 +1000 [thread overview]
Message-ID: <13382.1025769340@kao2.melbourne.sgi.com> (raw)
In-Reply-To: Your message of "Thu, 04 Jul 2002 00:09:17 MST." <200207040709.AAA05891@adam.yggdrasil.com>
On Thu, 4 Jul 2002 00:09:17 -0700,
"Adam J. Richter" <adam@yggdrasil.com> wrote:
> It looks like all architectures except {sparc,ppc}{,64} rely on
>the __ex_table section already being sorted by the address of the
>instruction that caused the memory access violation that is to be fixed
>up. However, __ex_table will not be constructed in sorted order if it
>includes any references made from an __init or __exit routine, because
>these routines are loaded into the kernel image after all of the other
>routines, rather than being loaded in the order in which they appear in
>each source file.
http://marc.theaimsgroup.com/?l=linux-kernel&m=101912337804026&w=2 and
the following thread. I was going to recode using the ppc insert sort
but got sidetracked.
>One refinement of this
>approach would be have some bfd tool sort __ex_table in vmlinux
>when the kernel is linked, and to do something similar for
>modules, to keep the sort out of the kernel and save a few
>microseconds of run time.
That either requires bfd devel to build the kernel (no chance) or a
program that can cope with cross compilation, including different word
sizes and endianness between the build and target machines. It is
easier and safer to do the sort at boot time then discard the code.
prev parent reply other threads:[~2002-07-04 7:53 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-04 7:09 Adam J. Richter
2002-07-04 7:55 ` Keith Owens [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=13382.1025769340@kao2.melbourne.sgi.com \
--to=kaos@ocs.com.au \
--cc=adam@yggdrasil.com \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®