mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Florian Weimer <fw@deneb.enyo.de>
Cc: "H.J. Lu" <hjl.tools@gmail.com>,
	x32-abi@googlegroups.com, GCC Development <gcc@gcc.gnu.org>,
	GNU C Library <libc-alpha@sourceware.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: X32 psABI status
Date: Sun, 13 Feb 2011 15:43:43 +0000 (GMT)	[thread overview]
Message-ID: <alpine.LFD.2.00.1102131514250.31425@eddie.linux-mips.org> (raw)
In-Reply-To: <87tyg8j7le.fsf@mid.deneb.enyo.de>

On Sun, 13 Feb 2011, Florian Weimer wrote:

> >> Actually, I'm wondering if you can do the translation in user space.
> >> There already are 32-on-64 implementations in existence, without
> >> kernel changes (recent Hotspot, LuaJIT, and probably some more).
> >
> > Please check out the x32 kernel source and provide feedback.
> 
> I still don't understand why you need a separate syscall table.  You
> should really be able to run on an unmodified amd64 kernel, in 64 bit
> mode.  This would imply that tools like strace don't need any porting
> at all (you could just use the amd64 version), and even GDB would
> mostly worked unchanged.

 For the record -- I suggested a similar approach for n32 MIPS too (back 
when it was on the table), but people rejected it deciding it was easier 
for them to add a separate syscall table (for a change).  It was perhaps 
even more surprising as any MIPS 32-bit user pointer is a valid 64-bit one 
too (I suspect this is also the case with x86-64) and any simple type, 
including pointers and the "long long" type (such as used with lseek64(2), 
etc.) goes into a single 64-bit register or stack slot with both ABIs, so 
any conversion layer (boundary checks or whatever; structures can be 
sorted out with padding) in libc would be pretty thin.

 One argument in favour was the need of some people for crippled 
interfaces such as original lseek(2) that would fail on large files for 
the sake of some broken programs out there they wanted to rebuild for the 
new ABI without fixing, sigh...  Actually some OSes, such as NetBSD (I 
think, it could have been one of the other *BSDs), do not offer these 
crippled interfaces at all on any platform, but I gather people simply are 
not particularly interested into pushing portability that far.

 So now we have another table in the kernel to maintain that goes wrong in 
respect to the two others from time to time.  But there you go...  At 
least each of the three is optional.  I couldn't care less about n32 
anyway; I usually configure 64-bit MIPS kernels for n64 only.

  Maciej

  parent reply	other threads:[~2011-02-13 15:49 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-12 19:41 H.J. Lu
2011-02-12 21:10 ` Florian Weimer
2011-02-12 21:29   ` H.J. Lu
2011-02-12 23:04   ` H. Peter Anvin
2011-02-13  3:02     ` Andrew Pinski
2011-02-13  8:48     ` Florian Weimer
2011-02-13 13:45       ` H.J. Lu
2011-02-13 15:07         ` Florian Weimer
2011-02-13 15:13           ` H.J. Lu
2011-02-13 15:21             ` Florian Weimer
2011-02-13 15:37               ` H.J. Lu
2011-02-13 16:35             ` Petr Baudis
2011-02-13 16:48               ` H.J. Lu
2011-02-13 17:37               ` Joseph S. Myers
2011-02-13 15:43           ` Maciej W. Rozycki [this message]
2011-02-13 15:57             ` H.J. Lu
2011-02-13 20:10 ` Arnd Bergmann
2011-02-13 21:10   ` H.J. Lu
2011-02-13 21:16     ` H. Peter Anvin
2011-02-13 21:28       ` H.J. Lu
2011-02-13 22:03         ` H. Peter Anvin
2011-02-13 22:12           ` H.J. Lu
2011-02-13 21:33       ` Alan Cox
2011-02-14  1:52         ` H. Peter Anvin
2011-02-13 22:27       ` H. Peter Anvin
2011-02-13 22:28       ` Arnd Bergmann
2011-02-13 22:46         ` H. Peter Anvin
2011-02-13 22:57           ` Arnd Bergmann
2011-02-13 23:03             ` H.J. Lu
2011-02-13 23:39           ` Alan Cox
2011-02-13 23:50             ` H.J. Lu
2011-02-14  1:59             ` H. Peter Anvin

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=alpine.LFD.2.00.1102131514250.31425@eddie.linux-mips.org \
    --to=macro@linux-mips.org \
    --cc=fw@deneb.enyo.de \
    --cc=gcc@gcc.gnu.org \
    --cc=hjl.tools@gmail.com \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=x32-abi@googlegroups.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

all inboxes | Powered by JetHome®