[gentoo-dev] x32 fun pants

[gentoo-dev] x32 fun pants

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 883 bytes --]

ive converted my system over to x86/amd64/x32 multilib for funs.  but i can 
see how some people wont want all three all the time.  so the question is how 
we want to make this available to users at the release/profile level.

background: x32 is a new ABI that runs on 64bit x86_64 processors.  see [1].  
you'll need gcc-4.7+, binutils-2.21.50+, glibc-2.15+, and linux-3.2+.

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).

release wise, we could ship a single multilib stage (x86/amd64/x32) and make 
it easy to convert to a subset.  that way we still need only one.

other thoughts ?
-mike

[1] https://sites.google.com/site/x32abi/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] x32 fun pants

[Alexey Shvetsov]

Hi all!

Is it accepted for merge into kernel mainline for 3.2?
Actualy this abi looks like n32 mips abi.

PS why not merge all x86 abis into one keyword? because x86_32 x86_64 
x86_x32 are only abis of x86. Also we dont have different keywords for 
different mips abis (64bit and 32bit ones)

On Thu, 15 Sep 2011 15:34:06 -0400, Mike Frysinger wrote:
> ive converted my system over to x86/amd64/x32 multilib for funs.  but 
> i can
> see how some people wont want all three all the time.  so the
> question is how
> we want to make this available to users at the release/profile level.
>
> background: x32 is a new ABI that runs on 64bit x86_64 processors.
> see [1].
> you'll need gcc-4.7+, binutils-2.21.50+, glibc-2.15+, and linux-3.2+.
>
> 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).
>
> release wise, we could ship a single multilib stage (x86/amd64/x32) 
> and make
> it easy to convert to a subset.  that way we still need only one.
>
> other thoughts ?
> -mike
>
> [1] https://sites.google.com/site/x32abi/

-- 
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexxyum@gmail.com
mailto:alexxy@gentoo.org
mailto:alexxy@omrb.pnpi.spb.ru

Re: [gentoo-dev] x32 fun pants

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 622 bytes --]

On Thursday, September 15, 2011 16:00:14 Alexey Shvetsov wrote:

please dont top post

> Is it accepted for merge into kernel mainline for 3.2?

no.  i was just being optimistic.  i'm running 3.1-rc4 atm with a smallish 
patch to make it work.

> Actualy this abi looks like n32 mips abi.

yeah, a lot of the reasons behind the creation of n32 were behind the creation 
of the x32 abi.

> PS why not merge all x86 abis into one keyword? because x86_32 x86_64
> x86_x32 are only abis of x86. Also we dont have different keywords for
> different mips abis (64bit and 32bit ones)

that'd be nice :)
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] x32 fun pants

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 679 bytes --]

On Thu, 15 Sep 2011 16:35:55 -0400
Mike Frysinger <vapier@gentoo.org> wrote:

> > PS why not merge all x86 abis into one keyword? because x86_32
> > x86_64 x86_x32 are only abis of x86. Also we dont have different
> > keywords for different mips abis (64bit and 32bit ones)
> 
> that'd be nice :)

Seems even acceptable. Not sane but acceptable. People tend to keyword
packages both '~amd64 ~x86' testing them on amd64 only; amd64 users
tend to get sad when someone keyworded a package '~x86' only.

On the other hand, it'd be good to have ABI sub-keywords then.
Something like 'x86:x86 -*' if a package is actually x86-only.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] x32 fun pants

[Stratos Psomadakis]

On 09/16/2011 10:48 AM, Michał Górny wrote:
> On Thu, 15 Sep 2011 16:35:55 -0400
> Mike Frysinger <vapier@gentoo.org> wrote:
>
>>> PS why not merge all x86 abis into one keyword? because x86_32
>>> x86_64 x86_x32 are only abis of x86. Also we dont have different
>>> keywords for different mips abis (64bit and 32bit ones)
>> that'd be nice :)
> Seems even acceptable. Not sane but acceptable. People tend to keyword
> packages both '~amd64 ~x86' testing them on amd64 only; amd64 users
> tend to get sad when someone keyworded a package '~x86' only.
>
> On the other hand, it'd be good to have ABI sub-keywords then.
> Something like 'x86:x86 -*' if a package is actually x86-only.
>
I guess there are only a few cases where a package should be keyworded
for eg x86, but not for amd64, so these few cases can be handled by
p.masks, right?

So, we can have a single x86 keyword, and a single x86 'parent' profile,
and subprofiles for x86(or x86_32), amd64, and x32.

I guess it's not that simple, but I think that's how the mips profiles work?

-- 
Stratos Psomadakis
<psomas@gentoo.org>

Re: [gentoo-dev] x32 fun pants

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1110 bytes --]

On Fri, 16 Sep 2011 10:58:01 +0300
Stratos Psomadakis <psomas@gentoo.org> wrote:

> On 09/16/2011 10:48 AM, Michał Górny wrote:
> > On Thu, 15 Sep 2011 16:35:55 -0400
> > Mike Frysinger <vapier@gentoo.org> wrote:
> >
> >>> PS why not merge all x86 abis into one keyword? because x86_32
> >>> x86_64 x86_x32 are only abis of x86. Also we dont have different
> >>> keywords for different mips abis (64bit and 32bit ones)
> >> that'd be nice :)
> > Seems even acceptable. Not sane but acceptable. People tend to
> > keyword packages both '~amd64 ~x86' testing them on amd64 only;
> > amd64 users tend to get sad when someone keyworded a package '~x86'
> > only.
> >
> > On the other hand, it'd be good to have ABI sub-keywords then.
> > Something like 'x86:x86 -*' if a package is actually x86-only.
> >
> I guess there are only a few cases where a package should be keyworded
> for eg x86, but not for amd64, so these few cases can be handled by
> p.masks, right?

Yes, that's a good idea indeed. +1 for me, and suggest pushing it to
the Council.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] x32 fun pants

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 09/16/11 10:58, Stratos Psomadakis wrote:
> On 09/16/2011 10:48 AM, Michał Górny wrote:
>> On Thu, 15 Sep 2011 16:35:55 -0400 Mike Frysinger
>> <vapier@gentoo.org> wrote:
>> 
>>>> PS why not merge all x86 abis into one keyword? because
>>>> x86_32 x86_64 x86_x32 are only abis of x86. Also we dont have
>>>> different keywords for different mips abis (64bit and 32bit
>>>> ones)
>>> that'd be nice :)
>> Seems even acceptable. Not sane but acceptable. People tend to
>> keyword packages both '~amd64 ~x86' testing them on amd64 only;
>> amd64 users tend to get sad when someone keyworded a package
>> '~x86' only.
>> 
>> On the other hand, it'd be good to have ABI sub-keywords then. 
>> Something like 'x86:x86 -*' if a package is actually x86-only.
>> 
> I guess there are only a few cases where a package should be
> keyworded for eg x86, but not for amd64, so these few cases can be
> handled by p.masks, right?
> 
> So, we can have a single x86 keyword, and a single x86 'parent'
> profile, and subprofiles for x86(or x86_32), amd64, and x32.
> 
> I guess it's not that simple, but I think that's how the mips
> profiles work?
> 
I am a bit confused by your proposal. Do you suggest to drop 'amd64'
and use x86(parent)/amd64(subprofile)(for x86_64) instead?

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iQIcBAEBCgAGBQJOc2XxAAoJEPqDWhW0r/LCUWQQAKdQ+1HcTbdNKdDkMcQna7M3
h9rWzE0BocJcXVji24hfN7JAthpvNohyIQkWgxP3HRCaOCYJ0kaXY+hC8piYrkGS
HPUQ/fV2JhhSgOZpQUmZFc4Db382ILqHk44k2/vYnN27U1yC2rX/GBiZkM/jZAe3
sYZ+DR8R6FCCmquLeWX+8tqE4A11o5hzjC9cMMBVr7iGVKsonWCDgGXSLX3FMfuT
gSAuRfpUHQa0ghCU/tXwH1fso/lDDhvySioJBue2ED432yknhOKtzfdye4Lg00nu
M+pM36sqdF21VMvBtA1H1X5Ok927+jqS19ac8OUy8vI0qq1sIozdzKWOMICvSjf9
UDcIO1+gAA0ZGjR+n5FIrKcFgPm4uHfUFZhG50GMXm3e1TTSOel3OVEngcsYeB7p
WoLPMuuZXVUrT9OXimqt5Ei2F9vkCWeh21zXSHQRmdlFvUsiPogp9ZQoL5cEAs2b
wolRF+haCmRw8tpMJ1fLxba7jOATLnmS0Z0RMXzlHON0jg4/SJa8wyZnQrPiexHq
rlKSI3kIzvpucvYiRn0w0ouMer835BzPpEV5xRcrX2Q2CyfP8JX/GR90ZU7iSSeh
lteqVKvGzg7Nj67OKlfW1WVjPBxhB9N8lPro6PcT2sBaFyatCr+c7phtYEismubN
kw2sbgrD2kp198ogymeq
=biyu
-----END PGP SIGNATURE-----

