On Thursday, September 15, 2011 17:03:07 Michał Górny wrote:
> On Thu, 15 Sep 2011 16:33:48 -0400 Mike Frysinger wrote:
> > On Thursday, September 15, 2011 16:12:00 Michał Górny wrote:
> > > On Thu, 15 Sep 2011 15:34:06 -0400 Mike Frysinger wrote:
> > > > KEYWORDS wise, i'd like to avoid having to add "x32" everywhere.
> > > > instead, reusing "amd64".  only downside is the existing USE=amd64
> > > > behavior, but we can address that by making MULTILIB_ABIS a
> > > > USE_EXPAND (i think this came up before with the portage multilib
> > > > discussion).
> > > 
> > > Hrm, wouldn't that be more like x86 keyword? AFAICS the type sizes
> > > for x86 and x32 would match.
> > 
> > the sizeof(long) and sizeof(void*) are the same between x86 and x32.
> > however, that's about the only thing.  for example, x32 gets access
> > to 64bit registers when working with 64bit types (long long) and the
> > tuple is x86_64-pc-linux- gnu.  in general, it seems to be closer to
> > amd64 than x32.
> 
> I'm rather thinking about potential issues. But OTOH packages fixed for
> amd64 should probably work with x32 as well. Excluding asm code which
> would probably need a third variant then.

yes, inline asm might need tweaking as pointers/longs are no longer 64bits.  
so any code that assumes "#ifdef __x64_64__ == sizeof(void*) == 8" and does so 
in their assembly might break.  they'll need to have gcc take care of it by 
leveraging the constraints, or checking the __LP64__ define in addition to 
__x64_64__.

but i'd rather not introduce another KEYWORD when we can simply p.mask the 
package, or disable the asm when ABI == x32.
-mike