Re: C6X port 13/11: MAINTAINERS
On Fri, 13 May 2011, Bernd Schmidt wrote: > Patch appended. Just raised on the steering committee. Gerald
gcc-4.3-20110522 is now available
Snapshot gcc-4.3-20110522 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20110522/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 174038 You'll find: gcc-4.3-20110522.tar.bz2 Complete GCC MD5=233566a62a8dd9f6ac7e7dff4f6259fb SHA1=386930fb019d8cee28c79e75a21fd8ce21b50513 Diffs from 4.3-20110515 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: X32 project status update
On Sat, May 21, 2011 at 4:48 PM, H.J. Lu wrote: > On Sat, May 21, 2011 at 1:01 PM, Anvin, H Peter > 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 [hjl.to...@gmail.com] >> Sent: Saturday, May 21, 2011 12:39 PM Pacific Standard Time >> To: Anvin, H Peter >> Cc: x32-...@googlegroups.com; 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 >> wrote: >>> On 05/21/2011 09:27 AM, H.J. Lu wrote: On Sat, May 21, 2011 at 8:34 AM, H.J. Lu wrote: > On Sat, May 21, 2011 at 8:27 AM, Arnd Bergmann 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.
Re: X32 project status update
On Sun, May 22, 2011 at 1:02 PM, H.J. Lu wrote: > On Sat, May 21, 2011 at 4:48 PM, H.J. Lu wrote: >> On Sat, May 21, 2011 at 1:01 PM, Anvin, H Peter >> 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 [hjl.to...@gmail.com] >>> Sent: Saturday, May 21, 2011 12:39 PM Pacific Standard Time >>> To: Anvin, H Peter >>> Cc: x32-...@googlegroups.com; 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 >>> wrote: On 05/21/2011 09:27 AM, H.J. Lu wrote: > On Sat, May 21, 2011 at 8:34 AM, H.J. Lu wrote: >> On Sat, May 21, 2011 at 8:27 AM, Arnd Bergmann 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.