Re: [gentoo-dev] x32 fun pants

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1475 bytes --]

On Friday, September 16, 2011 11:06:25 Markos Chandras wrote:
> On 09/16/11 10:58, Stratos Psomadakis wrote:
> > On 09/16/2011 10:48 AM, Michał Górny wrote:
> >> On Thu, 15 Sep 2011 16:35:55 -0400 Mike Frysinger wrote:
> >>>> PS why not merge all x86 abis into one keyword? because
> >>>> x86_32 x86_64 x86_x32 are only abis of x86. Also we dont have
> >>>> different keywords for different mips abis (64bit and 32bit
> >>>> ones)
> >>> 
> >>> that'd be nice :)
> >> 
> >> Seems even acceptable. Not sane but acceptable. People tend to
> >> keyword packages both '~amd64 ~x86' testing them on amd64 only;
> >> amd64 users tend to get sad when someone keyworded a package
> >> '~x86' only.
> >> 
> >> On the other hand, it'd be good to have ABI sub-keywords then.
> >> Something like 'x86:x86 -*' if a package is actually x86-only.
> > 
> > I guess there are only a few cases where a package should be
> > keyworded for eg x86, but not for amd64, so these few cases can be
> > handled by p.masks, right?
> > 
> > So, we can have a single x86 keyword, and a single x86 'parent'
> > profile, and subprofiles for x86(or x86_32), amd64, and x32.
> > 
> > I guess it's not that simple, but I think that's how the mips
> > profiles work?
> 
> I am a bit confused by your proposal. Do you suggest to drop 'amd64'
> and use x86(parent)/amd64(subprofile)(for x86_64) instead?

that would be ideal, and drop "amd64" in the process: x86/x86_64/
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] x32 fun pants

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 09/16/11 20:32, Mike Frysinger wrote:
> On Friday, September 16, 2011 11:06:25 Markos Chandras wrote:
>> On 09/16/11 10:58, Stratos Psomadakis wrote:
>>> On 09/16/2011 10:48 AM, Michał Górny wrote:
>>>> On Thu, 15 Sep 2011 16:35:55 -0400 Mike Frysinger wrote:
>>>>>> PS why not merge all x86 abis into one keyword? because 
>>>>>> x86_32 x86_64 x86_x32 are only abis of x86. Also we dont
>>>>>> have different keywords for different mips abis (64bit
>>>>>> and 32bit ones)
>>>>> 
>>>>> that'd be nice :)
>>>> 
>>>> Seems even acceptable. Not sane but acceptable. People tend
>>>> to keyword packages both '~amd64 ~x86' testing them on amd64
>>>> only; amd64 users tend to get sad when someone keyworded a
>>>> package '~x86' only.
>>>> 
>>>> On the other hand, it'd be good to have ABI sub-keywords
>>>> then. Something like 'x86:x86 -*' if a package is actually
>>>> x86-only.
>>> 
>>> I guess there are only a few cases where a package should be 
>>> keyworded for eg x86, but not for amd64, so these few cases can
>>> be handled by p.masks, right?
>>> 
>>> So, we can have a single x86 keyword, and a single x86
>>> 'parent' profile, and subprofiles for x86(or x86_32), amd64,
>>> and x32.
>>> 
>>> I guess it's not that simple, but I think that's how the mips 
>>> profiles work?
>> 
>> I am a bit confused by your proposal. Do you suggest to drop
>> 'amd64' and use x86(parent)/amd64(subprofile)(for x86_64)
>> instead?
> 
> that would be ideal, and drop "amd64" in the process: x86/x86_64/ 
> -mike

Ok so we will probably have the following multilib options

* x86(ABI=x86_32{/lib}) + amd64(ABI=x86_64{lib64/}) +
x32(ABI=x32{/libx32})
* x86/amd64 ( what we already have in amd64 multilib )
* x86/x32

and

* x86 (no multilib for 32-bit processors ) ( what we already have in
x86 profile )

Sounds doable

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iQIcBAEBCgAGBQJOc5SDAAoJEPqDWhW0r/LCHnYQAKuMpYvTWv4waSd503vfBjlb
yHPUK+Hd9itz47I3lNmxqZGl7sQxIYm6Ht6MWs3qPIrwI60biUK/vH7dK0q1dnF9
x/zSEFc6hG4nyZ94oeTtsxV7Ttsk9QK/JY2Vm1ulBbEWJeb8sfQD1lesRFV++YZn
Xeu3fMKkWoW/2m68nng7Rzfbxf2TvE7bdY3loefpXgMZf6kz7LSkNV1QidEwzs7V
yZ9C4N8G8FVFysDykqGbYKMTtn70CCKI1HZ608NY7msWm6LADwpYQYsGENX04l2O
xNpW1r+2bhSICT2TGzxIEsbspStH8g4XmRvIdXyZCbCecOyWRaAcBk9x6dY+6ZjB
mZkzauSiXGFQcVjjXdXqL1pT2NGEoGe5eWi4daH4cy/12ND76/Gt79HogBUznWTX
5A50jyEjMMHcQjDxvWOyCGvq7yxU3Njs3mNzImEmbR3j3PwlniaFs3Vz76o6yEfE
mJ0gaVP50XTDncsK9G4nrgJHKdA7BHOlWL50HXv0rsBHxkQyhsEiw5VaZUF7kOPr
R2JptEh9Kh2JyV+EfF/m74Y3Ht0jaXY0MQXV5fl5QxvavRb7WX/mzVXwjY+IlnPB
sJUcHkcNLNhm98e5j/CLn0T3DtmfqvnXSfF10wFztoUGDVOUuixVMo+ZvnGYdnH4
E4shmoxTlL7J5CzSEvpu
=wlRl
-----END PGP SIGNATURE-----

[gentoo-dev] Re: x32 fun pants

[Duncan]

Markos Chandras posted on Fri, 16 Sep 2011 21:25:07 +0300 as excerpted:

>> that would be ideal, and drop "amd64" in the process: x86/x86_64/
>> -mike
> 
> Ok so we will probably have the following multilib options
> 
> * x86(ABI=x86_32{/lib}) + amd64(ABI=x86_64{lib64/}) +
> x32(ABI=x32{/libx32})

