From: Miles Bader <miles@lsi.nec.co.jp>
To: Rusty Russell <rusty@rustcorp.com.au>,
Greg Ungerer <gerg@snapgear.com>,
David McCullough <davidm@snapgear.com>
Cc: linux-kernel@vger.kernel.org
Subject: exception tables in 2.5.55
Date: 09 Jan 2003 15:20:41 +0900 [thread overview]
Message-ID: <buo1y3msv2e.fsf@mcspd15.ucom.lsi.nec.co.jp> (raw)
I'm building for the v850, which has no MMU.
Starting with 2.5.55, I'm getting link errors like:
kernel/extable.c:29: undefined reference to `search_extable'
I didn't have to worry about this with earlier kernels, and it looks
like what happened is that previously arch-specific code was
consolidated into the generic kernel.
As far as I can see, the purpose of exception tables is to deal with
unexpected memory access traps and on the v850, this basically can't
happen (there's no MMU, and no way I know of to detect non-existant
memory). So I'd like to make the generic exception handling stuff
optional.
However, I'm not sure the best way to do this -- I could try to make it
dependent on CONFIG_MMU, but are there non-MMU processors that _can_
usefully use exception tables (in which case perhaps there should just
be a separate CONFIG_EXTABLES or something)?
[Oh, and also, please tell me if I'm mistaken about the purpose of
these tables and really _should_ just implement them.]
Thanks,
-Miles
--
Somebody has to do something, and it's just incredibly pathetic that it
has to be us. -- Jerry Garcia
next reply other threads:[~2003-01-09 6:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-09 6:20 Miles Bader [this message]
2003-01-10 8:30 ` Rusty Russell
2003-01-13 3:12 ` Greg Ungerer
2003-01-13 3:24 ` Linus Torvalds
2003-01-13 3:49 ` Greg Ungerer
2003-01-13 5:21 ` Miles Bader
2003-01-13 5:26 ` Rusty Russell
2003-01-13 21:03 ` Horst von Brand
2003-01-14 8:28 ` Rusty Russell
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=buo1y3msv2e.fsf@mcspd15.ucom.lsi.nec.co.jp \
--to=miles@lsi.nec.co.jp \
--cc=davidm@snapgear.com \
--cc=gerg@snapgear.com \
--cc=linux-kernel@vger.kernel.org \
--cc=miles@gnu.org \
--cc=rusty@rustcorp.com.au \
/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®