[<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