linux-kernel - Re: RFD: x32 ABI system call numbers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 30 Aug 2011 14:18:50 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Kyle Moffett <kyle@...fetthome.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"H.J. Lu" <hjl.tools@...il.com>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: RFD: x32 ABI system call numbers

On Tuesday 30 August 2011, Geert Uytterhoeven wrote:
> On Tue, Aug 30, 2011 at 06:45, H. Peter Anvin <hpa@...or.com> wrote:
> > On 08/29/2011 07:16 PM, Kyle Moffett wrote:
> >> The goal of x32 as I understand it is to allow 32-bit x86 programs to
> >> use all the nifty extra registers and faster instructions (IE: syscall)
> >> without needing to deal with the 2x memory overhead of 64-bit
> >> pointers.
> 
> Good. IIRC, the PPC people were thinking about something similar back in 2007,
> but it hasn't materialized yet.

I think every arch has thought about it at some point. Note that current powerpc
(and s390) enterprise systems are 64 bit only. s390 wants to add a new 32 bit
ABI along these lines (much simpler to do than on x86 though). MIPS has
had it for a long time (the n32 ABI).

For sh and tile, the 32-on-64 ABI still uses the 64 bit registers all the
time and is incompatible with the native 32 bit ABI.

> > That is the major goal.  A minor goal is to bring x86-64 goodness to
> > those who have an (irrational) fear of 64 bits thinking it is a major
> > porting effort.  Thus, *source-level* porting effort matters, but it is
> > completely subordinate to the major goal.
> 
> From my experience, if the source code is not 64-bit clean, it will probably
> be a major hassle to make it cope with changed time_t and off_t and other traps
> of that kind...

I don't think so. The only major user space projects that I've seen being
fundamentally 32-bit only are the ones that have some kind of language
interpreter that casts freely between pointers and 32 bit wide integers.

The uses of time_t and off_t are typically fairly localized in the programs
by comparison and can be fixed much easier, especially if you don't actually
want to use larger than 32 bit values for these.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/