public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Miles Bader <miles@gnu.org>
To: Greg Ungerer <gerg@snapgear.com>
Cc: Linus Torvalds <torvalds@transmeta.com>,
	Rusty Russell <rusty@rustcorp.com.au>,
	linux-kernel@vger.kernel.org,
	David McCullough <davidm@snapgear.com>
Subject: Re: exception tables in 2.5.55
Date: Mon, 13 Jan 2003 00:21:18 -0500	[thread overview]
Message-ID: <20030113052118.GA4539@gnu.org> (raw)
In-Reply-To: <3E223756.3010200@snapgear.com>

On Mon, Jan 13, 2003 at 01:49:42PM +1000, Greg Ungerer wrote:
> >There are exceptions that have nothing to do with MMU's, and a no-mmu 
> >architecture should still support them.  On x86, we have a number of such 
> >exceptions, for example general protection stuff for wrong values for 
> >special registers etc.
> 
> OK, heres an alternative patch that fully supports exception tables
> for m68knommu (Miles you'll need to do the same for v850).

On the v850, there are, to my knowledge, no usable exceptions (the only such
thing is illegal insn, which shouldn't occur, I think).

The latest patches I already sent to Linus handle this by just making
search_extable an inline in asm/module.h:

   /* We don't do exception tables.  */
   struct exception_table_entry;
   static inline const struct exception_table_entry *
   search_extable(const struct exception_table_entry *first,
		  const struct exception_table_entry *last,
	          unsigned long value)
   {
	   return 0;
   }

This allows gcc to remove a bit of the generic exception-table code, but I
was sort of hoping to have something like CONFIG_EXTABLES to get rid of the
rest of it (or maybe CONFIG_INHIBIT_EXTABLES since most archs want them).

As greg showed, this is simple to do, though I suppose the resulting savings
isn't much, and there are many many other places which might more profitably
be pruned...

[OTOH, little bits do add up, and for some reason this particular bit of code
seems extra gratuitous since it was previously arch-specific and I didn't
have to worry about it]

-Miles 
-- 
"I distrust a research person who is always obviously busy on a task."
   --Robert Frosch, VP, GM Research

  reply	other threads:[~2003-01-13  5:12 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-09  6:20 exception tables in 2.5.55 Miles Bader
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 [this message]
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=20030113052118.GA4539@gnu.org \
    --to=miles@gnu.org \
    --cc=davidm@snapgear.com \
    --cc=gerg@snapgear.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    --cc=torvalds@transmeta.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