All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: linuxppc-dev@ozlabs.org
Cc: Steve Munroe <sjmunroe@us.ibm.com>,
	Ulrich Weigand <Ulrich.Weigand@de.ibm.com>,
	Paul Mackerras <paulus@samba.org>,
	Anton Blanchard <anton@samba.org>
Subject: Re: Saving to 32 bits of GPRs in signal context
Date: Tue, 29 May 2007 16:28:35 +0200	[thread overview]
Message-ID: <200705291628.35852.arnd@arndb.de> (raw)
In-Reply-To: <08b3997ab86a819c63b5cb0afcdc0c9e@kernel.crashing.org>

On Tuesday 29 May 2007, Segher Boessenkool wrote:
> > But it also makes me wonder about a few things:
> > - do you use the standard 32 bit ABI, in which case the caller of 
> > libraries
> >   does not care and the libraries can be put in the standard places,
> 
> The compiler should either a) use full 64-bit only for
> "volatile" (call-clobbered) registers, or b) save and
> restore other 64-bit mode registers around calls.  I don't
> remember if powerpc-linux-gcc does a) or b), if either.

As benh explained, the 64 bit register contents are maintained
over normal function calls, iirc the ABI treats the upper halves
of each register as call-clobbered.

The problem is really just signal handlers.

> > or are
> >   there cases where the ability to pass 64 bit values in a single
> >   register would improve performance to the point that it is worth
> >   having an incompatible library (where to put it and how to name it)?
> 
> That would be a third ABI.  Is it worth that?

no ;-)

> > - how can an application know that it can use 64 bit registers and call
> >   the optimized routines?
> 
> Just call them and trap the SEGV ;-)  You can check the
> aux vector of course, or ask glibc -- but the SEGV way
> is the only really portable way.  Strange world :-)

shouldn't that be SIGILL?

> > As long
> > as such an option does not exist, the usefulness of this feature is
> > somewhat limited. In other words, GCC for now has support for ILP32 and
> > LP64 modes, but it would be better to also have support for IP32L64.
> 
> ILP32LL64.  The C "mode" stays the same, only the generated
> machine insns are changed.

right, as mentioned before, IP32L64 would imply introducing a new
ABI, which we don't want.
 
	Arnd <><

  reply	other threads:[~2007-05-29 14:28 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-29  7:24 Saving to 32 bits of GPRs in signal context Benjamin Herrenschmidt
2007-05-29  7:52 ` Dan Malek
2007-05-29  8:05   ` Benjamin Herrenschmidt
2007-05-29  9:26     ` Gabriel Paubert
2007-05-29  9:44       ` Benjamin Herrenschmidt
2007-05-29 13:12         ` Segher Boessenkool
2007-05-29 14:00           ` Steve Munroe
2007-05-29 14:08             ` Ulrich Weigand
2007-05-29 14:17               ` Kumar Gala
2007-05-29 14:38                 ` Segher Boessenkool
2007-05-29 19:04                   ` Becky Bruce
2007-05-30 10:04                     ` Christoph Hellwig
2007-05-30 12:13                       ` Kumar Gala
2007-05-30 12:30                     ` Segher Boessenkool
2007-05-29 14:31               ` Segher Boessenkool
2007-05-29 14:51               ` Steve Munroe
2007-05-29 21:44                 ` Benjamin Herrenschmidt
2007-05-29 23:16                   ` Steve Munroe
2007-05-29 23:19                     ` Benjamin Herrenschmidt
2007-05-30  7:34                     ` Hiroyuki Machida
2007-05-30 11:40                   ` Segher Boessenkool
2007-05-30 11:48                     ` Benjamin Herrenschmidt
2007-05-30  3:37                 ` Paul Mackerras
2007-05-30  5:32                   ` Kumar Gala
2007-05-30 11:44                     ` Benjamin Herrenschmidt
2007-05-30 12:15                       ` Kumar Gala
2007-05-30 12:48                         ` Hiroyuki Machida
2007-05-30 12:58                           ` Benjamin Herrenschmidt
2007-05-30 18:09                             ` Steve Munroe
2007-05-30 21:02                       ` Gabriel Paubert
2007-05-30 21:41                         ` Steve Munroe
2007-05-30 12:01                     ` Segher Boessenkool
2007-05-30 11:59                   ` Segher Boessenkool
2007-05-30 12:01                     ` Benjamin Herrenschmidt
2007-05-30 12:07                       ` Segher Boessenkool
2007-05-30 12:09                         ` Benjamin Herrenschmidt
2007-05-30 12:36                           ` Segher Boessenkool
2007-05-29 14:28             ` Segher Boessenkool
2007-05-29 21:37             ` Benjamin Herrenschmidt
2007-05-29 21:38               ` Benjamin Herrenschmidt
2007-05-29 13:04       ` Segher Boessenkool
2007-05-29 14:28         ` Arnd Bergmann [this message]
2007-05-29 14:43           ` Segher Boessenkool
2007-05-29 15:54             ` Geert Uytterhoeven
2007-05-29 18:48             ` Arnd Bergmann
2007-05-29 21:27         ` Benjamin Herrenschmidt
2007-05-29 21:45           ` Felix Domke
2007-05-30 11:23             ` Benjamin Herrenschmidt
2007-05-30 11:52               ` Felix Domke
2007-05-30 13:14                 ` Segher Boessenkool
2007-05-30 11:54             ` Segher Boessenkool
2007-05-30 12:07               ` Felix Domke
2007-05-31  5:39                 ` Benjamin Herrenschmidt
2007-05-29 13:10     ` Kumar Gala
2007-05-29 21:32       ` Benjamin Herrenschmidt
2007-05-29 23:46         ` Olof Johansson
2007-05-30  0:43           ` Kumar Gala
2007-05-30  2:54             ` Steve Munroe
2007-05-30  5:31               ` Kumar Gala
2007-05-30 19:47                 ` Steve Munroe
2007-05-30 20:52                   ` Olof Johansson
2007-05-30 21:33                     ` Steve Munroe
2007-05-29 13:53 ` Ulrich Weigand

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=200705291628.35852.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=Ulrich.Weigand@de.ibm.com \
    --cc=anton@samba.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=paulus@samba.org \
    --cc=sjmunroe@us.ibm.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.