From sjmunroe at us.ibm.com Tue Oct 1 01:38:16 2002 From: sjmunroe at us.ibm.com (Steve Munroe) Date: Mon, 30 Sep 2002 10:38:16 -0500 Subject: msqid_ds/semid_ds/shmid_ds and time fields Message-ID: We are trying to clean up the last of the 64-bit glibc-2.2.5 and glibc-2.3 changes for PPC64-linux and have run into a stumbling block. We are running LTP test and fixing up both PPC32 and PPC64 bugs. And one the key issues is getting structs used by the glibc and the kernel to match. Many of the structs used in PPC32 have "unused" and "pad" fields that don't seem to make any sense for PPC64. For example: /* Structure of record for one message inside the kernel. The type `struct msg' is opaque. */ struct msqid_ds { struct ipc_perm msg_perm; /* structure describing operation permission */ unsigned int __unused1; __time_t msg_stime; /* time of last msgsnd command */ unsigned int __unused2; __time_t msg_rtime; /* time of last msgrcv command */ unsigned int __unused3; __time_t msg_ctime; /* time of last change */ unsigned long __msg_cbytes; /* current number of bytes on queue */ msgqnum_t msg_qnum; /* number of messages currently on queue */ msglen_t msg_qbytes; /* max number of bytes allowed on queue */ __pid_t msg_lspid; /* pid of last msgsnd() */ __pid_t msg_lrpid; /* pid of last msgrcv() */ unsigned long __unused4; unsigned long __unused5; }; Note that each __time_t field is preceded with a 32-bit "unused". We assumed that the intent was to migrate to 64-bit __time_t and that PPC64 should just used a single 64-bit __time_t field without the "unused" cruft. This aligns the 32-bit __time_t with the low order bits of the 64-bit __time_t and provides a 64-bit upgrade path to PPC32. So we defined a common (PPC32/PPC64) glibc powerpc/bits/msq.h as: struct msqid_ds { struct ipc_perm msg_perm; /* structure describing operation permission */ #if __WORDSIZE == 32 unsigned int __unused1; #endif __time_t msg_stime; /* time of last msgsnd command */ #if __WORDSIZE == 32 unsigned int __unused2; #endif __time_t msg_rtime; /* time of last msgrcv command */ #if __WORDSIZE == 32 unsigned int __unused3; #endif __time_t msg_ctime; /* time of last change */ unsigned long __msg_cbytes; /* current number of bytes on queue */ msgqnum_t msg_qnum; /* number of messages currently on queue */ msglen_t msg_qbytes; /* max number of bytes allowed on queue */ __pid_t msg_lspid; /* pid of last msgsnd() */ __pid_t msg_lrpid; /* pid of last msgrcv() */ unsigned long __unused4; unsigned long __unused5; }; Which produced (what we though was the desired effect. Ditto for sem.h and shm.h. But when I submitted the patches to glibc they where rejected with the following not from Ulrich Drepper: "That's stupid. The unused field is meant to be used for sub-second information. There is (fortunately) again discussion about adding support to the kernel. You'd shut out ppc64 of this, doomed to live with full second numbers." When I pointed out to Ulrich the we (PPC64) where only following the lead of s390 and x86_64 he responded: "I don't say that these architectures don't have the same problem." So "kernel folks": Can anyone point me to the kernel discussions about adding sub-seconds to structs used in these syscalls? When sub-seconds are added how should it be layed out: 1) Like above with sub-seconds then seconds as implied above? 2) Replace __time_t with a __timeval (which would be seconds followed by sub-seconds)? 3) Some other format? ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From bergner at vnet.ibm.com Tue Oct 1 12:41:37 2002 From: bergner at vnet.ibm.com (Peter Bergner) Date: Mon, 30 Sep 2002 21:41:37 -0500 Subject: [PATCH] systemcfg Message-ID: <3D990B61.3070600@vnet.ibm.com> Here's the first pass at the systemcfg changes we've promised to several people. Let me know what you think. This or something like it needs to make it to SuSE _very_ soon! Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: systemcfg.diff.gz Type: application/x-gzip Size: 16419 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20020930/7717a57c/attachment.bin From anton at samba.org Sun Oct 6 11:02:26 2002 From: anton at samba.org (Anton Blanchard) Date: Sun, 6 Oct 2002 11:02:26 +1000 Subject: msqid_ds/semid_ds/shmid_ds and time fields In-Reply-To: References: Message-ID: <20021006010226.GA22888@krispykreme> > Can anyone point me to the kernel discussions about adding sub-seconds to > structs used in these syscalls? Its beginning. Andi just posted this to linux-kernel with the subject: [PATCH] struct timespec for stat diff -burp -X ../KDIFX linux/include/asm-ppc64/stat.h linux-2.5.40-work/include/asm-ppc64/stat.h --- linux/include/asm-ppc64/stat.h 2002-09-25 00:59:27.000000000 +0200 +++ linux-2.5.40-work/include/asm-ppc64/stat.h 2002-10-05 18:46:15.000000000 +0200 @@ -36,15 +36,17 @@ struct stat { unsigned long st_blksize; unsigned long st_blocks; unsigned long st_atime; - unsigned long __unused1; + unsigned long st_atime_nsec; unsigned long st_mtime; - unsigned long __unused2; + unsigned long st_mtime_nsec; unsigned long st_ctime; - unsigned long __unused3; + unsigned long st_ctime_nsec; unsigned long __unused4; unsigned long __unused5; }; +#define STAT_HAVE_NSEC 1 + /* This matches struct stat64 in glibc2.1. */ struct stat64 { unsigned long st_dev; /* Device. */ @@ -60,11 +62,11 @@ struct stat64 { long st_blocks; /* Number 512-byte blocks allocated. */ int st_atime; /* Time of last access. */ - unsigned int __unused1; + int st_atime_nsec; int st_mtime; /* Time of last modification. */ - unsigned int __unused2; + int st_mtime_nsec; int st_ctime; /* Time of last status change. */ - unsigned int __unused3; + int st_ctime_nsec; unsigned int __unused4; unsigned int __unused5; }; ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Tue Oct 8 00:28:55 2002 From: anton at samba.org (Anton Blanchard) Date: Tue, 8 Oct 2002 00:28:55 +1000 Subject: syscall update Message-ID: <20021007142855.GA12424@krispykreme> Hi, The following patch: 1. removes the old select syscall from 32 and 64 bit. We never had a libc that used this syscall and the current kernel code doesnt support the calling convention. 2. remove oldumount, olduname, oldgetrlimit and oldreaddir from 64 bit. If there are no complaints I'll check it into 2.4 tomorrow morning my time. Anton Index: arch/ppc64/kernel/misc.S =================================================================== RCS file: /cvs/linuxppc64/linuxppc64_2_4/arch/ppc64/kernel/misc.S,v retrieving revision 1.44 diff -u -r1.44 misc.S --- arch/ppc64/kernel/misc.S 18 Sep 2002 04:55:15 -0000 1.44 +++ arch/ppc64/kernel/misc.S 7 Oct 2002 14:25:05 -0000 @@ -585,7 +585,7 @@ .llong .sys32_settimeofday .llong .sys32_getgroups /* 80 */ .llong .sys32_setgroups - .llong .ppc32_select + .llong .sys_ni_syscall /* old select syscall */ .llong .sys_symlink .llong .sys32_lstat .llong .sys32_readlink /* 85 */ @@ -756,7 +756,7 @@ .llong .sys_lseek .llong .sys_getpid /* 20 */ .llong .sys_mount - .llong .sys_oldumount + .llong .sys_ni_syscall /* old umount syscall */ .llong .sys_setuid .llong .sys_getuid .llong .ppc64_sys_stime /* 25 */ @@ -793,7 +793,7 @@ .llong .sys_ni_syscall /* old mpx syscall holder */ .llong .sys_setpgid .llong .sys_ni_syscall /* old ulimit syscall holder */ - .llong .sys_olduname + .llong .sys_ni_syscall /* old uname syscall */ .llong .sys_umask /* 60 */ .llong .sys_chroot .llong .sys_ustat @@ -810,20 +810,20 @@ .llong .sys_sigpending .llong .sys_sethostname .llong .sys_setrlimit /* 75 */ - .llong .sys_old_getrlimit + .llong .sys_ni_syscall /* old getrlimit syscall */ .llong .sys_getrusage .llong .sys_gettimeofday .llong .sys_settimeofday .llong .sys_getgroups /* 80 */ .llong .sys_setgroups - .llong .sys_select + .llong .sys_ni_syscall /* old select syscall */ .llong .sys_symlink .llong .sys_lstat .llong .sys_readlink /* 85 */ .llong .sys_uselib .llong .sys_swapon .llong .sys_reboot - .llong .old_readdir + .llong .sys_ni_syscall /* old readdir syscall */ .llong .sys_mmap /* 90 */ .llong .sys_munmap .llong .sys_truncate ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From sjmunroe at us.ibm.com Tue Oct 8 00:44:03 2002 From: sjmunroe at us.ibm.com (Steve Munroe) Date: Mon, 7 Oct 2002 09:44:03 -0500 Subject: msqid_ds/semid_ds/shmid_ds and time fields Message-ID: Anton Blanchard writes: > > Can anyone point me to the kernel discussions about adding sub-seconds to > > structs used in these syscalls? > > Its beginning. Andi just posted this to linux-kernel with the subject: > [PATCH] struct timespec for stat > > diff -burp -X ../KDIFX linux/include/asm-ppc64/stat.h linux-2.5.40-work/include/asm-ppc64/stat.h > --- linux/include/asm-ppc64/stat.h 2002-09-25 00:59:27.000000000 +0200 > +++ linux-2.5.40-work/include/asm-ppc64/stat.h 2002-10-05 18:46:15.000000000 +0200 > @@ -36,15 +36,17 @@ struct stat { > ... OK this is stat, and we follow the other 64-bit archs which retain the pads. So we are OK. I can see why they want some solution to this because Make is having difficulties with file time stamps on fast machines. But the patches that Drepper rejected where for msq.h, sem.h, and shm.h (msqid_ds, semid_ds, shmid_ds). Here the other 64-bit archs removed the pads an left 64-bit time_t only. Any discussion about changing these structs? ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From ganich73 at yahoo.com Wed Oct 9 11:43:27 2002 From: ganich73 at yahoo.com (Viktor Ganich) Date: Tue, 8 Oct 2002 18:43:27 -0700 (PDT) Subject: building 64-bit cross compiler Message-ID: <20021009014327.4720.qmail@web21407.mail.yahoo.com> I am trying to build gcc compiler on 64-bit PowerPC machine with SLES-8 beta 2 version installed. I am following instruction published on linux64ppc.org site, I was able to config, build and install latest binutils and gcc 3.2 (pass one as it is mentioned on linuxppc64.org ) after that I built and installed glibc. Then I configured the kernel for PPC64 (as it is required, I changed CROSS_COMPILE in Makefile to point to $PREFIX/bin/powerpc64-linux- ). Then I built and installed binutils with enable-shared option (pass two), but after that I cannot rebuild and install gcc again (pass two). I checked the log file after I run configure for gcc (in pass two), it says that I already have in $PREFIX/powerpc64-linux/bin cross compiler, is that right or no ? But the main question for me is: do we build native or cross compiler during the second pass ? As from log files I noticed that I am building native one using previously built cross compiler (after pass one). ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From peter at bergner.org Wed Oct 9 14:55:33 2002 From: peter at bergner.org (Peter Bergner) Date: Tue, 8 Oct 2002 23:55:33 -0500 Subject: building 64-bit cross compiler In-Reply-To: <20021009014327.4720.qmail@web21407.mail.yahoo.com> References: <20021009014327.4720.qmail@web21407.mail.yahoo.com> Message-ID: <20021008235533.B1153569@brule.borg.umn.edu> Viktor Ganich wrote: : I am trying to build gcc compiler on 64-bit PowerPC : machine with SLES-8 beta 2 version installed. If you really need a 64-bit toolchain and you can't get one built, there's an rpm on the CD's which gets installed in /opt/cross/. : I am following instruction published on linux64ppc.org : site, I was able to config, build and install latest : binutils and gcc 3.2 (pass one as it is : mentioned on linuxppc64.org ) after that I built and : installed glibc. I _really_ need to fix those directions! :( Note that the directions at www.linuxppc64.org recommend you use "--prefix="/opt/ppc64" as a prefix directory. This is not strictly correct. Assuming you used that as your prefix directory for the binutils and gcc builds, then you'd want to use "--prefix="/opt/ppc64/powerpc64-linux" for your glibc build. What is your goal, just to compile ppc64 kernels ro do you want to build 64-bit applications as well? If you only want to build kernels, you only need to build binutils and gcc. : Then I built and installed binutils with enable-shared : option (pass two), but after that I cannot rebuild and : install gcc again (pass two). You can skip the second build of binutils (--enable-shared). : But the main question for me is: do we build native or : cross compiler during the second pass ? As from log : files I noticed that I am building native one using : previously built cross compiler (after pass one). The 64-bit toolchain (ie, powerpc64-linux-{as,ld,gcc,...} are all 32-bit cross tools. So no native binaries. Peter ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Wed Oct 9 19:21:28 2002 From: anton at samba.org (Anton Blanchard) Date: Wed, 9 Oct 2002 19:21:28 +1000 Subject: 64bit LTP Message-ID: <20021009092128.GU5947@krispykreme> Hi, Has anyone investigated the readdir01 LTP failure? It seems like we arent resetting errno. fcntl64 fails with -ENOSYS, we then do a number of readdir()s. Finally readdir returns NULL, we check the errno and its still -ENOSYS. Any ideas Steve? Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Wed Oct 9 21:08:45 2002 From: anton at samba.org (Anton Blanchard) Date: Wed, 9 Oct 2002 21:08:45 +1000 Subject: syscall update In-Reply-To: <20021007142855.GA12424@krispykreme> References: <20021007142855.GA12424@krispykreme> Message-ID: <20021009110845.GA22326@krispykreme> Hi, Ive updated the 2.5 tree with the 64bit changes and glibc 2.3 is working well. Steve here is the thing I was mentioning earlier, a strace of a 64 bit app shows we try fcntl64 before dropping back to fcntl: fcntl64(3, F_GETFD) = -1 ENOSYS (Function not implemented) fcntl(3, F_GETFD) = 0 Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From sjmunroe at us.ibm.com Wed Oct 9 23:07:37 2002 From: sjmunroe at us.ibm.com (Steve Munroe) Date: Wed, 9 Oct 2002 08:07:37 -0500 Subject: 64bit LTP Message-ID: I have not, but Peter may have. If Peter has not addressed this in the SLES 8 work, then I'll add it to the list... Just to verify, this is glibc-2.3 with my patches from ftp://ftp.linuxppc64.org/pub/people/sjmunroe/ and kernel-2.5.+ with Peter's LTP fixes frpm SLES 8? Anton Blanchard To: linuxppc64-dev at lists.linuxppc.org Sent by: cc: owner-linuxppc64-dev at lists.l Subject: 64bit LTP inuxppc.org 10/09/02 04:21 AM Hi, Has anyone investigated the readdir01 LTP failure? It seems like we arent resetting errno. fcntl64 fails with -ENOSYS, we then do a number of readdir()s. Finally readdir returns NULL, we check the errno and its still -ENOSYS. Any ideas Steve? Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Wed Oct 9 23:17:00 2002 From: anton at samba.org (Anton Blanchard) Date: Wed, 9 Oct 2002 23:17:00 +1000 Subject: 64bit LTP In-Reply-To: References: Message-ID: <20021009131700.GC9406@krispykreme> Hi, > I have not, but Peter may have. > > If Peter has not addressed this in the SLES 8 work, then I'll add it to the > list... Thanks. > Just to verify, this is glibc-2.3 with my patches from > ftp://ftp.linuxppc64.org/pub/people/sjmunroe/ and kernel-2.5.+ with Peter's > LTP fixes frpm SLES 8? Yep. I grabbed the glibc 2.3 patch yesterday. 2.5 kernel is from this morning, I merged the SLES 8 LTP fixes into 2.5 yesterday. Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From sjmunroe at us.ibm.com Fri Oct 11 02:19:27 2002 From: sjmunroe at us.ibm.com (Steve Munroe) Date: Thu, 10 Oct 2002 11:19:27 -0500 Subject: syscall update Message-ID: Ok it seems that most platforms, including PowerPC, implement fcntl by judt including the i386 implmentation (,/sysdeps/unix/sysv/linux/i386/fcntl.c). The implementation of fcntl is conditioned on __ASSUME_FCNTL64 (from glibc's kernel_features.h) and __NR_fcntl64 (from the kernel's include/asm/unistd.h). I made sure that __ASSUME_FCNTL64 is not defined for PowerPC64, but the kernel headers still define __NR_fcntl64. In this case fcntl tries fcntl64 just once per 64-bit process. Since the fcntl64 syscall fails with ENOSYS it sets the static variable __have_no_fcntl64 to "true" and only calls fcntl after that. This happens because __NR_fcntl64 is defined. Otherwise it only calls __NR_fcntl. If only the kernel did not define__NR_fcntl64 ... ;) As the there is only one set of /usr/include files for both 32- and 64-bit and the kernels ./asm and ./linux header get copied into /usr/include. The 32- and 64-bit unistd.h should be the same. So use something like: #if !defined __powerpc64__ #define __NR_fcntl64 204 #endif Anton Blanchard To: linuxppc64-dev at lists.linuxppc.org Sent by: cc: owner-linuxppc64-dev at lists.l Subject: Re: syscall update inuxppc.org 10/09/02 06:08 AM Hi, Ive updated the 2.5 tree with the 64bit changes and glibc 2.3 is working well. Steve here is the thing I was mentioning earlier, a strace of a 64 bit app shows we try fcntl64 before dropping back to fcntl: fcntl64(3, F_GETFD) = -1 ENOSYS (Function not implemented) fcntl(3, F_GETFD) = 0 Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From anton at samba.org Sun Oct 13 09:50:16 2002 From: anton at samba.org (Anton Blanchard) Date: Sun, 13 Oct 2002 09:50:16 +1000 Subject: 64bit LTP In-Reply-To: <20021009092128.GU5947@krispykreme> References: <20021009092128.GU5947@krispykreme> Message-ID: <20021012235016.GC17019@krispykreme> > Has anyone investigated the readdir01 LTP failure? It seems like we > arent resetting errno. > > fcntl64 fails with -ENOSYS, we then do a number of readdir()s. Finally > readdir returns NULL, we check the errno and its still -ENOSYS. It looks like a bug in the LTP test, I'll submit a patch to them. Anton ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/ From ganich73 at yahoo.com Thu Oct 17 05:02:23 2002 From: ganich73 at yahoo.com (Viktor Ganich) Date: Wed, 16 Oct 2002 12:02:23 -0700 (PDT) Subject: building 64-bit cross compiler In-Reply-To: <20021008235533.B1153569@brule.borg.umn.edu> Message-ID: <20021016190223.43192.qmail@web21407.mail.yahoo.com> --- Peter Bergner wrote: > Viktor Ganich wrote: > : I am trying to build gcc compiler on 64-bit > PowerPC > : machine with SLES-8 beta 2 version installed. > > If you really need a 64-bit toolchain and you can't > get > one built, there's an rpm on the CD's which gets > installed > in /opt/cross/. > Thank you Peter, I decided to follow this advice about using rpm that comes with SLES. The only thing is that I installed them not in /opt/cross, but in DFS, in order to be used by different users on different machines. cross-ppc64-glibc/binutils/gcc rpms are relocatable, but after installation in non-default location(on DFS) gcc/g++ are looking for libraries (libc.so.6 and libc_nonshared.a) not in DFS, but in /opt/cross, as --prefix option cannot be overwritten. It would be a good idea to put cross-ppc64-...src.rpm on SLES 8.0 CD's to rebuild rpm with the desired prefix, but alas. As a workaround I suggested to create symbolic links in /opt/cross/powerpc64-linux/lib on each user's machine, that will point to libraries in DFS and it seems to work, but I don't think this is the right way to do it. Viktor. ** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/