On Friday, September 16, 2011 01:46:49 Duncan wrote:
> Mike Frysinger posted on Thu, 15 Sep 2011 17:18:43 -0400 as excerpted:
> > 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".
> >> > >
> >> > > 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.
> > but i'd rather not introduce another KEYWORD when we can simply p.mask
> > the package, or disable the asm when ABI == x32.
> My immediate thought, probably unworkable for some reason but from here
> it looks useful for at least (what would be) ~x32 and as a jump-start on
> the number of ~x32 packages, and it should at least prove educational to
> have it shot down (<g>)...
these things have a way of not being fixed for a very long time. p.mask in an
x32 profile is a lot easier to work with and doesnt need to be "recovered"
from down the line.