From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: x32 fun pants
Date: Fri, 16 Sep 2011 05:46:49 +0000 (UTC) [thread overview]
Message-ID: <pan.2011.09.16.05.46.48@cox.net> (raw)
In-Reply-To: 201109151718.43422.vapier@gentoo.org
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.
>
> 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 == 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>)...
Have an x32 keyword, but at least for ~arch, have the package managers
(or profiles) define some "magic" such that ~amd64 AND ~x86 == ~x32
(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
~x86, it should be reasonable to consider it ~x32 as well, and that would
enormously jump-start the available packages list and remove the
necessity of adding all those keywords.
Further, -x32 could then be used for specific cases where ~x32 was NOT
desired from the combined ~x86/~amd64 keywords, and as packages were
actually tested stable, they could be x32 stable-keyworded or -x32
keyworded (or profile package.masked) as appropriate.
The same could obviously be tried for x32-stable based on x86 AND amd64,
but that seems far more problematic, while the existing practice of
simply carrying forward ~arch keywords without individually testing each
~arch is only extended slightly, and ~arch users (no matter the arch)
should already by policy be prepared to cope with and fix occasional
breakage.
OK, shoot it down. =:^)
Or do as suggested elsewhere and combine all three into ABIs of the same
arch keyword, making the issue moot. This is the best excuse we're ever
likely to get, for that, and over time as it deprecates, I expect legacy
x86 to appreciate the extra arch-team manpower they'd otherwise be losing
as they faded into minority and eventually obscurity. And with x32, the
cooperation between the two existing arch-abis will need to grow, in any
case.
But whether it's arch-team politically feasible, I don't know... I
believe that's what stopped the idea the last time it came up, but that
was before this whole x32 thing, which does quite change things.
--
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
next prev parent reply other threads:[~2011-09-16 5:47 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-15 19:34 [gentoo-dev] x32 fun pants Mike Frysinger
2011-09-15 20:00 ` Alexey Shvetsov
2011-09-15 20:35 ` Mike Frysinger
2011-09-16 7:48 ` Michał Górny
2011-09-16 7:58 ` Stratos Psomadakis
2011-09-16 8:14 ` Michał Górny
2011-09-16 15:06 ` Markos Chandras
2011-09-16 17:32 ` Mike Frysinger
2011-09-16 18:25 ` Markos Chandras
2011-09-17 5:53 ` [gentoo-dev] " Duncan
2011-09-16 18:07 ` [gentoo-dev] " Stratos Psomadakis
2011-09-15 20:12 ` Michał Górny
2011-09-15 20:33 ` Mike Frysinger
2011-09-15 21:03 ` Michał Górny
2011-09-15 21:18 ` Mike Frysinger
2011-09-16 5:46 ` Duncan [this message]
2011-09-16 18:15 ` [gentoo-dev] " Mike Frysinger
2011-09-19 23:28 ` [gentoo-dev] " Joshua Kinard
2011-09-16 8:28 ` Stratos Psomadakis
2011-09-16 16:08 ` Mike Frysinger
2011-09-16 19:09 ` Thomas Sachau
2011-09-16 20:17 ` Mike Frysinger
2011-09-16 13:36 ` Donnie Berkholz
2011-09-16 14:06 ` Michał Górny
2011-09-16 16:01 ` Mike Frysinger
2011-09-16 16:24 ` Mike Frysinger
2011-09-16 15:52 ` Mike Frysinger
2011-09-20 0:25 ` Joshua Kinard
2011-12-02 20:54 ` Mike Frysinger
2011-12-02 21:25 ` Samuli Suominen
2011-12-02 21:55 ` Mike Frysinger
2011-12-06 21:40 ` Mike Frysinger
2011-12-06 22:13 ` Markos Chandras
2011-12-06 22:39 ` Mike Frysinger
2011-12-10 8:02 ` Mike Frysinger
2011-12-10 13:15 ` [gentoo-dev] " octoploid
2011-12-10 18:37 ` Mike Frysinger
2011-12-10 19:36 ` Alec Warner
2011-12-10 19:49 ` Mike Frysinger
2011-12-10 20:01 ` Mike Gilbert
2011-12-11 1:36 ` Chí-Thanh Christopher Nguyễn
2011-12-11 3:18 ` Mike Frysinger
2011-12-12 14:47 ` Francesco Riosa
2011-12-12 17:26 ` Mike Frysinger
2011-12-12 22:47 ` Francesco Riosa
2011-12-13 21:20 ` Mike Frysinger
2011-12-08 21:22 ` [gentoo-dev] " Mike Frysinger
2011-12-08 21:29 ` Markos Chandras
2011-12-08 21:34 ` Mike Frysinger
2011-12-08 21:40 ` Markos Chandras
2011-12-08 22:11 ` Mike Frysinger
2012-06-05 18:44 ` [gentoo-dev] x32 release candidate Mike Frysinger
2012-06-06 2:17 ` Mike Frysinger
2012-06-06 5:14 ` Mike Frysinger
2012-06-06 19:40 ` Gregory M. Turner
2012-06-06 20:14 ` vivo75
2012-06-07 3:17 ` Mike Frysinger
2012-06-07 6:13 ` Luca Barbato
2012-06-07 13:38 ` Mike Frysinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=pan.2011.09.16.05.46.48@cox.net \
--to=1i5t5.duncan@cox.net \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox