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]
Message-Id: <201103210153.10145.vapier@gentoo.org>
Date:	Mon, 21 Mar 2011 01:53:08 -0400
From:	Mike Frysinger <vapier@...too.org>
To:	"H.J. Lu" <hjl.tools@...il.com>
Cc:	libc-alpha@...rceware.org, GCC Development <gcc@....gnu.org>,
	LKML <linux-kernel@...r.kernel.org>, x32-abi@...glegroups.com
Subject: Re: X32 psABI status update

On Monday, March 21, 2011 01:35:35 H.J. Lu wrote:
> On Sun, Mar 20, 2011 at 10:08 PM, Mike Frysinger wrote:
> > On Thursday, March 17, 2011 01:21:16 H.J. Lu wrote:
> >> On Wed, Mar 16, 2011 at 7:57 PM, Mike Frysinger wrote:
> >> > in looking at the gcc files, it doesnt seem like there's any defines
> >> > setup to declare x32 directly.  instead, you'd have to do something
> >> > like: #ifdef __x86_64__
> >> > # if __SIZEOF_LONG__ == 8
> >> > /* x86_64 */
> >> > # else
> >> > /* x32 */
> >> > # endif
> >> > #endif
> >> > 
> >> > any plans on adding an __x32__ (or whatever) cpp symbol to keep people
> >> > from coming up with their own special/broken crap ?  or are there some
> >> > already that i'm not seeing ?
> >> 
> >> The idea is in most cases, you only need to check __x86_64__ since x32
> >> and x86-64 are very close.  In some cases, x32 is very different from
> >> x86_64, like assembly codes on long and pointer, you can check
> >> __x86_64__ and __LP64__. In glibc, I used a different approach by using
> >> macros REG_RAX, .., MOV_LP, ADD_LP, SUB_LP and CMP_LP in assembly
> >> codes.
> > 
> > while i agree with you in general that this is how people should be doing
> > things, in practice i often see people fishing around.  education only
> > goes so far, so if there was an __x32__ define, i feel like people are
> > more likely to get it right than wrong.
> > 
> > i dont have any use cases off the top of my head, but i wouldnt be
> > surprised if the heavy inline assembly people (like the multimedia peeps
> > e.g. libav) approached it this way.  rather than google for
> > documentation, look at the cpp output between -m64 and -mx32 and see
> > what sticks out.  "__x32__" would certainly do that.
> 
> My point is __x86_64__ version should work for both 64bit and x32. There
> should no need for a separate x32 version.

yes, and my point is that people often reach for cpp defines rather than 
figure out how to do it right.

i'm not saying that __x32__ should be defined in place of __x86_64__, just 
that when -mx32 is used, __x32__ is additionally defined.  simply as an 
example, what i'm referring to could be accomplished by adding this to the 
*cpp specs:
	%{mx32:-D__x32__=1}
-mike

Download attachment "signature.asc " of type "application/pgp-signature" (837 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