> * x86/amd64 ( what we already have in amd64 multilib )

This one would probably be x86/x86_64 , as Mike said drop amd64.

(Tho I much prefer amd64, or if it's changed, something else without a _, 
which is hard to type, at least on the US/qwerty layout, requiring both 
hands to get the shift, and two rows up plus over to get the _, amd64 
works quite nicely in that regard.)

> * x86/x32
> 
> and
> 
> * x86 (no multilib for 32-bit processors ) ( what we already have in x86
> profile )

Don't forget current amd64/no-multilib.  I guess that's be

* x86/x86_64/no-multilb

(Tho again, I'd prefer keeping amd64, for x86/amd64/no-multilib.)

And presumably there's also be

* x86/x32/no-multilib

-- 
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

Re: [gentoo-dev] x32 fun pants

[Stratos Psomadakis]

[-- Attachment #1: Type: text/plain, Size: 1612 bytes --]

On 09/16/2011 06:06 PM, Markos Chandras wrote:
> On 09/16/11 10:58, Stratos Psomadakis wrote:
> > On 09/16/2011 10:48 AM, Michał Górny wrote:
> >> On Thu, 15 Sep 2011 16:35:55 -0400 Mike Frysinger
> >> <vapier@gentoo.org> wrote:
> >>
> >>>> PS why not merge all x86 abis into one keyword? because
> >>>> x86_32 x86_64 x86_x32 are only abis of x86. Also we dont have
> >>>> different keywords for different mips abis (64bit and 32bit
> >>>> ones)
> >>> that'd be nice :)
> >> Seems even acceptable. Not sane but acceptable. People tend to
> >> keyword packages both '~amd64 ~x86' testing them on amd64 only;
> >> amd64 users tend to get sad when someone keyworded a package
> >> '~x86' only.
> >>
> >> On the other hand, it'd be good to have ABI sub-keywords then.
> >> Something like 'x86:x86 -*' if a package is actually x86-only.
> >>
> > I guess there are only a few cases where a package should be
> > keyworded for eg x86, but not for amd64, so these few cases can be
> > handled by p.masks, right?
>
> > So, we can have a single x86 keyword, and a single x86 'parent'
> > profile, and subprofiles for x86(or x86_32), amd64, and x32.
>
> > I guess it's not that simple, but I think that's how the mips
> > profiles work?
>
> I am a bit confused by your proposal. Do you suggest to drop 'amd64'
> and use x86(parent)/amd64(subprofile)(for x86_64) instead?
>
Yeap.

And if we're going to use the same keyword for x32/amd64, we can just do
it for x86/amd64/x32 too. I don't think that there will be too many
differences.

-- 
Stratos Psomadakis
<psomas@gentoo.org>


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] x32 fun pants

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 505 bytes --]

On Thu, 15 Sep 2011 15:34:06 -0400
Mike Frysinger <vapier@gentoo.org> 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.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] x32 fun pants

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 833 bytes --]

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.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] x32 fun pants

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]

On Thu, 15 Sep 2011 16:33:48 -0400
Mike Frysinger <vapier@gentoo.org> 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. -mike

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.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] x32 fun pants

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1671 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[gentoo-dev] Re: x32 fun pants

[Duncan]

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

Re: [gentoo-dev] Re: x32 fun pants

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1773 bytes --]

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.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] x32 fun pants

[Joshua Kinard]

[-- Attachment #1: Type: text/plain, Size: 934 bytes --]

On 09/15/2011 16:33, Mike Frysinger wrote:

> 
> 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.
> -mike


Virtually the exact same for MIPS n32 ABI.  Needs a 64bit kernel, needs a
mips64-*-linux-gnu toolchain, but the output is a hybrid 32bit/64bit binary.

I wonder if procps ever resolved that PAGE_SIZE mess internally when we
brought the o32/n32/n64 mess to light with its author?

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: [gentoo-dev] x32 fun pants

[Stratos Psomadakis]

On 09/15/2011 10:34 PM, Mike Frysinger wrote:
> ive converted my system over to x86/amd64/x32 multilib for funs.  but i can 
> see how some people wont want all three all the time.  so the question is how 
> we want to make this available to users at the release/profile level.
>
> background: x32 is a new ABI that runs on 64bit x86_64 processors.  see [1].  
> you'll need gcc-4.7+, binutils-2.21.50+, glibc-2.15+, and linux-3.2+.
>
> 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).
>
> release wise, we could ship a single multilib stage (x86/amd64/x32) and make 
> it easy to convert to a subset.  that way we still need only one.
>
> other thoughts ?
> -mike
>
> [1] https://sites.google.com/site/x32abi/
Is a x86/amd64/x32 multilib profile just going to provide toolchain
support for x32 binaries (like x86 in a x86/amd64 multilib profile), or
do we want a 'full' x32 profile, where every package is built by default
as x32 code?

I'm guessing that as x32 gets standarized, and providing it really
outperforms amd64, most distros we'll move to using x32 binaries/libs by
default.

But then, what if a user wants amd64 for specific packages, which depend
on shared libraries built as x32 (maybe he should just use the amd64
profile then)?

-- 
Stratos Psomadakis
<psomas@gentoo.org>

Re: [gentoo-dev] x32 fun pants

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 356 bytes --]

On Friday, September 16, 2011 04:28:24 Stratos Psomadakis wrote:
> Is a x86/amd64/x32 multilib profile just going to provide toolchain
> support for x32 binaries (like x86 in a x86/amd64 multilib profile), or
> do we want a 'full' x32 profile, where every package is built by default
> as x32 code?

this is an issue for the multilib-portage project
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] x32 fun pants

[Thomas Sachau]

[-- Attachment #1: Type: text/plain, Size: 977 bytes --]

Mike Frysinger schrieb:
> On Friday, September 16, 2011 04:28:24 Stratos Psomadakis wrote:
>> Is a x86/amd64/x32 multilib profile just going to provide toolchain
>> support for x32 binaries (like x86 in a x86/amd64 multilib profile), or
>> do we want a 'full' x32 profile, where every package is built by default
>> as x32 code?
> 
> this is an issue for the multilib-portage project
> -mike

How is this an issue for multilib-portage? It only requires a toolchain able to build for the target
and the details in environment (like possible targets and needed additional flags for each target).
Thinking about the issues when starting with a new target, it might be a good idea to have the basic
system (stage3) for the multilib profile to contain files for all targets, but only enable the
default ABI. So when a user wants some other targets, he already has a base system, else he can just
reinstall the base system and drop the unused files with this step.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 380 bytes --]

Re: [gentoo-dev] x32 fun pants

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 669 bytes --]

On Friday, September 16, 2011 15:09:52 Thomas Sachau wrote:
> Mike Frysinger schrieb:
> > On Friday, September 16, 2011 04:28:24 Stratos Psomadakis wrote:
> >> Is a x86/amd64/x32 multilib profile just going to provide toolchain
> >> support for x32 binaries (like x86 in a x86/amd64 multilib profile), or
> >> do we want a 'full' x32 profile, where every package is built by default
> >> as x32 code?
> > 
> > this is an issue for the multilib-portage project
> 
> How is this an issue for multilib-portage?

the user picks which packages to build for which ABI.  x32 support has nothing 
to do with building every package for every available ABI.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] x32 fun pants

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 1291 bytes --]

On 15:34 Thu 15 Sep     , Mike Frysinger wrote:
> ive converted my system over to x86/amd64/x32 multilib for funs.  but i can 
> see how some people wont want all three all the time.  so the question is how 
> we want to make this available to users at the release/profile level.
> 
> background: x32 is a new ABI that runs on 64bit x86_64 processors.  see [1].  
> you'll need gcc-4.7+, binutils-2.21.50+, glibc-2.15+, and linux-3.2+.

For anyone interested how the performance compares to amd64 in more 
comprehensive tests, check out the slides from the Linux Plumbers 
Conference (particularly 14-21):

http://linuxplumbersconf.org/2011/ocw/proposals/531

In summary, on those benchmarks it looks like a small global win (maybe 
5%) on integer calculations with a few huge wins of ≥25%, but a net loss 
around 5% pretty much globally for floating-point calculations.

Most people probably do a lot more integer calculations unless they're 
science geeks like me, plus it should have lower memory use, so my 
understanding is that it probably makes sense to switch to x32 no matter 
what you're using now (x86 or amd64).

Mike, would you agree?

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] x32 fun pants

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1417 bytes --]

On Fri, 16 Sep 2011 08:36:32 -0500
Donnie Berkholz <dberkholz@gentoo.org> wrote:

> On 15:34 Thu 15 Sep     , Mike Frysinger wrote:
> > ive converted my system over to x86/amd64/x32 multilib for funs.
> > but i can see how some people wont want all three all the time.  so
> > the question is how we want to make this available to users at the
> > release/profile level.
> > 
> > background: x32 is a new ABI that runs on 64bit x86_64 processors.
> > see [1]. you'll need gcc-4.7+, binutils-2.21.50+, glibc-2.15+, and
> > linux-3.2+.
> 
> For anyone interested how the performance compares to amd64 in more 
> comprehensive tests, check out the slides from the Linux Plumbers 
> Conference (particularly 14-21):
> 
> http://linuxplumbersconf.org/2011/ocw/proposals/531
> 
> In summary, on those benchmarks it looks like a small global win
> (maybe 5%) on integer calculations with a few huge wins of ≥25%, but
> a net loss around 5% pretty much globally for floating-point
> calculations.
> 
> Most people probably do a lot more integer calculations unless
> they're science geeks like me, plus it should have lower memory use,
> so my understanding is that it probably makes sense to switch to x32
> no matter what you're using now (x86 or amd64).
> 
> Mike, would you agree?

But doesn't switching mean we're going to hit LFS PITA once again?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] x32 fun pants

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 392 bytes --]

On Friday, September 16, 2011 10:06:07 Michał Górny wrote:
> But doesn't switching mean we're going to hit LFS PITA once again?

LFS hasnt really been a pain in a long while.  but it's something worth 
raising on the x32 lists (which i'll do) since x32 has native 64bit support 
(uint64_t == %rax).  so there should be no need to have 32bit interfaces at 
all for read funcs.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] x32 fun pants

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1051 bytes --]

On Friday, September 16, 2011 12:01:43 Mike Frysinger wrote:
> On Friday, September 16, 2011 10:06:07 Michał Górny wrote:
> > But doesn't switching mean we're going to hit LFS PITA once again?
> 
> LFS hasnt really been a pain in a long while.  but it's something worth
> raising on the x32 lists (which i'll do) since x32 has native 64bit support
> (uint64_t == %rax).  so there should be no need to have 32bit interfaces at
> all for read funcs.

actually, this is already done.  in my libx32 libc.so.6, the 64bit ver is an 
alias to the 32bit ver.
  5790: 000cff00   210 FUNC    WEAK   DEFAULT   11 openat64
  6755: 000cff00   210 FUNC    WEAK   DEFAULT   11 openat
  6055: 000d07c0    92 FUNC    WEAK   DEFAULT   11 creat
  6595: 000d07c0    92 FUNC    WEAK   DEFAULT   11 creat64

so no, there shouldnt be any LFS issues with x32.  all file offsets are 64bit.

granted, if code does something like "int x = lseek(fd, 0, SEEK_CUR)", it'll 
break.  but that's irrelevant to x32 ... that's broken for all 32bit systems.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] x32 fun pants

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 785 bytes --]

On Friday, September 16, 2011 09:36:32 Donnie Berkholz wrote:
> understanding is that it probably makes sense to switch to x32 no matter
> what you're using now (x86 or amd64).

x32 needs a 64bit processor, so x86 cant go away as it's the only ABI that can 
run on 32bit processors

but for 64bit processors, it seems like x32 would be more common than x86_64.  
x32 comes with a 4GiB address space (since its pointers are 32bit), so there 
will always be a niche that wants the larger space that 64bit brings you.

so long term, i wouldnt be surprised if we move to:
	MULTILIBS="x86 amd64 x32"
	DEFAULT_ABI="x32"
or when multilib-portage lands, we default to just x32 (except glibc/gcc which 
has them all) and pull in the other two when people ask explicitly.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] x32 fun pants

[Joshua Kinard]

[-- Attachment #1: Type: text/plain, Size: 1958 bytes --]

On 09/16/2011 09:36, Donnie Berkholz wrote:

> 
> For anyone interested how the performance compares to amd64 in more 
> comprehensive tests, check out the slides from the Linux Plumbers 
> Conference (particularly 14-21):
> 
> http://linuxplumbersconf.org/2011/ocw/proposals/531
> 
> In summary, on those benchmarks it looks like a small global win (maybe 
> 5%) on integer calculations with a few huge wins of ≥25%, but a net loss 
> around 5% pretty much globally for floating-point calculations.
> 
> Most people probably do a lot more integer calculations unless they're 
> science geeks like me, plus it should have lower memory use, so my 
> understanding is that it probably makes sense to switch to x32 no matter 
> what you're using now (x86 or amd64).
> 
> Mike, would you agree?


Again, extremely similar to MIPS cases from a few years ago.  While even n32
is fairly stable in Linux (last few years, at least), the idea was always
that in an ideal multilib scenario, you'd use pure 32bits (MIPS o32) in very
limited cases (programs that just didn't work in either n32 or n64), n32 for
a majority of the system, and pure 64bit (n64) for specific applications,
like databases, crypto, or science applications.

That's supposed to provide the balance so that float-intensive apps can use
pure 64bit w/o penalty, but things that simply don't need 64bits' full power
can make use of n32/x32.

And yeah, lower memory use because the size of codewords is smaller in
memory overall.

Anyone wanting to compare x32 and n32 can see the old n32 ABI guide here:
ftp://ftp.linux-mips.org/pub/linux/mips/doc/ABI2/MIPS-N32-ABI-Handbook.pdf

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: [gentoo-dev] x32 fun pants

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 938 bytes --]

progress update:
 - binutils-2.22 in ~arch should work fine
 - glibc-2.14.1-r1 in ~arch includes support when "x32" is in MULTILIB_ABIS
 - linux-headers-3.1 includes support when "x32" is in MULTILIB_ABIS
 - you'll still need gcc-4.7 from the toolchain overlay
 - a 3.1 kernel can be obtained here: https://github.com/hjl-tools/linux

the only problem is with bootstrapping.  there is no way atm to live migrate 
between multilibs on your system.  this isn't a new problem ... we've been 
punting all bugs where people try to go from MULTILIB_ABIS="amd64" to "x86 
amd64" on a live system.  same issue applies when adding "x32" to the list.

i've been contemplating how to address this, but so far, it seems like the 
easiest is to post a glibc binpkg which includes all possible ABIs and have 
people install that first.  then they should be able to install gcc/linux-
headers freely and rebuild glibc after that.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] x32 fun pants

[Samuli Suominen]

On 12/02/2011 10:54 PM, Mike Frysinger wrote:
> progress update:
>   - linux-headers-3.1 includes support when "x32" is in MULTILIB_ABIS

so 3.1 will hit portage soon?

Re: [gentoo-dev] x32 fun pants

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 332 bytes --]

