mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

             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®