From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1R4RHI-0006iI-6C for garchives@archives.gentoo.org; Fri, 16 Sep 2011 05:47:56 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 992CE21C070; Fri, 16 Sep 2011 05:47:45 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 0C8DA21C0BB for ; Fri, 16 Sep 2011 05:47:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 9FD6F1B401B for ; Fri, 16 Sep 2011 05:47:12 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Score: -4.649 X-Spam-Level: X-Spam-Status: No, score=-4.649 required=5.5 tests=[AWL=1.950, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqQHxxYbbU8t for ; Fri, 16 Sep 2011 05:47:05 +0000 (UTC) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by smtp.gentoo.org (Postfix) with ESMTP id D28391B401D for ; Fri, 16 Sep 2011 05:47:03 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R4RGN-0005IM-Vq for gentoo-dev@gentoo.org; Fri, 16 Sep 2011 07:47:00 +0200 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 16 Sep 2011 07:46:59 +0200 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 16 Sep 2011 07:46:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: x32 fun pants Date: Fri, 16 Sep 2011 05:46:49 +0000 (UTC) Message-ID: References: <201109151534.07155.vapier@gentoo.org> <201109151633.48737.vapier@gentoo.org> <20110915230307.31dac38a@pomiocik.lan> <201109151718.43422.vapier@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.135 (Tomorrow I'll Wake Up and Scald Myself with Tea; GIT 8ea89e0 branch-master) Content-Transfer-Encoding: quoted-printable X-Archives-Salt: X-Archives-Hash: 72fc8879ff6871c1479dc34634ff2a6e Mike Frysinger posted on Thu, 15 Sep 2011 17:18:43 -0400 as excerpted: > On Thursday, September 15, 2011 17:03:07 Micha=C5=82 G=C3=B3rny wrote: >> On Thu, 15 Sep 2011 16:33:48 -0400 Mike Frysinger wrote: >> > On Thursday, September 15, 2011 16:12:00 Micha=C5=82 G=C3=B3rny wrot= e: >> > > 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. >> >=20 >> > 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. >>=20 >> I'm rather thinking about potential issues. But OTOH packages fixed fo= r >> amd64 should probably work with x32 as well. Excluding asm code which >> would probably need a third variant then. >=20 > yes, inline asm might need tweaking[.] > they'll need to have gcc take care of it > but i'd rather not introduce another KEYWORD when we can simply p.mask > the package, or disable the asm when ABI =3D=3D x32. My immediate thought, probably unworkable for some reason but from here=20 it looks useful for at least (what would be) ~x32 and as a jump-start on=20 the number of ~x32 packages, and it should at least prove educational to=20 have it shot down ()... Have an x32 keyword, but at least for ~arch, have the package managers=20 (or profiles) define some "magic" such that ~amd64 AND ~x86 =3D=3D ~x32=20 (likely as EAPI-N, if delegated to the package managers). It seems to me that if the package is ~arch keyworded for both ~amd64 and= =20 ~x86, it should be reasonable to consider it ~x32 as well, and that would= =20 enormously jump-start the available packages list and remove the=20 necessity of adding all those keywords. Further, -x32 could then be used for specific cases where ~x32 was NOT=20 desired from the combined ~x86/~amd64 keywords, and as packages were=20 actually tested stable, they could be x32 stable-keyworded or -x32=20 keyworded (or profile package.masked) as appropriate. The same could obviously be tried for x32-stable based on x86 AND amd64,=20 but that seems far more problematic, while the existing practice of=20 simply carrying forward ~arch keywords without individually testing each=20 ~arch is only extended slightly, and ~arch users (no matter the arch)=20 should already by policy be prepared to cope with and fix occasional=20 breakage. OK, shoot it down. =3D:^) Or do as suggested elsewhere and combine all three into ABIs of the same=20 arch keyword, making the issue moot. This is the best excuse we're ever=20 likely to get, for that, and over time as it deprecates, I expect legacy=20 x86 to appreciate the extra arch-team manpower they'd otherwise be losing= =20 as they faded into minority and eventually obscurity. And with x32, the=20 cooperation between the two existing arch-abis will need to grow, in any=20 case. But whether it's arch-team politically feasible, I don't know... I=20 believe that's what stopped the idea the last time it came up, but that=20 was before this whole x32 thing, which does quite change things. --=20 Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman