On Mon, Mar 21, 2011 at 1:20 AM, Michael Matz wrote:
> Hi,
>
> On Sun, 20 Mar 2011, H.J. Lu wrote:
>
>> I don't think it will help x32 and I think it will make it harder to add
>> x32 support. I still want to see a real usage before I add it.
>
> % cat real-world.c
> /* intptr_t; what's that? */
>
Hi,
On Sun, 20 Mar 2011, H.J. Lu wrote:
> I don't think it will help x32 and I think it will make it harder to add
> x32 support. I still want to see a real usage before I add it.
% cat real-world.c
/* intptr_t; what's that? */
union space_saving_htab_element {
void *generic_pointer;
/* Usu
On Sun, Mar 20, 2011 at 10:53 PM, Mike Frysinger wrote:
> On Monday, March 21, 2011 01:35:35 H.J. Lu wrote:
>> On Sun, Mar 20, 2011 at 10:08 PM, Mike Frysinger wrote:
>> > On Thursday, March 17, 2011 01:21:16 H.J. Lu wrote:
>> >> On Wed, Mar 16, 2011 at 7:57 PM, Mike Frysinger wrote:
>> >> > in lo
On Monday, March 21, 2011 01:35:35 H.J. Lu wrote:
> On Sun, Mar 20, 2011 at 10:08 PM, Mike Frysinger wrote:
> > On Thursday, March 17, 2011 01:21:16 H.J. Lu wrote:
> >> On Wed, Mar 16, 2011 at 7:57 PM, Mike Frysinger wrote:
> >> > in looking at the gcc files, it doesnt seem like there's any defines
On Sun, Mar 20, 2011 at 10:08 PM, Mike Frysinger wrote:
> On Thursday, March 17, 2011 01:21:16 H.J. Lu wrote:
>> On Wed, Mar 16, 2011 at 7:57 PM, Mike Frysinger wrote:
>> > in looking at the gcc files, it doesnt seem like there's any defines
>> > setup to declare x32 directly. instead, you'd hav
On Thursday, March 17, 2011 01:21:16 H.J. Lu wrote:
> On Wed, Mar 16, 2011 at 7:57 PM, Mike Frysinger wrote:
> > in looking at the gcc files, it doesnt seem like there's any defines
> > setup to declare x32 directly. instead, you'd have to do something
> > like: #ifdef __x86_64__
> > # if __SIZEO
On 03/16/2011 10:21 PM, H.J. Lu wrote:
> On Wed, Mar 16, 2011 at 7:57 PM, Mike Frysinger wrote:
>> On Wednesday, March 16, 2011 08:39:57 H.J. Lu wrote:
>>> On Tue, Mar 15, 2011 at 10:24 PM, Mike Frysinger wrote:
so we get back to my original e-mail:
are you getting a unique host t
On Wed, Mar 16, 2011 at 10:45 PM, Mike Frysinger wrote:
> On Thursday, March 17, 2011 01:21:16 H.J. Lu wrote:
>> On Wed, Mar 16, 2011 at 7:57 PM, Mike Frysinger wrote:
>> > ok, took long enough, but that answers most things. your usage of "x32-"
>> > prefixed binaries in the documentation seems
On Thursday, March 17, 2011 01:21:16 H.J. Lu wrote:
> On Wed, Mar 16, 2011 at 7:57 PM, Mike Frysinger wrote:
> > ok, took long enough, but that answers most things. your usage of "x32-"
> > prefixed binaries in the documentation seems to imply a lot more than the
> > fact you just picked those lo
On Wed, Mar 16, 2011 at 7:57 PM, Mike Frysinger wrote:
> On Wednesday, March 16, 2011 08:39:57 H.J. Lu wrote:
>> On Tue, Mar 15, 2011 at 10:24 PM, Mike Frysinger wrote:
>> > so we get back to my original e-mail:
>> > are you getting a unique host tuple for this ? or are you
>> > extending
On Wednesday, March 16, 2011 08:39:57 H.J. Lu wrote:
> On Tue, Mar 15, 2011 at 10:24 PM, Mike Frysinger wrote:
> > so we get back to my original e-mail:
> >are you getting a unique host tuple for this ? or are you
> > extending x86_64-linux-gnu ? so the only way of knowing which ABI is to
Mike Frysinger writes:
> but it doesnt say what to do for binutils or gcc itself. obviously you cant
> use the -mx32 flag when building the cross gcc for the first time since the
> current native gcc wont support it.
Of course, for a compiler tool the only thing that matters is the
target.
A
On Tue, Mar 15, 2011 at 10:24 PM, Mike Frysinger wrote:
> On Wednesday, March 16, 2011 00:51:37 H.J. Lu wrote:
>> On Tue, Mar 15, 2011 at 9:30 PM, Mike Frysinger wrote:
>> > On Wednesday, March 16, 2011 00:17:04 H.J. Lu wrote:
>> >> On Mon, Mar 7, 2011 at 1:33 PM, Mike Frysinger wrote:
>> >> > On
On Wednesday, March 16, 2011 00:51:37 H.J. Lu wrote:
> On Tue, Mar 15, 2011 at 9:30 PM, Mike Frysinger wrote:
> > On Wednesday, March 16, 2011 00:17:04 H.J. Lu wrote:
> >> On Mon, Mar 7, 2011 at 1:33 PM, Mike Frysinger wrote:
> >> > On Saturday, March 05, 2011 14:08:04 H.J. Lu wrote:
> >> >> Many
On Tue, Mar 15, 2011 at 9:30 PM, Mike Frysinger wrote:
> On Wednesday, March 16, 2011 00:17:04 H.J. Lu wrote:
>> On Mon, Mar 7, 2011 at 1:33 PM, Mike Frysinger wrote:
>> > On Saturday, March 05, 2011 14:08:04 H.J. Lu wrote:
>> >> Many x32 bugs are fixed in kernel, glibc, binutils and GCC:
>> >>
>>
On Wednesday, March 16, 2011 00:17:04 H.J. Lu wrote:
> On Mon, Mar 7, 2011 at 1:33 PM, Mike Frysinger wrote:
> > On Saturday, March 05, 2011 14:08:04 H.J. Lu wrote:
> >> Many x32 bugs are fixed in kernel, glibc, binutils and GCC:
> >>
> >> https://sites.google.com/site/x32abi/
> >>
> >> The major
Hi,
Almost all x32 bugs in kernel, glibc and binutils are fixed:
https://sites.google.com/site/x32abi/
There are no unexpected failures in glibc testsuite. I am
working on remaining GCC bugs.
--
H.J.
On Mon, Mar 7, 2011 at 1:33 PM, Mike Frysinger wrote:
> On Saturday, March 05, 2011 14:08:04 H.J. Lu wrote:
>> Many x32 bugs are fixed in kernel, glibc, binutils and GCC:
>>
>> https://sites.google.com/site/x32abi/
>>
>> The major remaining issues are glibc/gcc testsuite failures,
>> kernel core d
On Saturday, March 05, 2011 14:08:04 H.J. Lu wrote:
> Many x32 bugs are fixed in kernel, glibc, binutils and GCC:
>
> https://sites.google.com/site/x32abi/
>
> The major remaining issues are glibc/gcc testsuite failures,
> kernel core dump and signal handler unwind.
are you getting a unique host
On Sat, Mar 5, 2011 at 11:08 AM, H.J. Lu wrote:
> Hi,
>
> Many x32 bugs are fixed in kernel, glibc, binutils and GCC:
>
> https://sites.google.com/site/x32abi/
>
> The major remaining issues are glibc/gcc testsuite failures,
> kernel core dump and signal handler unwind.
>
I checked in a kernel pa
Hi,
Many x32 bugs are fixed in kernel, glibc, binutils and GCC:
https://sites.google.com/site/x32abi/
The major remaining issues are glibc/gcc testsuite failures,
kernel core dump and signal handler unwind.
--
H.J.
More data
* 186.crafty from SPEC CPU 2000 (64bit integer):
o Intel Core i7
+ ~5% slower than x86-64.
+ ~29% faster than ia32.
+ Sizes in bytes:
text databssdec
hexfilename
On Fri, Feb 18, 2011 at 8:28 PM, H.J. Lu wrote:
> On Wed, Feb 16, 2011 at 9:45 PM, H.J. Lu wrote:
>> On Wed, Feb 16, 2011 at 11:22 AM, H.J. Lu wrote:
>>> Hi,
>>>
>>> I updated x32 psABI draft to version 0.2 to change x32 library path
>>> from lib32 to libx32 since lib32 is used for ia32 librari
On Wed, Feb 16, 2011 at 9:45 PM, H.J. Lu wrote:
> On Wed, Feb 16, 2011 at 11:22 AM, H.J. Lu wrote:
>> Hi,
>>
>> I updated x32 psABI draft to version 0.2 to change x32 library path
>> from lib32 to libx32 since lib32 is used for ia32 libraries on Debian,
>> Ubuntu and other derivative distributio
On Wed, Feb 16, 2011 at 11:22 AM, H.J. Lu wrote:
> Hi,
>
> I updated x32 psABI draft to version 0.2 to change x32 library path
> from lib32 to libx32 since lib32 is used for ia32 libraries on Debian,
> Ubuntu and other derivative distributions. The new x32 psABI is
> available from:
>
> https://s
On 02/13/2011 03:39 PM, Alan Cox wrote:
a. the int $0x80 instruction is much slower than syscall. An actual
i386 process can use the syscall instruction which is disambiguated
by the CPU based on mode, but an x32 process is in the same CPU mode
as a normal 64-bit process.
So set a
On 02/13/2011 01:33 PM, Alan Cox wrote:
Who actually needs this new extra API - whats the justification for
everyone having more crud dumping their kernels, more syscall paths
(which are one of the most security critical areas) and the like.
What are the benchmark numbers to justify this versus
On Sun, Feb 13, 2011 at 3:39 PM, Alan Cox wrote:
>> a. the int $0x80 instruction is much slower than syscall. An actual
>> i386 process can use the syscall instruction which is disambiguated
>> by the CPU based on mode, but an x32 process is in the same CPU mode
>> as a normal 64-bit pro
> a. the int $0x80 instruction is much slower than syscall. An actual
>i386 process can use the syscall instruction which is disambiguated
>by the CPU based on mode, but an x32 process is in the same CPU mode
>as a normal 64-bit process.
So set a flag, whoopee
> b. 64-bit arguments h
On Sun, Feb 13, 2011 at 2:57 PM, Arnd Bergmann wrote:
>
>> The cost of an entire different ABI layer (supporting a new memory layout)
>> would be enormous, a.k.a. "not worth it", which is why the memory layout
>> of kernel objects needs to be compatible with i386.
>
> Right, this makes sense, you
On Sunday 13 February 2011, H. Peter Anvin wrote:
> We prototyped using the int $0x80 system call entry point. However,
> there are two disadvantages:
>
> a. the int $0x80 instruction is much slower than syscall. An actual
>i386 process can use the syscall instruction which is disambiguated
On 02/13/2011 02:28 PM, Arnd Bergmann wrote:
> On Sunday 13 February 2011, H. Peter Anvin wrote:
>> The actual idea is to use the i386 compat ABI for memory layout, but
>> with a 64-bit register convention. That means that system calls that
>> don't make references to memory structures can simply
On Sunday 13 February 2011, H. Peter Anvin wrote:
> The actual idea is to use the i386 compat ABI for memory layout, but
> with a 64-bit register convention. That means that system calls that
> don't make references to memory structures can simply use the 64-bit
> system calls, otherwise we're pla
On 02/13/2011 01:16 PM, H. Peter Anvin wrote:
>
> The actual idea is to use the i386 compat ABI for memory layout, but
> with a 64-bit register convention. That means that system calls that
> don't make references to memory structures can simply use the 64-bit
> system calls, otherwise we're plan
On Sun, Feb 13, 2011 at 2:03 PM, H. Peter Anvin wrote:
> On 02/13/2011 01:28 PM, H.J. Lu wrote:
>>
>> That is is currently implemented on hjl/x32 branch.
>>
>> I also added
>>
>> __NR_sigaction
>> __NR_sigpending
>> __NR_sigprocmask
>> __NR_sigsuspend
>>
>> to help the Bionic C library.
>>
>
> Tha
On 02/13/2011 01:28 PM, H.J. Lu wrote:
>
> That is is currently implemented on hjl/x32 branch.
>
> I also added
>
> __NR_sigaction
> __NR_sigpending
> __NR_sigprocmask
> __NR_sigsuspend
>
> to help the Bionic C library.
>
That seems a little redundant... even on the i386 front we want people
> The actual idea is to use the i386 compat ABI for memory layout, but
> with a 64-bit register convention. That means that system calls that
> don't make references to memory structures can simply use the 64-bit
> system calls, otherwise we're planning to reuse the i386 compat system
> calls, but
On Sun, Feb 13, 2011 at 1:16 PM, H. Peter Anvin wrote:
> On 02/13/2011 01:10 PM, H.J. Lu wrote:
>>> The basic concept looks entirely reasonable to me, but I'm
>>> curious what drove the decision to start out with the x86_64
>>> system calls instead of the generic ones.
>>>
>>> Since tile was merge
On 02/13/2011 01:10 PM, H.J. Lu wrote:
>>>
>>> 1. Kernel interface with syscall is close to be finalized.
>>
I don't think calling it "finalized" is accurate... it is more
accurately described as "prototyped".
>> Really? I haven't seen this being posted for review yet ;-)
>>
>> The basic concept
On Sun, Feb 13, 2011 at 12:10 PM, Arnd Bergmann wrote:
> On Saturday 12 February 2011 20:41:01 H.J. Lu wrote:
>> Hi,
>>
>> We made lots of progresses on x32 pABI:
>>
>> https://sites.google.com/site/x32abi/
>>
>> 1. Kernel interface with syscall is close to be finalized.
>
> Really? I haven't seen
On Saturday 12 February 2011 20:41:01 H.J. Lu wrote:
> Hi,
>
> We made lots of progresses on x32 pABI:
>
> https://sites.google.com/site/x32abi/
>
> 1. Kernel interface with syscall is close to be finalized.
Really? I haven't seen this being posted for review yet ;-)
The basic concept looks en
On Sun, 13 Feb 2011, Petr Baudis wrote:
> I think it would be great if you could add some text like this plus some
> rationale (AIUI, this is geared mainly at new Atoms and other x86_64
> embedded platforms) to the document.
>
> (BTW, it is not really convincing to me that such a niche is worth a
2011/2/13 Petr Baudis :
> On Sun, Feb 13, 2011 at 07:13:57AM -0800, H.J. Lu wrote:
>> On Sun, Feb 13, 2011 at 7:07 AM, Florian Weimer wrote:
>> > * H. J. Lu:
>> >
>> >>> Actually, I'm wondering if you can do the translation in user space.
>> >>> There already are 32-on-64 implementations in existe
On Sun, Feb 13, 2011 at 07:13:57AM -0800, H.J. Lu wrote:
> On Sun, Feb 13, 2011 at 7:07 AM, Florian Weimer wrote:
> > * H. J. Lu:
> >
> >>> Actually, I'm wondering if you can do the translation in user space.
> >>> There already are 32-on-64 implementations in existence, without
> >>> kernel chang
On Sun, Feb 13, 2011 at 7:43 AM, Maciej W. Rozycki wrote:
> On Sun, 13 Feb 2011, Florian Weimer wrote:
>
>> >> Actually, I'm wondering if you can do the translation in user space.
>> >> There already are 32-on-64 implementations in existence, without
>> >> kernel changes (recent Hotspot, LuaJIT, a
On Sun, 13 Feb 2011, Florian Weimer wrote:
> >> Actually, I'm wondering if you can do the translation in user space.
> >> There already are 32-on-64 implementations in existence, without
> >> kernel changes (recent Hotspot, LuaJIT, and probably some more).
> >
> > Please check out the x32 kernel s
On Sun, Feb 13, 2011 at 7:21 AM, Florian Weimer wrote:
> * H. J. Lu:
>
>> On Sun, Feb 13, 2011 at 7:07 AM, Florian Weimer wrote:
>>> * H. J. Lu:
>>>
> Actually, I'm wondering if you can do the translation in user space.
> There already are 32-on-64 implementations in existence, without
>>
* H. J. Lu:
> On Sun, Feb 13, 2011 at 7:07 AM, Florian Weimer wrote:
>> * H. J. Lu:
>>
Actually, I'm wondering if you can do the translation in user space.
There already are 32-on-64 implementations in existence, without
kernel changes (recent Hotspot, LuaJIT, and probably some mor
On Sun, Feb 13, 2011 at 7:07 AM, Florian Weimer wrote:
> * H. J. Lu:
>
>>> Actually, I'm wondering if you can do the translation in user space.
>>> There already are 32-on-64 implementations in existence, without
>>> kernel changes (recent Hotspot, LuaJIT, and probably some more).
>>
>> Please che
* H. J. Lu:
>> Actually, I'm wondering if you can do the translation in user space.
>> There already are 32-on-64 implementations in existence, without
>> kernel changes (recent Hotspot, LuaJIT, and probably some more).
>
> Please check out the x32 kernel source and provide feedback.
I still don'
On Sun, Feb 13, 2011 at 12:48 AM, Florian Weimer wrote:
> * H. Peter Anvin:
>
>> On 02/12/2011 01:10 PM, Florian Weimer wrote:
>>> Why is the ia32 compatiblity kernel interface used?
>>
>> Because there is no way in hell we're designing in a second
>> compatibility ABI in the kernel (and it has to
On Sat, Feb 12, 2011 at 9:47 PM, Matt Thomas wrote:
>
> On Feb 12, 2011, at 7:02 PM, Andrew Pinski wrote:
>
>> On Sat, Feb 12, 2011 at 3:04 PM, H. Peter Anvin wrote:
>>> On 02/12/2011 01:10 PM, Florian Weimer wrote:
Why is the ia32 compatiblity kernel interface used?
>>>
>>> Because there is
* H. Peter Anvin:
> On 02/12/2011 01:10 PM, Florian Weimer wrote:
>> Why is the ia32 compatiblity kernel interface used?
>
> Because there is no way in hell we're designing in a second
> compatibility ABI in the kernel (and it has to be a compatibility ABI,
> because of the pointer size difference
On Feb 12, 2011, at 7:02 PM, Andrew Pinski wrote:
> On Sat, Feb 12, 2011 at 3:04 PM, H. Peter Anvin wrote:
>> On 02/12/2011 01:10 PM, Florian Weimer wrote:
>>> Why is the ia32 compatiblity kernel interface used?
>>
>> Because there is no way in hell we're designing in a second
>> compatibility
On Sat, Feb 12, 2011 at 3:04 PM, H. Peter Anvin wrote:
> On 02/12/2011 01:10 PM, Florian Weimer wrote:
>> Why is the ia32 compatiblity kernel interface used?
>
> Because there is no way in hell we're designing in a second
> compatibility ABI in the kernel (and it has to be a compatibility ABI,
> b
On 02/12/2011 01:10 PM, Florian Weimer wrote:
> Why is the ia32 compatiblity kernel interface used?
Because there is no way in hell we're designing in a second
compatibility ABI in the kernel (and it has to be a compatibility ABI,
because of the pointer size difference.)
-hpa
--
H. Pete
On Feb 12, 2011, at 1:29 PM, H.J. Lu wrote:
> On Sat, Feb 12, 2011 at 1:10 PM, Florian Weimer wrote:
>> * H. J. Lu:
>>
>>> We made lots of progresses on x32 pABI:
>>>
>>> https://sites.google.com/site/x32abi/
>>>
>>> 1. Kernel interface with syscall is close to be finalized.
>>> 2. GCC x32 br
On Sat, Feb 12, 2011 at 1:10 PM, Florian Weimer wrote:
> * H. J. Lu:
>
>> We made lots of progresses on x32 pABI:
>>
>> https://sites.google.com/site/x32abi/
>>
>> 1. Kernel interface with syscall is close to be finalized.
>> 2. GCC x32 branch is stabilizing.
>> 3. The Bionic C library works with
* H. J. Lu:
> We made lots of progresses on x32 pABI:
>
> https://sites.google.com/site/x32abi/
>
> 1. Kernel interface with syscall is close to be finalized.
> 2. GCC x32 branch is stabilizing.
> 3. The Bionic C library works with the syscall kernel interface.
>
> The next major milestone will be
Hi,
We made lots of progresses on x32 pABI:
https://sites.google.com/site/x32abi/
1. Kernel interface with syscall is close to be finalized.
2. GCC x32 branch is stabilizing.
3. The Bionic C library works with the syscall kernel interface.
The next major milestone will be x32 glibc port.
--
H
60 matches
Mail list logo