On Friday 02 December 2011 16:25:15 Samuli Suominen wrote:
> On 12/02/2011 10:54 PM, Mike Frysinger wrote:
> > progress update:
> >   - linux-headers-3.1 includes support when "x32" is in MULTILIB_ABIS
> 
> so 3.1 will hit portage soon?

as soon as the bugs in the eclass keeping the ebuild out of the tree are fixed
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] x32 fun pants

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 256 bytes --]

On Friday 02 December 2011 15:54:09 Mike Frysinger wrote:
>  - you'll still need gcc-4.7 from the toolchain overlay

i guess hjlu did a gcc-4.6 backport, so i've included that patch in 4.6.2

next step:
 - build a stage3 where x32 is the default ABI
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] x32 fun pants

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 12/02/2011 08:54 PM, Mike Frysinger wrote:
> progress update: - binutils-2.22 in ~arch should work fine -
> glibc-2.14.1-r1 in ~arch includes support when "x32" is in
> MULTILIB_ABIS - linux-headers-3.1 includes support when "x32" is in
> MULTILIB_ABIS - you'll still need gcc-4.7 from the toolchain
> overlay - a 3.1 kernel can be obtained here:
> https://github.com/hjl-tools/linux
> 
> the only problem is with bootstrapping.  there is no way atm to
> live migrate between multilibs on your system.  this isn't a new
> problem ... we've been punting all bugs where people try to go from
> MULTILIB_ABIS="amd64" to "x86 amd64" on a live system.  same issue
> applies when adding "x32" to the list.
First of all thanks for your effort. I am really looking forward to
using this new ABI. Can you please tell me which bug is the one you
are referring to? Not sure how to search for that in bugzilla

> 
> i've been contemplating how to address this, but so far, it seems
> like the easiest is to post a glibc binpkg which includes all
> possible ABIs and have people install that first.  then they should
> be able to install gcc/linux- headers freely and rebuild glibc
> after that. -mike
Do you have such a glibc binary around?

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iQIcBAEBCgAGBQJO3pOPAAoJEPqDWhW0r/LCCQwP/j5dpPBe/P6UnSljR0A39pZ0
2+f5mlqzplVBOjhdm3irR9dSkH9uIXtb7tk/Gh8rjRJi+cIWQlPFhL/ig8T3eJQX
r6YE5KmQjbEOv/W/1C0CMk9p87TqDvmZ993F6N6h403djWeTHq9SKD2Qgp76x6NZ
IaJzf3pBlYGiiAcSQ7go+yce0//NOmuS+4kxtO/n+g0jXVfO8/lGo1jCMqO3J3+k
RipGD2SokXmOZBd1pWVp+7BP0E3jDA+SAtrg7GC1yhpVLMH2vUu83ufm/jKZWheq
vo7OIQLxNhNn4wTwxPup/a3BwLrt6gbZJD2FUkMJm0NMdA3JAupFr4CdXMvxzCME
w5BxQpxeA+adhzxXlzezRdefNeULqfBSJLqFME4p14OtJ9gsK6YdsV3auwl9pvvR
IVqgT5FtHL1mEOqUC6Xt3Zq0Ya0sw7v4F6DAqIX/J17cjuGadUOHbKChI3XVKSwP
JTomOmxtDNT3rKL6aZkzMlUtqqZt07YsAFz5HoiJGVr4QaX2qjVRu2YMyoMzUN59
Rs1EmOwoQwuEKoNk+e5hZWS7mabC+BamshbA+yMEbSXh3VQymqlXIFDSUDZ9IPDW
dOlGIVjf8eCyw2/gcP00QWvW93l7BtsPw4+F1DTw/RJOpJEYnzts/C3ebTbDlWqY
qh3WsivwXEaizOVssCNI
=Zt1A
-----END PGP SIGNATURE-----

Re: [gentoo-dev] x32 fun pants

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1786 bytes --]

On Tuesday 06 December 2011 17:13:35 Markos Chandras wrote:
> On 12/02/2011 08:54 PM, Mike Frysinger wrote:
> > progress update: - binutils-2.22 in ~arch should work fine -
> > glibc-2.14.1-r1 in ~arch includes support when "x32" is in
> > MULTILIB_ABIS - linux-headers-3.1 includes support when "x32" is in
> > MULTILIB_ABIS - you'll still need gcc-4.7 from the toolchain
> > overlay - a 3.1 kernel can be obtained here:
> > https://github.com/hjl-tools/linux
> > 
> > the only problem is with bootstrapping.  there is no way atm to
> > live migrate between multilibs on your system.  this isn't a new
> > problem ... we've been punting all bugs where people try to go from
> > MULTILIB_ABIS="amd64" to "x86 amd64" on a live system.  same issue
> > applies when adding "x32" to the list.
> 
> First of all thanks for your effort. I am really looking forward to
> using this new ABI. Can you please tell me which bug is the one you
> are referring to? Not sure how to search for that in bugzilla

there isn't a specific bug on the topic.  there are random ones where people 
try to emerge gcc and it errors out when building the 32bit ABI.  this is 
generally because they started off with a no-multilib profile and then later 
switched it a multilib profile.  we've just marked them as INVALID: install a 
multilib stage3 if you want multilib.

> > i've been contemplating how to address this, but so far, it seems
> > like the easiest is to post a glibc binpkg which includes all
> > possible ABIs and have people install that first.  then they should
> > be able to install gcc/linux- headers freely and rebuild glibc
> > after that.
> 
> Do you have such a glibc binary around?

i'll post binaries here:
	http://dev.gentoo.org/~vapier/x32/
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] x32 fun pants

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 619 bytes --]

On Tuesday 06 December 2011 17:39:48 Mike Frysinger wrote:
> i'll post binaries here:
> 	http://dev.gentoo.org/~vapier/x32/

i've posted a stage3 tarball there now built with catalyst.  if people want to 
give it a spin and file bugs, that'd probably be cool.

notes:
 - don't waste time on stable packages ... your bugs will be rejected
 - when filing new bugs, check the tracker first [1], and if it isn't already 
listed, add your bug as a blocker of it
 - the default build includes all 3 ABIs for gcc/glibc
 - x32 is the default ABI

g'luck
-mike

[1] https://bugs.gentoo.org/show_bug.cgi?id=x32

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[gentoo-dev] Re: x32 fun pants

[octoploid]

Mike Frysinger <vapier <at> gentoo.org> writes:
> On Tuesday 06 December 2011 17:39:48 Mike Frysinger wrote:
> > i'll post binaries here:
> > 	http://dev.gentoo.org/~vapier/x32/
> 
> i've posted a stage3 tarball there now built with catalyst.  if people want to 
> give it a spin and file bugs, that'd probably be cool.
> 
> notes:
>  - don't waste time on stable packages ... your bugs will be rejected
>  - when filing new bugs, check the tracker first [1], and if it isn't already 
> listed, add your bug as a blocker of it
>  - the default build includes all 3 ABIs for gcc/glibc
>  - x32 is the default ABI

Nice. 
Given that it's relatively easy to hit the 4GB barrier in the
toolchain (e.g. Firefox LTO build), wouldn't it make sense to
build gcc, binutils, et.al. as 64-bit LSB executables?

Re: [gentoo-dev] Re: x32 fun pants

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 343 bytes --]

On Saturday 10 December 2011 08:15:10 octoploid wrote:
> Mike Frysinger <vapier <at> gentoo.org> writes:
> >  - x32 is the default ABI
> 
> Given that it's relatively easy to hit the 4GB barrier in the
> toolchain (e.g. Firefox LTO build), wouldn't it make sense to
> build gcc, binutils, et.al. as 64-bit LSB executables?

