Hi,
This is the x32 project status update:
https://sites.google.com/site/x32abi/
With the latest x32 kernel semctl bug fix, C, C++ and Fortran
test results on GCC x32 branch only show one serious bug:
FAIL: gcc.c-torture/execute/builtins/strcspn.c execution, -O1
It is due to the combine issue:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49088
I am planning to prepare merging GCC x32 branch with trunk
followed by glibc and gdb patches.
The current x32 implementation uses DImode for Pmode.
I chose it because:
1. x32 process is running in 64bit mode. Hardware pointer
in x32 is 64bit.
2. x86 backend maps Pmode to hardware pointer mode.
Use SImode for Pmode requires extra changes in x86 bakend.
3. 32bit base/index are supported in x32 when they are
generated by middle-end via ptr_mode which is 32bit.
But I'd like to keep the option open to switch Pmode to
SImode later if it can provide better performance and/or
reduce the code size.
GCC x32 branch is available at:
svn://gcc.gnu.org/svn/gcc/branches/x32
Majority of changes are in x86 backend and there are also
some middle-end changes. I appreciate any feedbacks.
Thanks.
--
H.J.
On Saturday 21 May 2011 17:01:33 H.J. Lu wrote:
> This is the x32 project status update:
>
> https://sites.google.com/site/x32abi/
>
I've had another look at the kernel patch. It basically
looks all good, but the system call table appears to
diverge from the x86_64 list for no (documented) reason,
in the calls above 302. Is that intentional?
I can see why you might want to keep the numbers identical,
but if they are already different, why not use the generic
system call table from asm-generic/unistd.h for the new
ABI?
Arnd
On Sat, May 21, 2011 at 8:27 AM, Arnd Bergmann <[email protected]> wrote:
> On Saturday 21 May 2011 17:01:33 H.J. Lu wrote:
>> This is the x32 project status update:
>>
>> https://sites.google.com/site/x32abi/
>>
>
> I've had another look at the kernel patch. It basically
> looks all good, but the system call table appears to
> diverge from the x86_64 list for no (documented) reason,
> in the calls above 302. Is that intentional?
>
> I can see why you might want to keep the numbers identical,
> but if they are already different, why not use the generic
> system call table from asm-generic/unistd.h for the new
> ABI?
We can sort it out when we start merging x32 kernel changes.
--
H.J.
On Sat, May 21, 2011 at 8:34 AM, H.J. Lu <[email protected]> wrote:
> On Sat, May 21, 2011 at 8:27 AM, Arnd Bergmann <[email protected]> wrote:
>> On Saturday 21 May 2011 17:01:33 H.J. Lu wrote:
>>> This is the x32 project status update:
>>>
>>> https://sites.google.com/site/x32abi/
>>>
>>
>> I've had another look at the kernel patch. It basically
>> looks all good, but the system call table appears to
>> diverge from the x86_64 list for no (documented) reason,
>> in the calls above 302. Is that intentional?
>>
>> I can see why you might want to keep the numbers identical,
>> but if they are already different, why not use the generic
>> system call table from asm-generic/unistd.h for the new
>> ABI?
>
> We can sort it out when we start merging x32 kernel changes.
>
Peter, is that possible to use the single syscall table for
both x86-64 and x32 system calls? Out of 300+ system
calls, only 84 are different for x86-64 and x32. That
is additional 8*84 == 672 bytes in syscall table.
--
H.J.
On 05/21/2011 09:27 AM, H.J. Lu wrote:
> On Sat, May 21, 2011 at 8:34 AM, H.J. Lu <[email protected]> wrote:
>> On Sat, May 21, 2011 at 8:27 AM, Arnd Bergmann <[email protected]> wrote:
>>> On Saturday 21 May 2011 17:01:33 H.J. Lu wrote:
>>>> This is the x32 project status update:
>>>>
>>>> https://sites.google.com/site/x32abi/
>>>>
>>>
>>> I've had another look at the kernel patch. It basically
>>> looks all good, but the system call table appears to
>>> diverge from the x86_64 list for no (documented) reason,
>>> in the calls above 302. Is that intentional?
>>>
>>> I can see why you might want to keep the numbers identical,
>>> but if they are already different, why not use the generic
>>> system call table from asm-generic/unistd.h for the new
>>> ABI?
>>
>> We can sort it out when we start merging x32 kernel changes.
>>
>
> Peter, is that possible to use the single syscall table for
> both x86-64 and x32 system calls? Out of 300+ system
> calls, only 84 are different for x86-64 and x32. That
> is additional 8*84 == 672 bytes in syscall table.
>
Sort of... remember we talked about merging system calls at the tail
end? The problem with that is that some system calls (like read()!)
actually are different system calls in very subtle situations, due to
abuse in some subsystems of the is_compat() construct. I think that may
mean we have to have an unambiguous flag after all...
Now, perhaps we can use a high bit for that and mask it before dispatch,
then we don't need the additional table. A bit of a hack, but it should
work.
-hpa
On Sat, May 21, 2011 at 11:55 AM, H. Peter Anvin
<[email protected]> wrote:
> On 05/21/2011 09:27 AM, H.J. Lu wrote:
>> On Sat, May 21, 2011 at 8:34 AM, H.J. Lu <[email protected]> wrote:
>>> On Sat, May 21, 2011 at 8:27 AM, Arnd Bergmann <[email protected]> wrote:
>>>> On Saturday 21 May 2011 17:01:33 H.J. Lu wrote:
>>>>> This is the x32 project status update:
>>>>>
>>>>> https://sites.google.com/site/x32abi/
>>>>>
>>>>
>>>> I've had another look at the kernel patch. It basically
>>>> looks all good, but the system call table appears to
>>>> diverge from the x86_64 list for no (documented) reason,
>>>> in the calls above 302. Is that intentional?
>>>>
>>>> I can see why you might want to keep the numbers identical,
>>>> but if they are already different, why not use the generic
>>>> system call table from asm-generic/unistd.h for the new
>>>> ABI?
>>>
>>> We can sort it out when we start merging x32 kernel changes.
>>>
>>
>> Peter, is that possible to use the single syscall table for
>> both x86-64 and x32 system calls? Out of 300+ system
>> calls, only 84 are different for x86-64 and x32. ?That
>> is additional 8*84 == 672 bytes in syscall table.
>>
>
> Sort of... remember we talked about merging system calls at the tail
> end? ?The problem with that is that some system calls (like read()!)
> actually are different system calls in very subtle situations, due to
> abuse in some subsystems of the is_compat() construct. ?I think that may
> mean we have to have an unambiguous flag after all...
>
> Now, perhaps we can use a high bit for that and mask it before dispatch,
> then we don't need the additional table. ?A bit of a hack, but it should
> work.
How about this patch?
Merge x32 system calls with x86-64 system calls
Implemented with
1. Mark all x86-64 specific system calls with __NR_64_.
2. Mark all x32 specific system calls with __NR_x32_.
3. Include unistd_64_compat.h, instead of unistd_x32.h for kernel
build, which provides __NR_ versions of x86-64 specific system calls.
4. Append x32 specific system calls after the current x86-64 system
calls.
5. Generate unistd_x32.h from unistd_64.h, replacing __NR_x32_ with
_NR_.
6. Install user-space unistd_64.h, replacing __NR_64_ with _NR_.
--
H.J.
I'll look at it but possibly not until the weekend.
-----Original Message-----
From: H.J. Lu [[email protected]<mailto:[email protected]>]
Sent: Saturday, May 21, 2011 12:39 PM Pacific Standard Time
To: Anvin, H Peter
Cc: [email protected]; Arnd Bergmann; GCC Development; GNU C Library; LKML
Subject: Re: X32 project status update
On Sat, May 21, 2011 at 11:55 AM, H. Peter Anvin
<[email protected]> wrote:
> On 05/21/2011 09:27 AM, H.J. Lu wrote:
>> On Sat, May 21, 2011 at 8:34 AM, H.J. Lu <[email protected]> wrote:
>>> On Sat, May 21, 2011 at 8:27 AM, Arnd Bergmann <[email protected]> wrote:
>>>> On Saturday 21 May 2011 17:01:33 H.J. Lu wrote:
>>>>> This is the x32 project status update:
>>>>>
>>>>> https://sites.google.com/site/x32abi/
>>>>>
>>>>
>>>> I've had another look at the kernel patch. It basically
>>>> looks all good, but the system call table appears to
>>>> diverge from the x86_64 list for no (documented) reason,
>>>> in the calls above 302. Is that intentional?
>>>>
>>>> I can see why you might want to keep the numbers identical,
>>>> but if they are already different, why not use the generic
>>>> system call table from asm-generic/unistd.h for the new
>>>> ABI?
>>>
>>> We can sort it out when we start merging x32 kernel changes.
>>>
>>
>> Peter, is that possible to use the single syscall table for
>> both x86-64 and x32 system calls? Out of 300+ system
>> calls, only 84 are different for x86-64 and x32. That
>> is additional 8*84 == 672 bytes in syscall table.
>>
>
> Sort of... remember we talked about merging system calls at the tail
> end? The problem with that is that some system calls (like read()!)
> actually are different system calls in very subtle situations, due to
> abuse in some subsystems of the is_compat() construct. I think that may
> mean we have to have an unambiguous flag after all...
>
> Now, perhaps we can use a high bit for that and mask it before dispatch,
> then we don't need the additional table. A bit of a hack, but it should
> work.
How about this patch?
Merge x32 system calls with x86-64 system calls
Implemented with
1. Mark all x86-64 specific system calls with __NR_64_.
2. Mark all x32 specific system calls with __NR_x32_.
3. Include unistd_64_compat.h, instead of unistd_x32.h for kernel
build, which provides __NR_ versions of x86-64 specific system calls.
4. Append x32 specific system calls after the current x86-64 system
calls.
5. Generate unistd_x32.h from unistd_64.h, replacing __NR_x32_ with
_NR_.
6. Install user-space unistd_64.h, replacing __NR_64_ with _NR_.
--
H.J.
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
On Sat, May 21, 2011 at 1:01 PM, Anvin, H Peter <[email protected]> wrote:
> I'll look at it but possibly not until the weekend.
I checked it into hjl/x32/syscall branch at
http://git.kernel.org/?p=linux/kernel/git/hjl/linux-2.6.38.y.git;a=summary
H.J.
---
> -----Original Message-----
> From:?H.J. Lu [[email protected]]
> Sent:?Saturday, May 21, 2011 12:39 PM Pacific Standard Time
> To:?Anvin, H Peter
> Cc:[email protected]; Arnd Bergmann; GCC Development; GNU C Library;
> LKML
> Subject:?Re: X32 project status update
>
> On Sat, May 21, 2011 at 11:55 AM, H. Peter Anvin
> <[email protected]> wrote:
>> On 05/21/2011 09:27 AM, H.J. Lu wrote:
>>> On Sat, May 21, 2011 at 8:34 AM, H.J. Lu <[email protected]> wrote:
>>>> On Sat, May 21, 2011 at 8:27 AM, Arnd Bergmann <[email protected]> wrote:
>>>>> On Saturday 21 May 2011 17:01:33 H.J. Lu wrote:
>>>>>> This is the x32 project status update:
>>>>>>
>>>>>> https://sites.google.com/site/x32abi/
>>>>>>
>>>>>
>>>>> I've had another look at the kernel patch. It basically
>>>>> looks all good, but the system call table appears to
>>>>> diverge from the x86_64 list for no (documented) reason,
>>>>> in the calls above 302. Is that intentional?
>>>>>
>>>>> I can see why you might want to keep the numbers identical,
>>>>> but if they are already different, why not use the generic
>>>>> system call table from asm-generic/unistd.h for the new
>>>>> ABI?
>>>>
>>>> We can sort it out when we start merging x32 kernel changes.
>>>>
>>>
>>> Peter, is that possible to use the single syscall table for
>>> both x86-64 and x32 system calls? Out of 300+ system
>>> calls, only 84 are different for x86-64 and x32. ?That
>>> is additional 8*84 == 672 bytes in syscall table.
>>>
>>
>> Sort of... remember we talked about merging system calls at the tail
>> end? ?The problem with that is that some system calls (like read()!)
>> actually are different system calls in very subtle situations, due to
>> abuse in some subsystems of the is_compat() construct. ?I think that may
>> mean we have to have an unambiguous flag after all...
>>
>> Now, perhaps we can use a high bit for that and mask it before dispatch,
>> then we don't need the additional table. ?A bit of a hack, but it should
>> work.
>
> How about this patch?
>
> ?? Merge x32 system calls with x86-64 system calls
>
> ??? Implemented with
>
> ??? 1. Mark all x86-64 specific system calls with __NR_64_.
> ??? 2. Mark all x32 specific system calls with __NR_x32_.
> ??? 3. Include unistd_64_compat.h, instead of unistd_x32.h for kernel
> ??? build, which provides __NR_ versions of x86-64 specific system calls.
> ??? 4. Append x32 specific system calls after the current x86-64 system
> ??? calls.
> ??? 5. Generate unistd_x32.h from unistd_64.h, replacing __NR_x32_ with
> ??? _NR_.
> ??? 6. Install user-space unistd_64.h, replacing __NR_64_ with _NR_.
>
> --
> H.J.
>
--
H.J.
On Sat, May 21, 2011 at 4:48 PM, H.J. Lu <[email protected]> wrote:
> On Sat, May 21, 2011 at 1:01 PM, Anvin, H Peter <[email protected]> wrote:
>> I'll look at it but possibly not until the weekend.
>
> I checked it into hjl/x32/syscall branch at
>
> http://git.kernel.org/?p=linux/kernel/git/hjl/linux-2.6.38.y.git;a=summary
>
We need to investigate if we need to have different x32 syscalls for
.quad sys32_fanotify_mark
.quad compat_sys_open_by_handle_at
.quad compat_sys_clock_adjtime
.quad compat_sys_sendmmsg /* 345 */
My guess is yes for the last 3 and unsure for fanotify_mark.
H.J.
> ---
>> -----Original Message-----
>> From:?H.J. Lu [[email protected]]
>> Sent:?Saturday, May 21, 2011 12:39 PM Pacific Standard Time
>> To:?Anvin, H Peter
>> Cc:[email protected]; Arnd Bergmann; GCC Development; GNU C Library;
>> LKML
>> Subject:?Re: X32 project status update
>>
>> On Sat, May 21, 2011 at 11:55 AM, H. Peter Anvin
>> <[email protected]> wrote:
>>> On 05/21/2011 09:27 AM, H.J. Lu wrote:
>>>> On Sat, May 21, 2011 at 8:34 AM, H.J. Lu <[email protected]> wrote:
>>>>> On Sat, May 21, 2011 at 8:27 AM, Arnd Bergmann <[email protected]> wrote:
>>>>>> On Saturday 21 May 2011 17:01:33 H.J. Lu wrote:
>>>>>>> This is the x32 project status update:
>>>>>>>
>>>>>>> https://sites.google.com/site/x32abi/
>>>>>>>
>>>>>>
>>>>>> I've had another look at the kernel patch. It basically
>>>>>> looks all good, but the system call table appears to
>>>>>> diverge from the x86_64 list for no (documented) reason,
>>>>>> in the calls above 302. Is that intentional?
>>>>>>
>>>>>> I can see why you might want to keep the numbers identical,
>>>>>> but if they are already different, why not use the generic
>>>>>> system call table from asm-generic/unistd.h for the new
>>>>>> ABI?
>>>>>
>>>>> We can sort it out when we start merging x32 kernel changes.
>>>>>
>>>>
>>>> Peter, is that possible to use the single syscall table for
>>>> both x86-64 and x32 system calls? Out of 300+ system
>>>> calls, only 84 are different for x86-64 and x32. ?That
>>>> is additional 8*84 == 672 bytes in syscall table.
>>>>
>>>
>>> Sort of... remember we talked about merging system calls at the tail
>>> end? ?The problem with that is that some system calls (like read()!)
>>> actually are different system calls in very subtle situations, due to
>>> abuse in some subsystems of the is_compat() construct. ?I think that may
>>> mean we have to have an unambiguous flag after all...
>>>
>>> Now, perhaps we can use a high bit for that and mask it before dispatch,
>>> then we don't need the additional table. ?A bit of a hack, but it should
>>> work.
>>
>> How about this patch?
>>
>> ?? Merge x32 system calls with x86-64 system calls
>>
>> ??? Implemented with
>>
>> ??? 1. Mark all x86-64 specific system calls with __NR_64_.
>> ??? 2. Mark all x32 specific system calls with __NR_x32_.
>> ??? 3. Include unistd_64_compat.h, instead of unistd_x32.h for kernel
>> ??? build, which provides __NR_ versions of x86-64 specific system calls.
>> ??? 4. Append x32 specific system calls after the current x86-64 system
>> ??? calls.
>> ??? 5. Generate unistd_x32.h from unistd_64.h, replacing __NR_x32_ with
>> ??? _NR_.
>> ??? 6. Install user-space unistd_64.h, replacing __NR_64_ with _NR_.
>>
>> --
>> H.J.
>>
>
>
>
> --
> H.J.
>
--
H.J.
On Sun, May 22, 2011 at 1:02 PM, H.J. Lu <[email protected]> wrote:
> On Sat, May 21, 2011 at 4:48 PM, H.J. Lu <[email protected]> wrote:
>> On Sat, May 21, 2011 at 1:01 PM, Anvin, H Peter <[email protected]> wrote:
>>> I'll look at it but possibly not until the weekend.
>>
>> I checked it into hjl/x32/syscall branch at
>>
>> http://git.kernel.org/?p=linux/kernel/git/hjl/linux-2.6.38.y.git;a=summary
>>
>
> We need to investigate if we need to have different x32 syscalls for
>
> ? ? ? ?.quad sys32_fanotify_mark
> ? ? ? ?.quad compat_sys_open_by_handle_at
> ? ? ? ?.quad compat_sys_clock_adjtime
> ? ? ? ?.quad compat_sys_sendmmsg ? ? ? /* 345 */
>
> My guess is yes for the last 3 and unsure for fanotify_mark.
There is no need for x32 fanotify_mark. I updated hjl/x32/syscall branch
for the other 3 system calls. Should we regroup x32 system calls?
I added
/* Need it before vDSO is enabled. */
#define __NR_x32_getcpu 402
since vDSO isn't enabled for x32. It should be removed/disabled after
x32 vDSO is supported.
H.J.
>> ---
>>> -----Original Message-----
>>> From:?H.J. Lu [[email protected]]
>>> Sent:?Saturday, May 21, 2011 12:39 PM Pacific Standard Time
>>> To:?Anvin, H Peter
>>> Cc:[email protected]; Arnd Bergmann; GCC Development; GNU C Library;
>>> LKML
>>> Subject:?Re: X32 project status update
>>>
>>> On Sat, May 21, 2011 at 11:55 AM, H. Peter Anvin
>>> <[email protected]> wrote:
>>>> On 05/21/2011 09:27 AM, H.J. Lu wrote:
>>>>> On Sat, May 21, 2011 at 8:34 AM, H.J. Lu <[email protected]> wrote:
>>>>>> On Sat, May 21, 2011 at 8:27 AM, Arnd Bergmann <[email protected]> wrote:
>>>>>>> On Saturday 21 May 2011 17:01:33 H.J. Lu wrote:
>>>>>>>> This is the x32 project status update:
>>>>>>>>
>>>>>>>> https://sites.google.com/site/x32abi/
>>>>>>>>
>>>>>>>
>>>>>>> I've had another look at the kernel patch. It basically
>>>>>>> looks all good, but the system call table appears to
>>>>>>> diverge from the x86_64 list for no (documented) reason,
>>>>>>> in the calls above 302. Is that intentional?
>>>>>>>
>>>>>>> I can see why you might want to keep the numbers identical,
>>>>>>> but if they are already different, why not use the generic
>>>>>>> system call table from asm-generic/unistd.h for the new
>>>>>>> ABI?
>>>>>>
>>>>>> We can sort it out when we start merging x32 kernel changes.
>>>>>>
>>>>>
>>>>> Peter, is that possible to use the single syscall table for
>>>>> both x86-64 and x32 system calls? Out of 300+ system
>>>>> calls, only 84 are different for x86-64 and x32. ?That
>>>>> is additional 8*84 == 672 bytes in syscall table.
>>>>>
>>>>
>>>> Sort of... remember we talked about merging system calls at the tail
>>>> end? ?The problem with that is that some system calls (like read()!)
>>>> actually are different system calls in very subtle situations, due to
>>>> abuse in some subsystems of the is_compat() construct. ?I think that may
>>>> mean we have to have an unambiguous flag after all...
>>>>
>>>> Now, perhaps we can use a high bit for that and mask it before dispatch,
>>>> then we don't need the additional table. ?A bit of a hack, but it should
>>>> work.
>>>
>>> How about this patch?
>>>
>>> ?? Merge x32 system calls with x86-64 system calls
>>>
>>> ??? Implemented with
>>>
>>> ??? 1. Mark all x86-64 specific system calls with __NR_64_.
>>> ??? 2. Mark all x32 specific system calls with __NR_x32_.
>>> ??? 3. Include unistd_64_compat.h, instead of unistd_x32.h for kernel
>>> ??? build, which provides __NR_ versions of x86-64 specific system calls.
>>> ??? 4. Append x32 specific system calls after the current x86-64 system
>>> ??? calls.
>>> ??? 5. Generate unistd_x32.h from unistd_64.h, replacing __NR_x32_ with
>>> ??? _NR_.
>>> ??? 6. Install user-space unistd_64.h, replacing __NR_64_ with _NR_.
>>>
>>> --
>>> H.J.
>>>
>>
>>
>>
>> --
>> H.J.
>>
>
>
>
> --
> H.J.
>
--
H.J.
The eventual goal is to merge it with the x86-64 syscall table, although we're still working out exactly where we can do it.
-hpa
-----Original Message-----
From: Arnd Bergmann [mailto:[email protected]]
Sent: Saturday, May 21, 2011 8:28
To: H.J. Lu
Cc: GCC Development; GNU C Library; LKML; [email protected]; Anvin, H Peter
Subject: Re: X32 project status update
On Saturday 21 May 2011 17:01:33 H.J. Lu wrote:
> This is the x32 project status update:
>
> https://sites.google.com/site/x32abi/
>
I've had another look at the kernel patch. It basically
looks all good, but the system call table appears to
diverge from the x86_64 list for no (documented) reason,
in the calls above 302. Is that intentional?
I can see why you might want to keep the numbers identical,
but if they are already different, why not use the generic
system call table from asm-generic/unistd.h for the new
ABI?
Arnd
Hi,
This is the x32 project status update:
https://sites.google.com/site/x32abi/
With the latest x32 kernel, glibc, gcc and gdb, everything
works, including core dump and vDSO.
I'd like to see x32 kernel system call numbers be finalized
so that people don't have to recompile everything if the final
x32 kernel system call numbers are different from the current
one.
I started to prepare merging GCC x32 branch with trunk followed
by glibc and gdb patches. I have sent 7 middle-end patches so
far. I got feedbacks on 3 of them. I checked in one patch. I
provided one update and I am investigating the 3rd feedback.
I have more middle-end patches.
--
H.J.