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
signature.asc
Description: This is a digitally signed message part.