no
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: x32 fun pants

[Alec Warner]

On Sat, Dec 10, 2011 at 10:37 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Saturday 10 December 2011 08:15:10 octoploid wrote:
>> Mike Frysinger <vapier <at> gentoo.org> writes:
>> >  - x32 is the default ABI
>>
>> Given that it's relatively easy to hit the 4GB barrier in the
>> toolchain (e.g. Firefox LTO build), wouldn't it make sense to
>> build gcc, binutils, et.al. as 64-bit LSB executables?
>
> no
> -mike

On a completely random note, can you even build chromium with a 32-bit
linker? I vaguely recall it requiring more than 4gb of ram to link ;p

-A

Re: [gentoo-dev] Re: x32 fun pants

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 716 bytes --]

On Saturday 10 December 2011 14:36:25 Alec Warner wrote:
> On Sat, Dec 10, 2011 at 10:37 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> > On Saturday 10 December 2011 08:15:10 octoploid wrote:
> >> Mike Frysinger <vapier <at> gentoo.org> writes:
> >> >  - x32 is the default ABI
> >> 
> >> Given that it's relatively easy to hit the 4GB barrier in the
> >> toolchain (e.g. Firefox LTO build), wouldn't it make sense to
> >> build gcc, binutils, et.al. as 64-bit LSB executables?
> > 
> > no
> 
> On a completely random note, can you even build chromium with a 32-bit
> linker? I vaguely recall it requiring more than 4gb of ram to link ;p

the ebuild has x86 KEYWORDS, so presumably it works
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: x32 fun pants

[Mike Gilbert]

On Sat, Dec 10, 2011 at 2:36 PM, Alec Warner <antarus@gentoo.org> wrote:
> On Sat, Dec 10, 2011 at 10:37 AM, Mike Frysinger <vapier@gentoo.org> wrote:
>> On Saturday 10 December 2011 08:15:10 octoploid wrote:
>>> Mike Frysinger <vapier <at> gentoo.org> writes:
>>> >  - x32 is the default ABI
>>>
>>> Given that it's relatively easy to hit the 4GB barrier in the
>>> toolchain (e.g. Firefox LTO build), wouldn't it make sense to
>>> build gcc, binutils, et.al. as 64-bit LSB executables?
>>
>> no
>> -mike
>
> On a completely random note, can you even build chromium with a 32-bit
> linker? I vaguely recall it requiring more than 4gb of ram to link ;p
>
> -A
>

I think it is around 2.2 GB on amd64 with debug stuff (-ggdb). Under
half that without the debug.

I'm pretty sure there gentoo users on x86 that are able to build it;
it does have an x86 keyword afterall. :)

Re: [gentoo-dev] Re: x32 fun pants

[Chí-Thanh Christopher Nguyễn]

Mike Gilbert schrieb:
> I think it is around 2.2 GB on amd64 with debug stuff (-ggdb). Under
> half that without the debug.
> 
> I'm pretty sure there gentoo users on x86 that are able to build it;
> it does have an x86 keyword afterall. :)

Some people mess with kernel/user memory split to avoid HIGHMEM on 32
bit systems. If you do that, you might run out of address space.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Re: x32 fun pants

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 508 bytes --]

On Saturday 10 December 2011 20:36:52 Chí-Thanh Christopher Nguyễn wrote:
> Mike Gilbert schrieb:
> > I think it is around 2.2 GB on amd64 with debug stuff (-ggdb). Under
> > half that without the debug.
> > 
> > I'm pretty sure there gentoo users on x86 that are able to build it;
> > it does have an x86 keyword afterall. :)
> 
> Some people mess with kernel/user memory split to avoid HIGHMEM on 32
> bit systems. If you do that, you might run out of address space.

return -EPEBKAC
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: x32 fun pants

[Francesco Riosa]

2011/12/11 Mike Frysinger <vapier@gentoo.org>:
> On Saturday 10 December 2011 20:36:52 Chí-Thanh Christopher Nguyễn wrote:
>> Mike Gilbert schrieb:
>> > I think it is around 2.2 GB on amd64 with debug stuff (-ggdb). Under
>> > half that without the debug.
>> >
>> > I'm pretty sure there gentoo users on x86 that are able to build it;
>> > it does have an x86 keyword afterall. :)
>>
>> Some people mess with kernel/user memory split to avoid HIGHMEM on 32
>> bit systems. If you do that, you might run out of address space.
>
> return -EPEBKAC
> -mike

it's not so fast to retrieve informations on how to build the needed
kernel, could someone post instruction here, also for future
reference?

Re: [gentoo-dev] Re: x32 fun pants

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 845 bytes --]

On Monday 12 December 2011 09:47:44 Francesco Riosa wrote:
> 2011/12/11 Mike Frysinger <vapier@gentoo.org>:
> > On Saturday 10 December 2011 20:36:52 Chí-Thanh Christopher Nguyễn wrote:
> >> Mike Gilbert schrieb:
> >> > I think it is around 2.2 GB on amd64 with debug stuff (-ggdb). Under
> >> > half that without the debug.
> >> > 
> >> > I'm pretty sure there gentoo users on x86 that are able to build it;
> >> > it does have an x86 keyword afterall. :)
> >> 
> >> Some people mess with kernel/user memory split to avoid HIGHMEM on 32
> >> bit systems. If you do that, you might run out of address space.
> > 
> > return -EPEBKAC
> 
> it's not so fast to retrieve informations on how to build the needed
> kernel, could someone post instruction here, also for future
> reference?

don't mess with the defaults ?
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: x32 fun pants

[Francesco Riosa]

2011/12/12 Mike Frysinger <vapier@gentoo.org>:
> On Monday 12 December 2011 09:47:44 Francesco Riosa wrote:
>> 2011/12/11 Mike Frysinger <vapier@gentoo.org>:
>> > On Saturday 10 December 2011 20:36:52 Chí-Thanh Christopher Nguyễn wrote:
>> >> Mike Gilbert schrieb:
>> >> > I think it is around 2.2 GB on amd64 with debug stuff (-ggdb). Under
>> >> > half that without the debug.
>> >> >
>> >> > I'm pretty sure there gentoo users on x86 that are able to build it;
>> >> > it does have an x86 keyword afterall. :)
>> >>
>> >> Some people mess with kernel/user memory split to avoid HIGHMEM on 32
>> >> bit systems. If you do that, you might run out of address space.
>> >
>> > return -EPEBKAC
>>
>> it's not so fast to retrieve informations on how to build the needed
>> kernel, could someone post instruction here, also for future
>> reference?
>
> don't mess with the defaults ?
> -mike

not there yet, I was looking for this:

git clone https://github.com/hjl-tools/linux.git
git checkout hjl/x32/lfs/v3.1

when it will be finished I'll mess with the defaults

Re: [gentoo-dev] Re: x32 fun pants

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 411 bytes --]

On Monday 12 December 2011 17:47:54 Francesco Riosa wrote:
> not there yet, I was looking for this:
> 
> git clone https://github.com/hjl-tools/linux.git
> git checkout hjl/x32/lfs/v3.1

sorry, i didn't realize that's what you were looking for.  i mentioned it in 
the summary which is a parent of this e-mail ...

http://archives.gentoo.org/gentoo-dev/msg_e99aa2a9476bf9cf8385c131b96d5a75.xml
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] x32 fun pants

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 833 bytes --]

On Thursday 15 September 2011 15:34:06 Mike Frysinger wrote:
> ive converted my system over to x86/amd64/x32 multilib for funs.  but i can
> see how some people wont want all three all the time.  so the question is
> how we want to make this available to users at the release/profile level.

