From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Ulrich Drepper <drepper@redhat.com>
Cc: munroesj@us.ibm.com, "H. Peter Anvin" <hpa@zytor.com>,
David Miller <davem@davemloft.net>,
ralf@linux-mips.org, linux-arch@vger.kernel.org,
linux-kernel@vger.kernel.org, kernel@teksavvy.com,
torvalds@linux-foundation.org
Subject: Re: 64-syscall args on 32-bit vs syscall()
Date: Wed, 17 Mar 2010 21:13:45 +1100 [thread overview]
Message-ID: <1268820825.2335.190.camel@pasglop> (raw)
In-Reply-To: <4BA09D5D.5090602@redhat.com>
On Wed, 2010-03-17 at 02:14 -0700, Ulrich Drepper wrote:
> >> I believe that should cover it, at least for powerpc, possibly for
> other
> >> archs too though as I said, I may have missed something there.
>
> How can this possibly be the case? This will screw people who
> currently
> work around the ppc limitations of the existing syscall.
No it won't. As I said, it will work for both cases. The problem is a
register pair alignment problem. If the alignment is corrected with the
trick I proposed, 64-bit values will end up in the right pair, but
manually worked-around cases where the value is already broken up will
-also- end up in the right pair.
The problem with syscall() as it is is that it skews the arguments by 1
register, which causes the compiler to skip a register when generating
the call for a 64-bit value. By doing the trick I propose, that skew
will be gone, both 32 and 64 bit arguments will end up where expected.
Cheers,
Ben.
next prev parent reply other threads:[~2010-03-17 10:14 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-15 4:48 64-syscall args on 32-bit vs syscall() Benjamin Herrenschmidt
2010-03-15 5:06 ` David Miller
2010-03-15 5:18 ` Benjamin Herrenschmidt
2010-03-15 5:54 ` David Miller
2010-03-15 20:22 ` Benjamin Herrenschmidt
2010-03-15 13:44 ` Ralf Baechle
2010-03-15 15:13 ` H. Peter Anvin
2010-03-15 16:00 ` Ulrich Drepper
2010-03-15 19:00 ` David Miller
2010-03-15 19:41 ` H. Peter Anvin
2010-03-15 20:35 ` Benjamin Herrenschmidt
2010-03-15 20:41 ` H. Peter Anvin
2010-03-16 21:56 ` Steven Munroe
2010-03-17 0:31 ` Benjamin Herrenschmidt
2010-03-17 5:52 ` Ulrich Drepper
2010-03-17 8:56 ` Benjamin Herrenschmidt
2010-03-17 9:14 ` Ulrich Drepper
2010-03-17 10:13 ` Benjamin Herrenschmidt [this message]
2010-03-17 9:18 ` Jamie Lokier
2010-03-17 10:18 ` Benjamin Herrenschmidt
2010-03-17 18:30 ` H. Peter Anvin
2010-03-17 20:35 ` Benjamin Herrenschmidt
2010-03-17 20:53 ` H. Peter Anvin
2010-03-17 22:58 ` Benjamin Herrenschmidt
2010-03-18 16:08 ` Steven Munroe
2010-03-18 16:21 ` Andreas Schwab
2010-03-18 17:03 ` Steven Munroe
2010-03-18 21:18 ` Benjamin Herrenschmidt
2010-03-19 1:22 ` Jamie Lokier
2010-03-15 20:27 ` Benjamin Herrenschmidt
2010-03-15 15:03 ` Steven Munroe
2010-03-15 20:32 ` Benjamin Herrenschmidt
2010-03-15 15:04 ` Jamie Lokier
2010-03-15 20:33 ` Benjamin Herrenschmidt
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=1268820825.2335.190.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=davem@davemloft.net \
--cc=drepper@redhat.com \
--cc=hpa@zytor.com \
--cc=kernel@teksavvy.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=munroesj@us.ibm.com \
--cc=ralf@linux-mips.org \
--cc=torvalds@linux-foundation.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 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.