for profiles, i'll be doing:

arch/amd64/x32/:
contains all of the default settings for x32 as native ABI, with amd64/x86 
being supplemental

profiles/default/linux/amd64/10.0/x32/:
profile for linux x32 users to set as their /etc/make.profile

the releases will include all 3 ABIs (which only affects gcc/glibc in terms of 
overhead).  if people want to use x32 with less other ABIs, then i think the 
expected use case will be for them to set MULTILIB_ABIS in their make.conf:
	/etc/make.conf:MULTILIB_ABIS="x32"
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] x32 fun pants

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 12/08/2011 09:22 PM, Mike Frysinger wrote:
> On Thursday 15 September 2011 15:34:06 Mike Frysinger wrote:
>> ive converted my system over to x86/amd64/x32 multilib for funs.
>> but i can see how some people wont want all three all the time.
>> so the question is how we want to make this available to users at
>> the release/profile level.
> 
> for profiles, i'll be doing:
> 
> arch/amd64/x32/: contains all of the default settings for x32 as
> native ABI, with amd64/x86 being supplemental
> 
> profiles/default/linux/amd64/10.0/x32/: profile for linux x32 users
> to set as their /etc/make.profile
> 
> the releases will include all 3 ABIs (which only affects gcc/glibc
> in terms of overhead).  if people want to use x32 with less other
> ABIs, then i think the expected use case will be for them to set
> MULTILIB_ABIS in their make.conf: 
> /etc/make.conf:MULTILIB_ABIS="x32" -mike
What happens if all three ABIS are set in MULTILIB_ABIS? What would be
the default ABI for compiled binaries?

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iQIcBAEBCgAGBQJO4SwrAAoJEPqDWhW0r/LCt7AQAILp/HQPB+u14KMpEXwlmgAN
kPgaa1ariXWtb6hnw3612Neyr+t859jLtGpoaJz5mEBIyoPRngdR48Zuiiq85ugZ
f3iSp5NXBDRtgghPyNF3zQaoyD1Nm+CLV4gX3J5x8mvSpuRTDY6JpYg3zeWt5KII
FGXcpnFj2++ksRpxknamNnCh9ySUp/3sIL92ZQUDFF8xB62BAq33nlQZoPKR7izo
9TFpnn//7bWUNSZrv/dtFfVB+G9qJ7Szujh8BwFEuKje4ZX8sMw1mJ9zykKSUfYQ
vBjWMSMCPLejyMA63wF/G+pOEJPM04/zEguGRqagipFXoLTW7Jpl2Ag2rC9n+Efu
swQeTSIJALN+kqV27FsTgJviUD0JPaFqlmqmftPxX0TnN/Fg+zfz/5EMGoDI346g
Y8fV+B63isWE3ko2tmSYH8S4hww6uzbpMNL6dIguo3N57F5vOE48ZjE4LnV/8XoH
XNTN8VOoV4Pprzm8aMnN0YQ1bxbmOKpluGzoR/ho7Tki3+VWFfP9xWkY66PJ3p25
KyiMtVLrwr5unK8hhBCkz2h/OSXA2d/SvbFxjqbqCcb0b5vw3niF+Q3Tmj/+UhHx
1zEPSvmcLeADuZVa3n6rJ5p+OkLzc9Nam6atiPWySwx30Gcf0nf7o1rb2gBmpeYp
m3nswQ3uCIr1W+00N1iB
=qeSC
-----END PGP SIGNATURE-----

Re: [gentoo-dev] x32 fun pants

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 633 bytes --]

On Thursday 08 December 2011 16:29:15 Markos Chandras wrote:
> On 12/08/2011 09:22 PM, Mike Frysinger wrote:
> > the releases will include all 3 ABIs (which only affects gcc/glibc
> > in terms of overhead).  if people want to use x32 with less other
> > ABIs, then i think the expected use case will be for them to set
> > MULTILIB_ABIS in their make.conf:
> > /etc/make.conf:MULTILIB_ABIS="x32"
> 
> What happens if all three ABIS are set in MULTILIB_ABIS? What would be
> the default ABI for compiled binaries?

default ABI is controlled by $DEFAULT_ABI.  the order of $MULTILIB_ABIS does 
not matter anywhere.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] x32 fun pants

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 12/08/2011 09:34 PM, Mike Frysinger wrote:
> On Thursday 08 December 2011 16:29:15 Markos Chandras wrote:
>> On 12/08/2011 09:22 PM, Mike Frysinger wrote:
>>> the releases will include all 3 ABIs (which only affects
>>> gcc/glibc in terms of overhead).  if people want to use x32
>>> with less other ABIs, then i think the expected use case will
>>> be for them to set MULTILIB_ABIS in their make.conf: 
>>> /etc/make.conf:MULTILIB_ABIS="x32"
>> 
>> What happens if all three ABIS are set in MULTILIB_ABIS? What
>> would be the default ABI for compiled binaries?
> 
> default ABI is controlled by $DEFAULT_ABI.  the order of
> $MULTILIB_ABIS does not matter anywhere. -mike
Doh! Right I forgot. I guess we need to create a quick draft and put
it in amd64 project page. At least the MULTILIB_ABIS variable may be
useful for people who want to try that or a quick HowTo on how to live
migrate from amd64 to x32 ABIS and vice versa.

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iQIcBAEBCgAGBQJO4S7qAAoJEPqDWhW0r/LCyDcQAKEk4an48BHTYrU1s1Qf0N/c
miik8e6kZRmQwUfj/5KglkbeI27Xv84TA/duQ6hpilfKKBYVbCPg/Af0XiFe3E2s
bE+05a3qecPHYind+VVFPz4VukG2oLFGMQf2tcZH00jMRqPifnGLM7oS1bQA/fYA
oRkF3Wt0jXR9Kk8HsRxCyEnI9JVXel/bCpp/PEFYlR0a5wJgMFUshgN2dEtI2x35
J4dbOYNzAY+uH9KbR4zjFaKtcYrPxfz45fVsYPKwgOnyzTE80jP1tQXLoWMmbq0h
+pvboV4MTWr5nO9bUgCCplqAY94mxAcEaA0yqf50FesZcB/cHO100kfgss0guhy6
lMuVdnyEzjzRsYAmp9ZX/vjkDNa2MF8QnoApxU7IJ2F7AJMWZ4/RDwulP6FBlzPa
dvauZirtZjLP4Yhc1hsSHZL67ZoNVkD8HZhF9JQAIZF5511J+izZSy9iW80ITtxD
fD2ldBU4fNPzWIUPohXCOo1yXXCgwb2xMhtmLUdVLZKllF45Tv1F+mznbzDgiLeq
vXWiungeU68KnNsljYGjwlyXAWLj52CjVkogO8F8VUaSaR7qjoIStz1M/ahN5W0f
HK6KdO5nBH7aXmM6O9h+2yPyesDgGNVfkz1O+aLn0NXpUOVWI2ybVI3GkXy0xmvm
k5zWPE8EXb38MEDSNLGh
=0lPf
-----END PGP SIGNATURE-----

Re: [gentoo-dev] x32 fun pants

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1167 bytes --]

On Thursday 08 December 2011 16:40:58 Markos Chandras wrote:
> On 12/08/2011 09:34 PM, Mike Frysinger wrote:
> > On Thursday 08 December 2011 16:29:15 Markos Chandras wrote:
> >> On 12/08/2011 09:22 PM, Mike Frysinger wrote:
> >>> the releases will include all 3 ABIs (which only affects
> >>> gcc/glibc in terms of overhead).  if people want to use x32
> >>> with less other ABIs, then i think the expected use case will
> >>> be for them to set MULTILIB_ABIS in their make.conf:
> >>> /etc/make.conf:MULTILIB_ABIS="x32"
> >> 
> >> What happens if all three ABIS are set in MULTILIB_ABIS? What
> >> would be the default ABI for compiled binaries?
> > 
> > default ABI is controlled by $DEFAULT_ABI.  the order of
> > $MULTILIB_ABIS does not matter anywhere.
> 
> Doh! Right I forgot. I guess we need to create a quick draft and put
> it in amd64 project page. At least the MULTILIB_ABIS variable may be
> useful for people who want to try that or a quick HowTo on how to live
> migrate from amd64 to x32 ABIS and vice versa.

i want to hold off on that until i commit biarch support, and then verify the 
upgrade path actually works :)
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[gentoo-dev] x32 release candidate

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1688 bytes --]

i'm pleased to announce the initial x32 release candidate:
http://dev.gentoo.org/~vapier/x32/stage3-amd64-x32-20120605.tar.xz

the x32 ABI is the default one, and includes x86/amd64 ABIs.  it is not using 
/lib32/ (and /lib is not a symlink) like our existing amd64 multilib as that 
is being phased out, and the x32 port allows me to do a clean break.

i call this a release candidate as it is using glibc-2.15 with backported 
patches.  the ABI however should be the same as glibc-2.16, so hopefully the 
upgrade will go smooth.  but i don't want to make an official release on the 
chance that things aren't smooth, so this is a release candidate.

once glibc-2.16 is released upstream, we should have x32 stages released 
alongside the existing x86/amd64 stages.

caveats:
 - you have to be running linux-3.4+ with the x32 ABI enabled in your config
 - the x32 profile has marked toolchain packages stable ahead of other arches:
	- linux-headers-3.4
	- binutils-2.22
	- glibc-2.15 (and will have stable glibc-2.16)
	- gcc-4.7.0
	- strace-4.7
	- gdb-7.4.1
 - gdb will probably be flaky, but the new gdb-7.5 release should address that

so if you try running stable amd64, you will hit some failures unrelated to 
x32, but related to the newer toolchain packages.  this will get better over 
time as other packages go stable, and i'll be trying to push at least 
binutils/linux-headers stable soonish.

for the adventurous souls, please review the existing x32 tracker bug:
	https://bugs.gentoo.org/show_bug.cgi?id=x32
and file new bugs for packages you come across that aren't yet known

more reading:
	https://sites.google.com/site/x32abi/
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] x32 release candidate

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 438 bytes --]

compiler wise, you do not need to specify -mx32 yourself.  the toolchain 
defaults to the x32 ABI (and all programs in there are compiled as x32).  you 
only need -mx32 if you want to do something like distcc and execute with 
toolchains that aren't targeting x32 by default.

as for what are valid flags, pretty much everything that works with your amd64 
target will work with x32.  very little is different between them.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] x32 release candidate

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 404 bytes --]

On Tuesday 05 June 2012 14:44:13 Mike Frysinger wrote:
> i'm pleased to announce the initial x32 release candidate:
> http://dev.gentoo.org/~vapier/x32/stage3-amd64-x32-20120605.tar.xz

to be kind to infra, i've put this on the mirrors:
http://distfiles.gentoo.org/experimental/amd64/x32/

this URL will continue to work as i setup an apache redirect, but please use 
the new one anyways
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] x32 release candidate

[Gregory M. Turner]

----- Original Message -----
> i'm pleased to announce the initial x32 release candidate:
> http://dev.gentoo.org/~vapier/x32/stage3-amd64-x32-20120605.tar.xz

Also pleased to hear this!  Thanks!  Can't wait to find the time to play with it.  Did you do all that work yourself?  Is there a wiki or forum thread somewhere where folks can gloat and/or commiserate?

<OT><BS><LC>I'm cautiously hopeful/enthusiastic about x32's prospects and a prefix seems like a fantastic way to bootstrap a community which could blueprint "cheat sheets" for prospective binary package maintainers (potentially driving adoption -- at least in my fantasies -- in the Grandma Zone).</LC></BS></OT>

-gmt

Re: [gentoo-dev] x32 release candidate

[vivo75]

Il 06/06/2012 21:40, Gregory M. Turner ha scritto:
> ----- Original Message -----
>> i'm pleased to announce the initial x32 release candidate:
>> http://dev.gentoo.org/~vapier/x32/stage3-amd64-x32-20120605.tar.xz
> Also pleased to hear this!  Thanks!  Can't wait to find the time to play with it.  Did you do all that work yourself?  Is there a wiki or forum thread somewhere where folks can gloat and/or commiserate?
>
> <OT><BS><LC>I'm cautiously hopeful/enthusiastic about x32's prospects and a prefix seems like a fantastic way to bootstrap a community which could blueprint "cheat sheets" for prospective binary package maintainers (potentially driving adoption -- at least in my fantasies -- in the Grandma Zone).</LC></BS></OT>
>
> -gmt
>

seem LWN was pleased too:

http://lwn.net/Articles/500482/

Congratulations for the achievement, this has been  more than 7 month of 
work right? It would be very interesting to see were it goes.

- Francesco

Re: [gentoo-dev] x32 release candidate

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 568 bytes --]

On Wednesday 06 June 2012 15:40:18 Gregory M. Turner wrote:
> > i'm pleased to announce the initial x32 release candidate:
> > http://dev.gentoo.org/~vapier/x32/stage3-amd64-x32-20120605.tar.xz
> 
> Also pleased to hear this!  Thanks!  Can't wait to find the time to play
> with it.  Did you do all that work yourself?

H.J.Lu did all the real work in the relevant toolchain/kernel projects.  i 
merely did the distro integration.

> Is there a wiki or forum thread somewhere where folks can gloat and/or
> commiserate?

i haven't set up anything
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] x32 release candidate

[Luca Barbato]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/06/12 05:17, Mike Frysinger wrote:
> On Wednesday 06 June 2012 15:40:18 Gregory M. Turner wrote:
>>> i'm pleased to announce the initial x32 release candidate:
>>> http://dev.gentoo.org/~vapier/x32/stage3-amd64-x32-20120605.tar.xz
>>
>> Also pleased to hear this!  Thanks!  Can't wait to find the time to play
>> with it.  Did you do all that work yourself?
> 
> H.J.Lu did all the real work in the relevant toolchain/kernel projects.  i 
> merely did the distro integration.
> 
>> Is there a wiki or forum thread somewhere where folks can gloat and/or
>> commiserate?
> 
> i haven't set up anything

Shall we start a http://wiki.gentoo.org/wiki/amd64-x32 page?

> -mike


- -- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/QRnwACgkQ6Ex4woTpDjTPhACdE6Xo4tJONuO6ZjsEaAU7k4pr
QQ0AoN2yKaWZFPpVpcz+uzallp4gTV3M
=0wnw
-----END PGP SIGNATURE-----

Re: [gentoo-dev] x32 release candidate

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 480 bytes --]

On Thursday 07 June 2012 02:13:16 Luca Barbato wrote:
> On 07/06/12 05:17, Mike Frysinger wrote:
> > On Wednesday 06 June 2012 15:40:18 Gregory M. Turner wrote:
> >> Is there a wiki or forum thread somewhere where folks can gloat and/or
> >> commiserate?
> > 
> > i haven't set up anything
> 
> Shall we start a http://wiki.gentoo.org/wiki/amd64-x32 page?

assuming our wiki is sane and can handle namespaces, i'd go with:
http://wiki.gentoo.org/wiki/amd64/x32
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]