From drepper@redhat.com Fri Sep 1 00:12:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Fri, 01 Sep 2000 00:12:00 -0000 Subject: O_LARGEFILE missing References: Message-ID: Andreas Jaeger writes: > Here's a patch. Port maintainers of m68k, sh, ia64, arm and s390: > Please provided a bits/fcntl.h for your architecture! Please check it in. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From aj@suse.de Fri Sep 1 00:14:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Fri, 01 Sep 2000 00:14:00 -0000 Subject: O_LARGEFILE missing References: Message-ID: >>>>> Ulrich Drepper writes: > Andreas Jaeger writes: >> Here's a patch. Port maintainers of m68k, sh, ia64, arm and s390: >> Please provided a bits/fcntl.h for your architecture! > Please check it in. Thanks, done. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From drepper@redhat.com Fri Sep 1 01:55:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Fri, 01 Sep 2000 01:55:00 -0000 Subject: more stdio functions Message-ID: You might have seen that I added a bunch of new stdio functions. These come from Solaris where they are provided to avoid the unportable poking in the FILE structure. Some GNU programs already use these functions. One of the functions is doing something which wasn't possible before. The __fsetlocking function allows to set the stream in a mode where the functions are not performing any locking operations. This might be useful for lazy programmers who don't want to use the _unlocked functions but also for the case where no unlocked equivalents are available (e.g., printf). -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From hjl@valinux.com Fri Sep 1 07:54:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Fri, 01 Sep 2000 07:54:00 -0000 Subject: Support for testing static binaries Message-ID: <20000901075421.A21509@valinux.com> This patch adds the support for testing static binaries even when shared library is enabled. It is useful to check static linking. -- H.J. Lu (hjl@gnu.org) --- 2000-09-01 H.J. Lu * Makeconfig (built-program-cmd): Don't use the dynamic linker to run a binary if it is in $(tests-static). * Rules (binaries-static): Add $(tests-static). Index: Makeconfig =================================================================== RCS file: /work/cvs/gnu/glibc/Makeconfig,v retrieving revision 1.1.1.9 diff -u -p -r1.1.1.9 Makeconfig --- Makeconfig 2000/08/26 01:11:19 1.1.1.9 +++ Makeconfig 2000/08/26 01:14:30 @@ -495,8 +495,12 @@ sysdep-library-path = \ $(subst $(empty) ,:,$(strip $(patsubst -Wl$(comma)-rpath-link=%, %,\ $(filter -Wl$(comma)-rpath-link=%,\ $(sysdep-LDFLAGS))))) +ifeq (,$(findstring $(notdir $(built-program-file)), $(tests-static))) run-program-prefix = $(elf-objpfx)$(rtld-installed-name) \ --library-path $(rpath-link)$(patsubst %,:%,$(sysdep-library-path)) +else +run-program-prefix = +endif else run-program-prefix = endif Index: Rules =================================================================== RCS file: /work/cvs/gnu/glibc/Rules,v retrieving revision 1.1.1.4 diff -u -p -r1.1.1.4 Rules --- Rules 2000/07/29 16:19:49 1.1.1.4 +++ Rules 2000/07/29 16:29:31 @@ -96,7 +96,7 @@ endif ifeq ($(build-programs),yes) binaries-all = $(others) $(sysdep-others) $(tests) $(test-srcs) -binaries-static = $(others-static) +binaries-static = $(others-static) $(tests-static) else binaries-all = $(tests) $(test-srcs) binaries-static = From drepper@redhat.com Fri Sep 1 16:11:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Fri, 01 Sep 2000 16:11:00 -0000 Subject: collate changes Message-ID: Bruno's collation changes introduced problems on Arm. This is most probably due to unaligned data since the test suite was working before. I don't know when I'll find the time to look at this. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From aj@suse.de Sat Sep 2 05:56:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Sat, 02 Sep 2000 05:56:00 -0000 Subject: fmemopen test failure Message-ID: Hi Uli, I fear you cleaned up too much. test-fmemopen fails for me, the appended patch fixes this. Andreas 2000-09-02 Andreas Jaeger * libio/fmemopen.c (fmemopen_close): Revert one part of last patch. ============================================================ Index: libio/fmemopen.c --- libio/fmemopen.c 2000/09/01 20:49:16 1.2 +++ libio/fmemopen.c 2000/09/02 10:56:40 @@ -183,7 +183,8 @@ c = (fmemopen_cookie_t *) cookie; - free (c->buffer); + if (c->mybuffer) + free (c->buffer); free (c); return 0; -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From aj@suse.de Sat Sep 2 08:20:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Sat, 02 Sep 2000 08:20:00 -0000 Subject: shlib-versions patch for libBrokenLocale Message-ID: Both libc.map and libBrokenLocale.map export __ctype_get_mb_cur_max: $ grep __ctype_get_mb_cur_max *map libBrokenLocale.map: __ctype_get_mb_cur_max; libc.map: __ctype_get_mb_cur_max; On ia64 and sh, the minimal version used is 2.2. In libc.map the version will therefore be 2.2 - but in libBrokenLocale it's 2.0. What do you think of the appended patch? I also think that libnss_* need special treatment for ia64 and sh. But haven't added it yet. Is this needed? Andreas 2000-09-02 Andreas Jaeger * shlib-versions: libBrokenLocale needs minimal version for ia64 and sh to synch with libc. ============================================================ Index: shlib-versions --- shlib-versions 2000/08/28 11:09:29 1.52 +++ shlib-versions 2000/09/02 15:16:32 @@ -110,6 +110,8 @@ # The gross patch for programs assuming broken locale implementations. alpha.*-.*-linux.* libBrokenLocale=1.1 +ia64-.*-.* libBrokenLocale=1 GLIBC_2.2 +sh.*-.*-.* libBrokenLocale=1 GLIBC_2.2 .*-.*-.* libBrokenLocale=1 # The real-time library from POSIX.1b. -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From aj@suse.de Sat Sep 2 08:57:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Sat, 02 Sep 2000 08:57:00 -0000 Subject: Warnings on sparc build Message-ID: My automatic build of glibc CVS on sparc (see http://www.suse.de/~aj/results/linux/sparc/20000901-3/msg.html ) gives lots of warnings like these: Makefile:184: target `soft-fp/subdir_lib' given more than once in the same rule. Makefile:184: target `soft-fp/objects' given more than once in the same rule. Makefile:184: target `soft-fp/objs' given more than once in the same rule. Makefile:184: target `soft-fp/others' given more than once in the same rule. How should this be fixed? It seems that the soft-fp Makefiles are not really correct. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From hjl@valinux.com Sat Sep 2 10:33:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Sat, 02 Sep 2000 10:33:00 -0000 Subject: Problems with libstdc++ v3 and glibc 2.2 Message-ID: <20000902103312.A22827@valinux.com> libstdc++ v3 wants _IO_file_xsgetn, _IO_wfile_doallocate and _IO_no_init. Also it seems to want __libio_codecvt, but reference it as __c_libio_codecvt. Can we fix them? Thanks. -- H.J. Lu (hjl@gnu.org) From drepper@redhat.com Sat Sep 2 10:37:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Sat, 02 Sep 2000 10:37:00 -0000 Subject: Warnings on sparc build References: Message-ID: Andreas Jaeger writes: > How should this be fixed? It seems that the soft-fp Makefiles are not > really correct. This whole soft-fp situation is not pleasing. Since the code is not an add-on there is no room for this subdir having a sysdeps hierachy. It must be mergerd with the regular one in which case the warnings go away. Any volunteer? -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Sat Sep 2 10:45:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Sat, 02 Sep 2000 10:45:00 -0000 Subject: Problems with libstdc++ v3 and glibc 2.2 References: <20000902103312.A22827@valinux.com> Message-ID: "H . J . Lu" writes: > libstdc++ v3 wants _IO_file_xsgetn, _IO_wfile_doallocate and > _IO_no_init. In which files? > Also it seems to want __libio_codecvt, but reference it as > __c_libio_codecvt. This is not needed. None of this code should be used outside the libc. It's currently there because we are experimenting. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From hjl@lucon.org Sat Sep 2 10:48:00 2000 From: hjl@lucon.org (H . J . Lu) Date: Sat, 02 Sep 2000 10:48:00 -0000 Subject: Problems with libstdc++ v3 and glibc 2.2 References: <20000902103312.A22827@valinux.com> Message-ID: <20000902104844.A961@lucon.org> On Sat, Sep 02, 2000 at 10:45:09AM -0700, Ulrich Drepper wrote: > "H . J . Lu" writes: > > > libstdc++ v3 wants _IO_file_xsgetn, _IO_wfile_doallocate and > > _IO_no_init. > > In which files? ./config/c_io_libio.cc: { return _IO_file_xsgetn(this, __s, __n); } ./config/c_io_libio.cc: { return _IO_wfile_doallocate(this); } ./config/c_io_libio.cc: _IO_no_init(this, 0, 0, &_M_wfile, 0); ./config/c_io_libio.cc: _IO_no_init(this, 0, 0, &_M_wfile, &_IO_wfile_jumps); > > > Also it seems to want __libio_codecvt, but reference it as > > __c_libio_codecvt. > > This is not needed. None of this code should be used outside the > libc. It's currently there because we are experimenting. Well, it looks like they are all related: ./config/c_io_libio.cc: _codecvt = &__c_libio_codecvt; If we remove ./config/c_io_libio.cc, there will be no references to any of those. H.J. From drepper@redhat.com Sat Sep 2 10:59:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Sat, 02 Sep 2000 10:59:00 -0000 Subject: Problems with libstdc++ v3 and glibc 2.2 References: <20000902103312.A22827@valinux.com> <20000902104844.A961@lucon.org> Message-ID: "H . J . Lu" writes: > > In which files? > > ./config/c_io_libio.cc: { return _IO_file_xsgetn(this, __s, __n); } > ./config/c_io_libio.cc: { return _IO_wfile_doallocate(this); } > ./config/c_io_libio.cc: _IO_no_init(this, 0, 0, &_M_wfile, 0); > ./config/c_io_libio.cc: _IO_no_init(this, 0, 0, &_M_wfile, &_IO_wfile_jumps); This file is not going to be used with glibc. It's there for other libc versions and for development. With glibc 2.2 this has to be done differently. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From jakub@redhat.com Sat Sep 2 14:34:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Sat, 02 Sep 2000 14:34:00 -0000 Subject: [PATCH] Fix segv in nss_files Message-ID: <20000902233643.B491@sunsite.ms.mff.cuni.cz> Hi! With multi on in /etc/host.conf and lines like: 1.2.3.4 x 1.2.3.4 x y in /etc/hosts gethostbyname segfaults (a while loop in HOST_DB_LOOKUP loops forever because cnt is never incremented). Fixed by following patch. 2000-09-02 Jakub Jelinek * nss/nss_files/files-hosts.c (HOST_DB_LOOKUP): Increment counter in the loop. --- libc/nss/nss_files/files-hosts.c.jj Thu Jul 27 15:59:38 2000 +++ libc/nss/nss_files/files-hosts.c Sat Sep 2 23:19:11 2000 @@ -200,6 +200,7 @@ _nss_files_get##name##_r (proto, bufferend = (__stpcpy (bufferend, \ tmp_result_buf.h_aliases[cnt]) \ + 1); \ + ++cnt; \ } \ \ if (cnt < newaliases) \ Jakub From jakub@redhat.com Sat Sep 2 14:58:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Sat, 02 Sep 2000 14:58:00 -0000 Subject: [PATCH] Don't try fcntl64 if not needed Message-ID: <20000903000009.C491@sunsite.ms.mff.cuni.cz> Hi! fcntl on i386 and sparc32 currently if not build with --enable-kernel=2.4.1 and above is trying fcntl64 first and falls back to fcntl syscalls for all cmd values, which is IMHO overkill. The following patch makes it to try fcntl64 only if F_GETLK64 and above commands are requested, thus saving one fcntl64 -ENOSYS call on earlier kernels in the common case (non-LFS compiled application). 2000-09-02 Jakub Jelinek * sysdeps/unix/sysv/linux/i386/fcntl.c (__libc_fcntl): Only try fcntl64 for commands F_GETLK64 and above. --- libc/sysdeps/unix/sysv/linux/i386/fcntl.c.jj Sat Aug 12 12:00:35 2000 +++ libc/sysdeps/unix/sysv/linux/i386/fcntl.c Sat Sep 2 22:21:33 2000 @@ -44,7 +44,7 @@ __libc_fcntl (int fd, int cmd, ...) return INLINE_SYSCALL (fcntl64, 3, fd, cmd, arg); #else # ifdef __NR_fcntl64 - if (! __have_no_fcntl64) + if (cmd >= F_GETLK64 && ! __have_no_fcntl64) { int result = INLINE_SYSCALL (fcntl64, 3, fd, cmd, arg); if (result >= 0 || errno != ENOSYS) Jakub From kettenis@wins.uva.nl Sun Sep 3 06:38:00 2000 From: kettenis@wins.uva.nl (Mark Kettenis) Date: Sun, 03 Sep 2000 06:38:00 -0000 Subject: linuxthread/linuxthread_db fix Message-ID: <200009031338.e83DcAT18434@delius.kettenis.local> Looks like TD_REAP and TD_DEATH are a bit mixed up (probably due to copy & paste). Mark 2000-09-03 Mark Kettenis * manager.c (pthread_exited): Correctly report event as TD_REAP instead of TD_DEATH. Fix comments. Index: linuxthreads/manager.c =================================================================== RCS file: /cvs/glibc/libc/linuxthreads/manager.c,v retrieving revision 1.57 diff -u -p -r1.57 manager.c --- linuxthreads/manager.c 2000/08/30 07:37:18 1.57 +++ linuxthreads/manager.c 2000/09/03 13:31:51 @@ -745,7 +745,7 @@ static void pthread_exited(pid_t pid) | th->p_eventbuf.eventmask.event_bits[idx])) != 0) { /* Yep, we have to signal the death. */ - th->p_eventbuf.eventnum = TD_DEATH; + th->p_eventbuf.eventnum = TD_REAP; th->p_eventbuf.eventdata = th; __pthread_last_event = th; From kettenis@wins.uva.nl Sun Sep 3 06:47:00 2000 From: kettenis@wins.uva.nl (Mark Kettenis) Date: Sun, 03 Sep 2000 06:47:00 -0000 Subject: lunixthreads/linuxthreads_db fix Message-ID: <200009031347.e83Dlk318537@delius.kettenis.local> Please ignore my previous patch. It didn't include the doc fixes. Here is the correct one. Mark 2000-09-03 Mark Kettenis * manager.c (pthread_exited): Correctly report event as TD_REAP instead of TD_DEATH. Fix comments. Index: linuxthreads/manager.c =================================================================== RCS file: /cvs/glibc/libc/linuxthreads/manager.c,v retrieving revision 1.57 diff -u -p -r1.57 manager.c --- linuxthreads/manager.c 2000/08/30 07:37:18 1.57 +++ linuxthreads/manager.c 2000/09/03 13:39:38 @@ -737,15 +737,15 @@ static void pthread_exited(pid_t pid) /* If we have to signal this event do it now. */ if (th->p_report_events) { - /* See whether TD_DEATH is in any of the mask. */ + /* See whether TD_REAP is in any of the mask. */ int idx = __td_eventword (TD_REAP); uint32_t mask = __td_eventmask (TD_REAP); if ((mask & (__pthread_threads_events.event_bits[idx] | th->p_eventbuf.eventmask.event_bits[idx])) != 0) { - /* Yep, we have to signal the death. */ - th->p_eventbuf.eventnum = TD_DEATH; + /* Yep, we have to signal the reapage. */ + th->p_eventbuf.eventnum = TD_REAP; th->p_eventbuf.eventdata = th; __pthread_last_event = th; From drepper@redhat.com Sun Sep 3 09:50:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Sun, 03 Sep 2000 09:50:00 -0000 Subject: Support for testing static binaries References: <20000901075421.A21509@valinux.com> Message-ID: "H . J . Lu" writes: > This patch adds the support for testing static binaries even when > shared library is enabled. It is useful to check static linking. Seems to not break anything. I've added it. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Sun Sep 3 09:58:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Sun, 03 Sep 2000 09:58:00 -0000 Subject: [PATCH] Fix segv in nss_files References: <20000902233643.B491@sunsite.ms.mff.cuni.cz> Message-ID: Jakub Jelinek writes: > 2000-09-02 Jakub Jelinek > > * nss/nss_files/files-hosts.c (HOST_DB_LOOKUP): Increment counter in > the loop. Applied. Thanks, -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Sun Sep 3 10:03:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Sun, 03 Sep 2000 10:03:00 -0000 Subject: [PATCH] Don't try fcntl64 if not needed References: <20000903000009.C491@sunsite.ms.mff.cuni.cz> Message-ID: Jakub Jelinek writes: > 2000-09-02 Jakub Jelinek > > * sysdeps/unix/sysv/linux/i386/fcntl.c (__libc_fcntl): Only try > fcntl64 for commands F_GETLK64 and above. I don't think this is necessary. This version is mainly used with 2.4 kernel even though they are not available widely now. But the lifetime of glibc 2.2 overlaps certainly more with the 2.4 kernels than with 2.2. But then we just have one more if (more code) and two used entry points in the kernel. Mind you that I don't --enable-kernel be used very much in general. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Sun Sep 3 10:11:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Sun, 03 Sep 2000 10:11:00 -0000 Subject: lunixthreads/linuxthreads_db fix References: <200009031347.e83Dlk318537@delius.kettenis.local> Message-ID: Mark Kettenis writes: > 2000-09-03 Mark Kettenis > > * manager.c (pthread_exited): Correctly report event as TD_REAP > instead of TD_DEATH. Fix comments. Thanks, I've applied this patch now. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From hjl@lucon.org Sun Sep 3 11:19:00 2000 From: hjl@lucon.org (H . J . Lu) Date: Sun, 03 Sep 2000 11:19:00 -0000 Subject: Support for testing static binaries References: <20000901075421.A21509@valinux.com> Message-ID: <20000903111902.B8315@lucon.org> On Sun, Sep 03, 2000 at 09:50:00AM -0700, Ulrich Drepper wrote: > "H . J . Lu" writes: > > > This patch adds the support for testing static binaries even when > > shared library is enabled. It is useful to check static linking. > > Seems to not break anything. I've added it. > Thanks. I will add some tests if the static linking fails again :-). H.J. From aj@suse.de Mon Sep 4 01:36:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Mon, 04 Sep 2000 01:36:00 -0000 Subject: Fixed sysdeps/generic/fegetenv.c Message-ID: FYI: I've committed the appended patch, Andreas 2000-09-04 Andreas Jaeger * sysdeps/generic/fegetenv.c: It's __fegetenv. Reported by Rob Levin . ============================================================ Index: sysdeps/generic/fegetenv.c --- sysdeps/generic/fegetenv.c 2000/07/12 17:39:23 1.5 +++ sysdeps/generic/fegetenv.c 2000/09/04 08:15:38 @@ -23,7 +23,7 @@ #include int -fegetenv (fenv_t *envp) +__fegetenv (fenv_t *envp) { /* This always fails. */ return 1; -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From aj@suse.de Mon Sep 4 02:06:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Mon, 04 Sep 2000 02:06:00 -0000 Subject: New strtod test cases Message-ID: Uli, what do you think of the appended test cases? make check passes on i686. Andreas 2000-09-04 Andreas Jaeger * stdlib/tst-strtod.c: Add testcases for denormal numbers from PR libc/1880. ============================================================ Index: stdlib/tst-strtod.c --- stdlib/tst-strtod.c 1999/10/30 04:31:06 1.14 +++ stdlib/tst-strtod.c 2000/09/04 08:52:59 @@ -1,4 +1,4 @@ -/* Copyright (C) 1991, 1996, 1997, 1998, 1999 Free Software Foundation, Inc. +/* Copyright (C) 1991,96,97,98,99,2000 Free Software Foundation, Inc. This file is part of the GNU C Library. The GNU C Library is free software; you can redistribute it and/or @@ -56,6 +56,8 @@ { "0x00.0050p17", 160.0, '\0', 0 }, { "0x00.0028p18", 160.0, '\0', 0 }, { "0x00.0014p19", 160.0, '\0', 0 }, + { "0x1p-1023", 1.11253692925360069154511635866620203210960799023116591527666e-308, '\0', 0 }, + { "0x0.8p-1022", 1.11253692925360069154511635866620203210960799023116591527666e-308, '\0', 0 }, { NULL, 0, '\0', 0 } }; -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From aj@suse.de Mon Sep 4 04:52:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Mon, 04 Sep 2000 04:52:00 -0000 Subject: Warnings on sparc build References: Message-ID: >>>>> Ulrich Drepper writes: Uli> Andreas Jaeger writes: >> How should this be fixed? It seems that the soft-fp Makefiles are not >> really correct. Uli> This whole soft-fp situation is not pleasing. Since the code is not Uli> an add-on there is no room for this subdir having a sysdeps hierachy. Uli> It must be mergerd with the regular one in which case the warnings go Uli> away. Do you mean that the contents of soft-fp/sysdeps/* has to be put in the normal sysdeps files? For example: mv soft-fp/sysdeps/i386/sfp-machine.h sysdeps/i386 ... Uli> Any volunteer? I can do that - but I can't really test it really since I don't have normally an easy access to a Sparc machine. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From jakub@redhat.com Mon Sep 4 04:54:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Mon, 04 Sep 2000 04:54:00 -0000 Subject: Warnings on sparc build References: Message-ID: <20000904135639.D491@sunsite.ms.mff.cuni.cz> On Mon, Sep 04, 2000 at 01:51:34PM +0200, Andreas Jaeger wrote: > >>>>> Ulrich Drepper writes: > > Uli> Andreas Jaeger writes: > >> How should this be fixed? It seems that the soft-fp Makefiles are not > >> really correct. > > Uli> This whole soft-fp situation is not pleasing. Since the code is not > Uli> an add-on there is no room for this subdir having a sysdeps hierachy. > Uli> It must be mergerd with the regular one in which case the warnings go > Uli> away. > > Do you mean that the contents of soft-fp/sysdeps/* has to be put in > the normal sysdeps files? For example: > mv soft-fp/sysdeps/i386/sfp-machine.h sysdeps/i386 > ... > > Uli> Any volunteer? > > I can do that - but I can't really test it really since I don't have > normally an easy access to a Sparc machine. I'll do it soonish. Jakub From aj@suse.de Mon Sep 4 05:11:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Mon, 04 Sep 2000 05:11:00 -0000 Subject: Warnings on sparc build References: <20000904135639.D491@sunsite.ms.mff.cuni.cz> Message-ID: >>>>> Jakub Jelinek writes: Jakub> On Mon, Sep 04, 2000 at 01:51:34PM +0200, Andreas Jaeger wrote: >> >>>>> Ulrich Drepper writes: >> Uli> Andreas Jaeger writes: >> >> How should this be fixed? It seems that the soft-fp Makefiles are not >> >> really correct. >> Uli> This whole soft-fp situation is not pleasing. Since the code is not Uli> an add-on there is no room for this subdir having a sysdeps hierachy. Uli> It must be mergerd with the regular one in which case the warnings go Uli> away. >> >> Do you mean that the contents of soft-fp/sysdeps/* has to be put in >> the normal sysdeps files? For example: >> mv soft-fp/sysdeps/i386/sfp-machine.h sysdeps/i386 >> ... >> Uli> Any volunteer? >> >> I can do that - but I can't really test it really since I don't have >> normally an easy access to a Sparc machine. Jakub> I'll do it soonish. I've just started and have a script for it already, I'm just waiting for Uli's "Go ahead". I guess the best solution would be if I move the files around (including removal of soft-fp/configure) - and let you do the rest (including changes to Makefiles[1]). What do you think, Jakub? Otherwise I can send you my script. Andreas Footnotes: [1] I can't just move soft-fp/sysdeps/sparc/sparc64/Makefile to sysdeps/sparc/sparc64/Makefile, those have to be merged and this has to be done manually. -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From schwab@suse.de Mon Sep 4 09:52:00 2000 From: schwab@suse.de (Andreas Schwab) Date: Mon, 04 Sep 2000 09:52:00 -0000 Subject: Problem with make dist Message-ID: <200009041652.e84Gq5o07115@hawking.suse.de> The makefile in sysdeps/ia64 modifies dl-routines and rtld-routines to get dl-symaddr and dl-fptr into the dynamic linker objects. This is wrong, a sysdep makefile should never modify generic object lists, only sysdep lists. It breaks `make dist' when running on ia64. This patch adds the necessary hooks to elf/Makefile that the sysdep makefile can use. Andreas. 2000-09-04 Andreas Schwab * elf/Makefile (all-dl-routines): New variable. (elide-routines.os): Use it instead of $(dl-routines). (all-rtld-routines): New variable. (extra-objs): Use it instead of $(rtld-routines). ($(objpfx)dl-allobjs.os): Likewise. * sysdeps/ia64/Makefile [$(subdir) = elf]: Modify sysdep-dl-routines and sysdep_routines instead of rtld-routines and dl-routines. Index: libc/elf/Makefile =================================================================== RCS file: /cvs/glibc/libc/elf/Makefile,v retrieving revision 1.172 diff -u -a -u -r1.172 libc/elf/Makefile --- libc/elf/Makefile 2000/08/26 23:23:41 1.172 +++ libc/elf/Makefile 2000/09/04 16:47:34 @@ -29,12 +29,15 @@ dl-routines = $(addprefix dl-,load cache lookup object reloc deps \ runtime error init fini debug misc \ version profile) +all-dl-routines = $(dl-routines) $(sysdep-dl-routines) # But they are absent from the shared libc, because that code is in ld.so. -elide-routines.os = $(dl-routines) dl-support enbl-secure +elide-routines.os = $(all-dl-routines) dl-support enbl-secure # ld.so uses those routines, plus some special stuff for being the program # interpreter and operating independent of libc. rtld-routines := rtld $(dl-routines) dl-sysdep dl-environ dl-minimal +all-rtld-routines = $(rtld-routines) $(sysdep-dl-routines) + distribute := $(rtld-routines:=.c) dynamic-link.h do-rel.h dl-machine.h \ dl-cache.h dl-hash.h soinit.c sofini.c ldd.bash.in \ genrtldtbl.awk atomicity.h dl-procinfo.h ldsodefs.h \ @@ -60,7 +63,7 @@ endif ifeq (yes,$(build-shared)) -extra-objs = $(rtld-routines:=.os) soinit.os sofini.os interp.os +extra-objs = $(all-rtld-routines:%=%.os) soinit.os sofini.os interp.os generated += librtld.os dl-allobjs.os ld.so ldd install-others = $(inst_slibdir)/$(rtld-installed-name) install-bin = ldd @@ -118,7 +121,7 @@ # Command to link into a larger single relocatable object. reloc-link = $(LINK.o) -nostdlib -nostartfiles -r -o $@ -$(objpfx)dl-allobjs.os: $(rtld-routines:%=$(objpfx)%.os) +$(objpfx)dl-allobjs.os: $(all-rtld-routines:%=$(objpfx)%.os) $(reloc-link) $^ # Link together the dynamic linker into a single relocatable object. Index: sysdeps/ia64/Makefile =================================================================== RCS file: /cvs/glibc/libc/sysdeps/ia64/Makefile,v retrieving revision 1.1 diff -u -a -u -r1.1 sysdeps/ia64/Makefile --- sysdeps/ia64/Makefile 2000/05/05 16:41:36 1.1 +++ sysdeps/ia64/Makefile 2000/09/04 16:45:02 @@ -3,6 +3,6 @@ endif ifeq ($(subdir),elf) -dl-routines += dl-symaddr dl-fptr -rtld-routines += dl-symaddr dl-fptr +sysdep-dl-routines += dl-symaddr dl-fptr +sysdep_routines += $(sysdep-dl-routines) endif -- Andreas Schwab "And now for something SuSE Labs completely different." Andreas.Schwab@suse.de SuSE GmbH, Schanz????ckerstr. 10, D-90443 N????rnberg From drepper@redhat.com Mon Sep 4 10:41:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Mon, 04 Sep 2000 10:41:00 -0000 Subject: New strtod test cases References: Message-ID: Andreas Jaeger writes: > Uli, what do you think of the appended test cases? make check passes > on i686. Sure, looks OK. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From hjl@valinux.com Mon Sep 4 10:48:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Mon, 04 Sep 2000 10:48:00 -0000 Subject: A patch for linuxthreads Message-ID: <20000904104812.A12853@valinux.com> page_roundup is faster than roundup. Since `ps' is returned from __getpagesize (), it should be ok. -- H.J. Lu (hjl@gnu.org) --- 2000-09-04 H.J. Lu * attr.c (__pthread_attr_setguardsize): Use page_roundup instead of roundup to round up to the page size. Index: attr.c =================================================================== RCS file: /work/cvs/gnu/glibc/linuxthreads/attr.c,v retrieving revision 1.1.1.2 diff -u -p -r1.1.1.2 attr.c --- attr.c 2000/08/16 00:55:46 1.1.1.2 +++ attr.c 2000/08/17 16:18:05 @@ -147,7 +147,7 @@ int __pthread_attr_setguardsize(pthread_ size_t ps = __getpagesize (); /* First round up the guard size. */ - guardsize = roundup (guardsize, ps); + guardsize = page_roundup (guardsize, ps); /* The guard size must not be larger than the stack itself */ if (guardsize >= attr->__stacksize) return EINVAL; From drepper@redhat.com Mon Sep 4 10:54:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Mon, 04 Sep 2000 10:54:00 -0000 Subject: Warnings on sparc build References: <20000904135639.D491@sunsite.ms.mff.cuni.cz> Message-ID: Andreas Jaeger writes: > I've just started and have a script for it already, I'm just waiting > for Uli's "Go ahead". We probably should move soft-fp/sysdeps/space in sysdeps/sparc/soft-fp etc and adjust add appropriate Implies files. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Mon Sep 4 19:54:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Mon, 04 Sep 2000 19:54:00 -0000 Subject: A patch for linuxthreads References: <20000904104812.A12853@valinux.com> Message-ID: "H . J . Lu" writes: > page_roundup is faster than roundup. Since `ps' is returned from > __getpagesize (), it should be ok. I've applied the patch. Thanks, -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Mon Sep 4 19:54:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Mon, 04 Sep 2000 19:54:00 -0000 Subject: Problem with make dist References: <200009041652.e84Gq5o07115@hawking.suse.de> Message-ID: Thanks, I've applied the patch. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From aj@suse.de Mon Sep 4 22:11:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Mon, 04 Sep 2000 22:11:00 -0000 Subject: config.guess,config.sub and texinfo.tex updated Message-ID: FYI, I've updated these versions from the official version. config.* now supports AMD's x86_64 as x86_64. Andreas 2000-09-05 Andreas Jaeger * scripts/config.guess: New upstream version. * scripts/config.sub: Likewise. * manual/texinfo.tex: Likewise. -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From aj@suse.de Mon Sep 4 23:34:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Mon, 04 Sep 2000 23:34:00 -0000 Subject: Warnings on sparc build References: <20000904135639.D491@sunsite.ms.mff.cuni.cz> Message-ID: >>>>> Ulrich Drepper writes: Uli> Andreas Jaeger writes: >> I've just started and have a script for it already, I'm just waiting >> for Uli's "Go ahead". Uli> We probably should move Uli> soft-fp/sysdeps/space Uli> in Uli> sysdeps/sparc/soft-fp This would lead to the following changes: * soft-fp/sysdeps/powerpc/q_add.c: Move from here... * sysdeps/powerpc/soft-fp/q_add.c: ... to here. * soft-fp/sysdeps/powerpc/q_cmp.c: Move from here... * sysdeps/powerpc/soft-fp/q_cmp.c: ... to here. * soft-fp/sysdeps/powerpc/q_cmpe.c: Move from here... * sysdeps/powerpc/soft-fp/q_cmpe.c: ... to here. * soft-fp/sysdeps/powerpc/q_div.c: Move from here... * sysdeps/powerpc/soft-fp/q_div.c: ... to here. * soft-fp/sysdeps/powerpc/q_dtoq.c: Move from here... * sysdeps/powerpc/soft-fp/q_dtoq.c: ... to here. * soft-fp/sysdeps/powerpc/q_feq.c: Move from here... * sysdeps/powerpc/soft-fp/q_feq.c: ... to here. * soft-fp/sysdeps/powerpc/q_fge.c: Move from here... * sysdeps/powerpc/soft-fp/q_fge.c: ... to here. * soft-fp/sysdeps/powerpc/q_fgt.c: Move from here... * sysdeps/powerpc/soft-fp/q_fgt.c: ... to here. * soft-fp/sysdeps/powerpc/q_fle.c: Move from here... * sysdeps/powerpc/soft-fp/q_fle.c: ... to here. * soft-fp/sysdeps/powerpc/q_flt.c: Move from here... * sysdeps/powerpc/soft-fp/q_flt.c: ... to here. * soft-fp/sysdeps/powerpc/q_fne.c: Move from here... * sysdeps/powerpc/soft-fp/q_fne.c: ... to here. * soft-fp/sysdeps/powerpc/q_itoq.c: Move from here... * sysdeps/powerpc/soft-fp/q_itoq.c: ... to here. * soft-fp/sysdeps/powerpc/q_lltoq.c: Move from here... * sysdeps/powerpc/soft-fp/q_lltoq.c: ... to here. * soft-fp/sysdeps/powerpc/q_mul.c: Move from here... * sysdeps/powerpc/soft-fp/q_mul.c: ... to here. * soft-fp/sysdeps/powerpc/q_neg.c: Move from here... * sysdeps/powerpc/soft-fp/q_neg.c: ... to here. * soft-fp/sysdeps/powerpc/q_qtod.c: Move from here... * sysdeps/powerpc/soft-fp/q_qtod.c: ... to here. * soft-fp/sysdeps/powerpc/q_qtoi.c: Move from here... * sysdeps/powerpc/soft-fp/q_qtoi.c: ... to here. * soft-fp/sysdeps/powerpc/q_qtoll.c: Move from here... * sysdeps/powerpc/soft-fp/q_qtoll.c: ... to here. * soft-fp/sysdeps/powerpc/q_qtos.c: Move from here... * sysdeps/powerpc/soft-fp/q_qtos.c: ... to here. * soft-fp/sysdeps/powerpc/q_qtou.c: Move from here... * sysdeps/powerpc/soft-fp/q_qtou.c: ... to here. * soft-fp/sysdeps/powerpc/q_qtoull.c: Move from here... * sysdeps/powerpc/soft-fp/q_qtoull.c: ... to here. * soft-fp/sysdeps/powerpc/q_sqrt.c: Move from here... * sysdeps/powerpc/soft-fp/q_sqrt.c: ... to here. * soft-fp/sysdeps/powerpc/q_stoq.c: Move from here... * sysdeps/powerpc/soft-fp/q_stoq.c: ... to here. * soft-fp/sysdeps/powerpc/q_sub.c: Move from here... * sysdeps/powerpc/soft-fp/q_sub.c: ... to here. * soft-fp/sysdeps/powerpc/q_ulltoq.c: Move from here... * sysdeps/powerpc/soft-fp/q_ulltoq.c: ... to here. * soft-fp/sysdeps/powerpc/q_util.c: Move from here... * sysdeps/powerpc/soft-fp/q_util.c: ... to here. * soft-fp/sysdeps/powerpc/q_utoq.c: Move from here... * sysdeps/powerpc/soft-fp/q_utoq.c: ... to here. * soft-fp/sysdeps/sparc/sparc32/q_add.c: Move from here... * sysdeps/sparc/sparc32/soft-fp/q_add.c: ... to here. * soft-fp/sysdeps/sparc/sparc32/q_cmp.c: Move from here... * sysdeps/sparc/sparc32/soft-fp/q_cmp.c: ... to here. * soft-fp/sysdeps/sparc/sparc32/q_cmpe.c: Move from here... * sysdeps/sparc/sparc32/soft-fp/q_cmpe.c: ... to here. * soft-fp/sysdeps/sparc/sparc32/q_div.c: Move from here... * sysdeps/sparc/sparc32/soft-fp/q_div.c: ... to here. * soft-fp/sysdeps/sparc/sparc32/q_dtoq.c: Move from here... * sysdeps/sparc/sparc32/soft-fp/q_dtoq.c: ... to here. * soft-fp/sysdeps/sparc/sparc32/q_feq.c: Move from here... * sysdeps/sparc/sparc32/soft-fp/q_feq.c: ... to here. * soft-fp/sysdeps/sparc/sparc32/q_fge.c: Move from here... * sysdeps/sparc/sparc32/soft-fp/q_fge.c: ... to here. * soft-fp/sysdeps/sparc/sparc32/q_fgt.c: Move from here... * sysdeps/sparc/sparc32/soft-fp/q_fgt.c: ... to here. * soft-fp/sysdeps/sparc/sparc32/q_fle.c: Move from here... * sysdeps/sparc/sparc32/soft-fp/q_fle.c: ... to here. * soft-fp/sysdeps/sparc/sparc32/q_flt.c: Move from here... * sysdeps/sparc/sparc32/soft-fp/q_flt.c: ... to here. * soft-fp/sysdeps/sparc/sparc32/q_fne.c: Move from here... * sysdeps/sparc/sparc32/soft-fp/q_fne.c: ... to here. * soft-fp/sysdeps/sparc/sparc32/q_itoq.c: Move from here... * sysdeps/sparc/sparc32/soft-fp/q_itoq.c: ... to here. * soft-fp/sysdeps/sparc/sparc32/q_mul.c: Move from here... * sysdeps/sparc/sparc32/soft-fp/q_mul.c: ... to here. * soft-fp/sysdeps/sparc/sparc32/q_neg.c: Move from here... * sysdeps/sparc/sparc32/soft-fp/q_neg.c: ... to here. * soft-fp/sysdeps/sparc/sparc32/q_qtod.c: Move from here... * sysdeps/sparc/sparc32/soft-fp/q_qtod.c: ... to here. * soft-fp/sysdeps/sparc/sparc32/q_qtoi.c: Move from here... * sysdeps/sparc/sparc32/soft-fp/q_qtoi.c: ... to here. * soft-fp/sysdeps/sparc/sparc32/q_qtos.c: Move from here... * sysdeps/sparc/sparc32/soft-fp/q_qtos.c: ... to here. * soft-fp/sysdeps/sparc/sparc32/q_qtoui.c: Move from here... * sysdeps/sparc/sparc32/soft-fp/q_qtoui.c: ... to here. * soft-fp/sysdeps/sparc/sparc32/q_qtoux.c: Move from here... * sysdeps/sparc/sparc32/soft-fp/q_qtoux.c: ... to here. * soft-fp/sysdeps/sparc/sparc32/q_qtox.c: Move from here... * sysdeps/sparc/sparc32/soft-fp/q_qtox.c: ... to here. * soft-fp/sysdeps/sparc/sparc32/q_sqrt.c: Move from here... * sysdeps/sparc/sparc32/soft-fp/q_sqrt.c: ... to here. * soft-fp/sysdeps/sparc/sparc32/q_stoq.c: Move from here... * sysdeps/sparc/sparc32/soft-fp/q_stoq.c: ... to here. * soft-fp/sysdeps/sparc/sparc32/q_sub.c: Move from here... * sysdeps/sparc/sparc32/soft-fp/q_sub.c: ... to here. * soft-fp/sysdeps/sparc/sparc32/q_uitoq.c: Move from here... * sysdeps/sparc/sparc32/soft-fp/q_uitoq.c: ... to here. * soft-fp/sysdeps/sparc/sparc32/q_util.c: Move from here... * sysdeps/sparc/sparc32/soft-fp/q_util.c: ... to here. * soft-fp/sysdeps/sparc/sparc32/q_uxtoq.c: Move from here... * sysdeps/sparc/sparc32/soft-fp/q_uxtoq.c: ... to here. * soft-fp/sysdeps/sparc/sparc32/q_xtoq.c: Move from here... * sysdeps/sparc/sparc32/soft-fp/q_xtoq.c: ... to here. * soft-fp/sysdeps/sparc/sparc64/qp_add.c: Move from here... * sysdeps/sparc/sparc64/soft-fp/qp_add.c: ... to here. * soft-fp/sysdeps/sparc/sparc64/qp_cmp.c: Move from here... * sysdeps/sparc/sparc64/soft-fp/qp_cmp.c: ... to here. * soft-fp/sysdeps/sparc/sparc64/qp_cmpe.c: Move from here... * sysdeps/sparc/sparc64/soft-fp/qp_cmpe.c: ... to here. * soft-fp/sysdeps/sparc/sparc64/qp_div.c: Move from here... * sysdeps/sparc/sparc64/soft-fp/qp_div.c: ... to here. * soft-fp/sysdeps/sparc/sparc64/qp_dtoq.c: Move from here... * sysdeps/sparc/sparc64/soft-fp/qp_dtoq.c: ... to here. * soft-fp/sysdeps/sparc/sparc64/qp_feq.c: Move from here... * sysdeps/sparc/sparc64/soft-fp/qp_feq.c: ... to here. * soft-fp/sysdeps/sparc/sparc64/qp_fge.c: Move from here... * sysdeps/sparc/sparc64/soft-fp/qp_fge.c: ... to here. * soft-fp/sysdeps/sparc/sparc64/qp_fgt.c: Move from here... * sysdeps/sparc/sparc64/soft-fp/qp_fgt.c: ... to here. * soft-fp/sysdeps/sparc/sparc64/qp_fle.c: Move from here... * sysdeps/sparc/sparc64/soft-fp/qp_fle.c: ... to here. * soft-fp/sysdeps/sparc/sparc64/qp_flt.c: Move from here... * sysdeps/sparc/sparc64/soft-fp/qp_flt.c: ... to here. * soft-fp/sysdeps/sparc/sparc64/qp_fne.c: Move from here... * sysdeps/sparc/sparc64/soft-fp/qp_fne.c: ... to here. * soft-fp/sysdeps/sparc/sparc64/qp_itoq.c: Move from here... * sysdeps/sparc/sparc64/soft-fp/qp_itoq.c: ... to here. * soft-fp/sysdeps/sparc/sparc64/qp_mul.c: Move from here... * sysdeps/sparc/sparc64/soft-fp/qp_mul.c: ... to here. * soft-fp/sysdeps/sparc/sparc64/qp_qtod.c: Move from here... * sysdeps/sparc/sparc64/soft-fp/qp_qtod.c: ... to here. * soft-fp/sysdeps/sparc/sparc64/qp_qtoi.c: Move from here... * sysdeps/sparc/sparc64/soft-fp/qp_qtoi.c: ... to here. * soft-fp/sysdeps/sparc/sparc64/qp_qtos.c: Move from here... * sysdeps/sparc/sparc64/soft-fp/qp_qtos.c: ... to here. * soft-fp/sysdeps/sparc/sparc64/qp_qtoui.c: Move from here... * sysdeps/sparc/sparc64/soft-fp/qp_qtoui.c: ... to here. * soft-fp/sysdeps/sparc/sparc64/qp_qtoux.c: Move from here... * sysdeps/sparc/sparc64/soft-fp/qp_qtoux.c: ... to here. * soft-fp/sysdeps/sparc/sparc64/qp_qtox.c: Move from here... * sysdeps/sparc/sparc64/soft-fp/qp_qtox.c: ... to here. * soft-fp/sysdeps/sparc/sparc64/qp_sqrt.c: Move from here... * sysdeps/sparc/sparc64/soft-fp/qp_sqrt.c: ... to here. * soft-fp/sysdeps/sparc/sparc64/qp_stoq.c: Move from here... * sysdeps/sparc/sparc64/soft-fp/qp_stoq.c: ... to here. * soft-fp/sysdeps/sparc/sparc64/qp_sub.c: Move from here... * sysdeps/sparc/sparc64/soft-fp/qp_sub.c: ... to here. * soft-fp/sysdeps/sparc/sparc64/qp_uitoq.c: Move from here... * sysdeps/sparc/sparc64/soft-fp/qp_uitoq.c: ... to here. * soft-fp/sysdeps/sparc/sparc64/qp_util.c: Move from here... * sysdeps/sparc/sparc64/soft-fp/qp_util.c: ... to here. * soft-fp/sysdeps/sparc/sparc64/qp_uxtoq.c: Move from here... * sysdeps/sparc/sparc64/soft-fp/qp_uxtoq.c: ... to here. * soft-fp/sysdeps/sparc/sparc64/qp_xtoq.c: Move from here... * sysdeps/sparc/sparc64/soft-fp/qp_xtoq.c: ... to here. * soft-fp/sysdeps/sparc/sparc64/s_frexpl.c: Move from here... * sysdeps/sparc/sparc64/soft-fp/s_frexpl.c: ... to here. * soft-fp/sysdeps/sparc/sparc64/s_ilogbl.c: Move from here... * sysdeps/sparc/sparc64/soft-fp/s_ilogbl.c: ... to here. * soft-fp/sysdeps/sparc/sparc64/s_scalblnl.c: Move from here... * sysdeps/sparc/sparc64/soft-fp/s_scalblnl.c: ... to here. * soft-fp/sysdeps/sparc/sparc64/s_scalbnl.c: Move from here... * sysdeps/sparc/sparc64/soft-fp/s_scalbnl.c: ... to here. * soft-fp/sysdeps/alpha/sfp-machine.h: Move from here... * sysdeps/alpha/soft-fp/sfp-machine.h: ... to here. * soft-fp/sysdeps/i386/sfp-machine.h: Move from here... * sysdeps/i386/soft-fp/sfp-machine.h: ... to here. * soft-fp/sysdeps/mips/mips64/sfp-machine.h: Move from here... * sysdeps/mips/mips64/soft-fp/sfp-machine.h: ... to here. * soft-fp/sysdeps/mips/sfp-machine.h: Move from here... * sysdeps/mips/soft-fp/sfp-machine.h: ... to here. * soft-fp/sysdeps/powerpc/sfp-machine.h: Move from here... * sysdeps/powerpc/soft-fp/sfp-machine.h: ... to here. * soft-fp/sysdeps/sparc/sparc32/sfp-machine.h: Move from here... * sysdeps/sparc/sparc32/soft-fp/sfp-machine.h: ... to here. * soft-fp/sysdeps/sparc/sparc64/sfp-machine.h: Move from here... * sysdeps/sparc/sparc64/soft-fp/sfp-machine.h: ... to here. * soft-fp/sysdeps/powerpc/Versions: Move from here... * sysdeps/powerpc/soft-fp/Versions: ... to here. * soft-fp/sysdeps/sparc/sparc64/Versions: Move from here... * sysdeps/sparc/sparc64/soft-fp/Versions: ... to here. Are these ok? In that case I'll checkin the changes and handle the rest later today. Uli> etc and adjust add appropriate Implies files. Implies and/or Makefiles need separate changes which will come separatly Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From drepper@redhat.com Mon Sep 4 23:40:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Mon, 04 Sep 2000 23:40:00 -0000 Subject: Warnings on sparc build References: <20000904135639.D491@sunsite.ms.mff.cuni.cz> Message-ID: Andreas Jaeger writes: > Are these ok? In that case I'll checkin the changes and handle the > rest later today. It's OK with me. I see no reason why Geoff, rth, Jakub, or anyone should have a problem. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From aj@suse.de Mon Sep 4 23:49:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Mon, 04 Sep 2000 23:49:00 -0000 Subject: Warnings on sparc build References: <20000904135639.D491@sunsite.ms.mff.cuni.cz> Message-ID: >>>>> Ulrich Drepper writes: Uli> Andreas Jaeger writes: >> Are these ok? In that case I'll checkin the changes and handle the >> rest later today. Uli> It's OK with me. I see no reason why Geoff, rth, Jakub, or anyone Uli> should have a problem. Ok, I'll start later today - this might cause for a few hours problems on some (perhaps only sparc) platforms but I'll try to fix them (just building a sparc cross-compiler to test everything) asap. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From aj@suse.de Tue Sep 5 02:05:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Tue, 05 Sep 2000 02:05:00 -0000 Subject: Warnings on sparc build References: <20000904135639.D491@sunsite.ms.mff.cuni.cz> <200009050855.BAA20009@localhost.cygnus.com> Message-ID: >>>>> Geoff Keating writes: >> From: Andreas Jaeger >> Date: 05 Sep 2000 08:33:43 +0200 >> * soft-fp/sysdeps/powerpc/Versions: Move from here... >> * sysdeps/powerpc/soft-fp/Versions: ... to here. >> >> * soft-fp/sysdeps/sparc/sparc64/Versions: Move from here... >> * sysdeps/sparc/sparc64/soft-fp/Versions: ... to here. >> >> Are these ok? In that case I'll checkin the changes and handle the >> rest later today. Geoff> Please don't name the sysdeps subdirectory for powerpc Geoff> 'soft-fp'. Those files are used for powerpc targets both with and Geoff> without an FPU; 'soft-fp' will be confused with the GCC -msoft-float Geoff> option which means "compile for a CPU with no FPU". This leads to even greater confusion - we have already a soft-fp subdirectory - we shouldn't name this soft-fp for some platforms and use another name for powerpc. Geoff> Otherwise the changes are OK. I've checked in the changes already - but I can move them around another time if it's really needed (but not today anymore, let's discuss this first). Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From drepper@redhat.com Tue Sep 5 02:13:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Tue, 05 Sep 2000 02:13:00 -0000 Subject: Warnings on sparc build References: <20000904135639.D491@sunsite.ms.mff.cuni.cz> <200009050855.BAA20009@localhost.cygnus.com> Message-ID: Geoff Keating writes: > Please don't name the sysdeps subdirectory for powerpc > 'soft-fp'. Those files are used for powerpc targets both with and > without an FPU; 'soft-fp' will be confused with the GCC -msoft-float > option which means "compile for a CPU with no FPU". You named the whole package soft-fp. I don't see a problem with this name. soft-float reads very different from soft-fp and people who have to care have to know enough about the architecture to know that even with hardware FP support you need soft-fp. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From aj@suse.de Tue Sep 5 03:35:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Tue, 05 Sep 2000 03:35:00 -0000 Subject: Warnings on sparc build References: <20000904135639.D491@sunsite.ms.mff.cuni.cz> Message-ID: >>>>> Ulrich Drepper writes: Uli> Andreas Jaeger writes: >> I've just started and have a script for it already, I'm just waiting >> for Uli's "Go ahead". Uli> We probably should move Uli> soft-fp/sysdeps/space Uli> in Uli> sysdeps/sparc/soft-fp Uli> etc and adjust add appropriate Implies files. sysdeps/sparc/Subdirs has already "soft-fp" in it, should we add a Subdirs file for powerpc? Something I don't understand: Why are the files in the soft-fp directory not build at all? soft-fp/Makefile has list like gcc-single-routines but those are nowhere used in glibc. Is it correct that those routines are *not* build on any platform? My patches are in now. sparc32 seems to build without problems, I'll try sparc64 now. If anybody encounters problems, please tell me, Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From aj@suse.de Tue Sep 5 04:02:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Tue, 05 Sep 2000 04:02:00 -0000 Subject: Warnings on sparc build References: <20000904135639.D491@sunsite.ms.mff.cuni.cz> <20000905064321.G784@devserv.devel.redhat.com> Message-ID: >>>>> Jakub Jelinek writes: Jakub> On Tue, Sep 05, 2000 at 12:34:29PM +0200, Andreas Jaeger wrote: [...] >> Something I don't understand: Why are the files in the soft-fp >> directory not build at all? soft-fp/Makefile has list like >> gcc-single-routines but those are nowhere used in glibc. Is it >> correct that those routines are *not* build on any platform? Jakub> They are used on sparc64, they are not used on sparc32 (yet). The issue is Jakub> that sparc32 gcc has used 64bit long double and only recently changed into Jakub> supporting both (with -m options), but it still defaults to 64bit long Jakub> double. And those _Q_ functions are only of interest if it has 128bit long Jakub> double. I'm just not yet sure how to do the transition: probably all libm Jakub> long double symbols will have to be versioned then, with the @2.0 symbols Jakub> pointing to double implementation and @2.2.1 or whatever pointing to new Jakub> IEEE quad long double implementations. If you do this change, please consider it for 2.2 - or for 2.3. I prefer not to make such changes in a minor release. As this change seems to require gcc 2.96, how will you handle long double support in sparc32 with older compilers? Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From aj@suse.de Tue Sep 5 08:10:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Tue, 05 Sep 2000 08:10:00 -0000 Subject: soft-fp move finished Message-ID: I've finished the soft-fp move. During the process I made a few clean-ups and enabled soft-fp for powerpc, sparc - both don't use it actually yet - and sparc64. I've build the current glibc natively on i686, MIPS and with cross-compilers on sparc32, sparc64 and powerpc successfully. If anybody notices problems with the soft-fp move, please tell me. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From drepper@redhat.com Tue Sep 5 10:11:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Tue, 05 Sep 2000 10:11:00 -0000 Subject: soft-fp move finished References: Message-ID: Andreas Jaeger writes: > I've finished the soft-fp move. During the process I made a few > clean-ups and enabled soft-fp for powerpc, sparc - both don't use it > actually yet - and sparc64. Thanks. Did you try `make dist' as well? -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From aj@suse.de Tue Sep 5 12:15:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Tue, 05 Sep 2000 12:15:00 -0000 Subject: soft-fp move finished References: Message-ID: >>>>> Ulrich Drepper writes: > Andreas Jaeger writes: >> I've finished the soft-fp move. During the process I made a few >> clean-ups and enabled soft-fp for powerpc, sparc - both don't use it >> actually yet - and sparc64. > Thanks. Did you try `make dist' as well? No - but I'll do that tomorrow. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From aj@suse.de Tue Sep 5 12:24:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Tue, 05 Sep 2000 12:24:00 -0000 Subject: soft-fp/ChangeLog Message-ID: Why has soft-fp a separate ChangeLog? I used the top-level ChangeLog file instead :-(. Should I move my changes to the soft-fp? Or shall we remove that ChangeLog file? Where shall I add new change log entries? Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From aj@suse.de Tue Sep 5 12:24:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Tue, 05 Sep 2000 12:24:00 -0000 Subject: Problem with make dist Message-ID: In my cross powerpc build directory, I tried running make dist and got: make[4]: Entering directory `/usr/src/cvs/libc/elf' make[4]: *** No rule to make target `dl-machine.c', needed by `dist'. Stop. make[4]: Leaving directory `/usr/src/cvs/libc/elf' We have: gromit:/usr/src/cvs/libc:[1]$ find . -name "dl-machine.c" ./sysdeps/mach/hurd/mips/dl-machine.c ./sysdeps/powerpc/dl-machine.c and sysdeps/powerpc/Makefile contains: ifeq ($(subdir),elf) dl-routines += dl-machine rtld-routines += dl-machine dl-start endif Any ideas how to fix this? Thanks, Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From drepper@redhat.com Tue Sep 5 12:45:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Tue, 05 Sep 2000 12:45:00 -0000 Subject: Problem with make dist References: Message-ID: Andreas Jaeger writes: > and sysdeps/powerpc/Makefile contains: > ifeq ($(subdir),elf) > dl-routines += dl-machine > rtld-routines += dl-machine dl-start > endif We have to introduce sysdep-dl-routines and add it the elf/Makefile. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Tue Sep 5 12:47:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Tue, 05 Sep 2000 12:47:00 -0000 Subject: soft-fp/ChangeLog References: Message-ID: Andreas Jaeger writes: > Why has soft-fp a separate ChangeLog? I used the top-level ChangeLog > file instead :-(. Should I move my changes to the soft-fp? Or shall > we remove that ChangeLog file? Where shall I add new change log > entries? I think it's not necessary to keep have a separate ChangeLog but it's also not necessary to move the old content. Except for one entry by Geoff all it says: here are new files. Maybe add an entry saying soft-fp subdir merged but this should be all. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From aj@suse.de Tue Sep 5 17:10:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Tue, 05 Sep 2000 17:10:00 -0000 Subject: soft-fp/ChangeLog References: Message-ID: >>>>> Ulrich Drepper writes: > Andreas Jaeger writes: >> Why has soft-fp a separate ChangeLog? I used the top-level ChangeLog >> file instead :-(. Should I move my changes to the soft-fp? Or shall >> we remove that ChangeLog file? Where shall I add new change log >> entries? > I think it's not necessary to keep have a separate ChangeLog but it's > also not necessary to move the old content. Except for one entry by > Geoff all it says: here are new files. Maybe add an entry saying > soft-fp subdir merged but this should be all. I found in ChangeLog.10: 1999-12-29 Ulrich Drepper * soft-fp/*: Tons of new files to implement floating-point arithmetic in software. Contributed by Richard Henderson, Jakub Jelinek and others. I've removed soft-fp/ChangeLog now and added in the top-level ChangeLog file: 2000-09-06 Andreas Jaeger * soft-fp/ChangeLog: Merged with this file. 2000-06-13 Ulrich Drepper * soft-fp/Makefile (distribute): Add op-8.h and testit.c. * soft-fp/Makefile (distribute): Add the math functions, too. * soft-fp/Makefile (distribute): Add ChangeLog, Banner, and configure. 2000-03-03 Geoff Keating * soft-fp/soft-fp.h (_FP_ROUND_ZERO): Cast 0 to void before using it as a statement. * soft-fp/sysdeps/powerpc/Makefile (routines): New file. * soft-fp/sysdeps/powerpc/q_*: New files. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From aj@suse.de Wed Sep 6 03:54:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Wed, 06 Sep 2000 03:54:00 -0000 Subject: soft-fp move finished References: Message-ID: >>>>> Ulrich Drepper writes: > Andreas Jaeger writes: >> I've finished the soft-fp move. During the process I made a few >> clean-ups and enabled soft-fp for powerpc, sparc - both don't use it >> actually yet - and sparc64. > Thanks. Did you try `make dist' as well? make dist now works for me on i386, sparc32, sparc64 and MIPS. I had to add a number of smaller patches to get make dist working on the now working platforms. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From schwab@suse.de Wed Sep 6 07:37:00 2000 From: schwab@suse.de (Andreas Schwab) Date: Wed, 06 Sep 2000 07:37:00 -0000 Subject: CLK_TCK on IA64 Message-ID: <200009061436.e86EaqX20216@hawking.suse.de> Recently the kernel has changed HZ to 1024 on IA64. has to be updated. Andreas. 2000-09-06 Andreas Schwab * sysdeps/unix/sysv/linux/ia64/bits/time.h: New file. --- /dev/null Sun Aug 6 01:23:03 2000 +++ sysdeps/unix/sysv/linux/ia64/bits/time.h Wed Sep 6 16:33:22 2000 @@ -0,0 +1,67 @@ +/* System-dependent timing definitions. Linux/IA64 version. + Copyright (C) 2000 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Library General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Library General Public License for more details. + + You should have received a copy of the GNU Library General Public + License along with the GNU C Library; see the file COPYING.LIB. If not, + write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, + Boston, MA 02111-1307, USA. */ + +/* + * Never include this file directly; use instead. + */ + +#ifndef __need_timeval +# ifndef _BITS_TIME_H +# define _BITS_TIME_H 1 + +/* ISO/IEC 9899:1990 7.12.1: + The macro `CLOCKS_PER_SEC' is the number per second of the value + returned by the `clock' function. */ +/* CAE XSH, Issue 4, Version 2: + The value of CLOCKS_PER_SEC is required to be 1 million on all + XSI-conformant systems. */ +# define CLOCKS_PER_SEC 1000000 + +# ifndef __STRICT_ANSI__ +/* Even though CLOCKS_PER_SEC has such a strange value CLK_TCK + presents the real value for clock ticks per second for the system. */ +# define CLK_TCK 1024 +# endif + +# ifdef __USE_POSIX199309 +/* Identifier for system-wide realtime clock. */ +# define CLOCK_REALTIME 0 + +/* Flag to indicate time is absolute. */ +# define TIMER_ABSTIME 1 +# endif + +# endif /* bits/time.h */ +#endif + +#ifdef __need_timeval +# undef __need_timeval +# ifndef _STRUCT_TIMEVAL +# define _STRUCT_TIMEVAL 1 +# include + +/* A time value that is accurate to the nearest + microsecond but also has a range of years. */ +struct timeval + { + __time_t tv_sec; /* Seconds. */ + __suseconds_t tv_usec; /* Microseconds. */ + }; +# endif /* struct timeval */ +#endif /* need timeval */ -- Andreas Schwab "And now for something SuSE Labs completely different." Andreas.Schwab@suse.de SuSE GmbH, Schanz????ckerstr. 10, D-90443 N????rnberg From drepper@redhat.com Wed Sep 6 09:36:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Wed, 06 Sep 2000 09:36:00 -0000 Subject: soft-fp move finished References: Message-ID: Andreas Jaeger writes: > make dist now works for me on i386, sparc32, sparc64 and MIPS. Thanks a lot. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Wed Sep 6 10:30:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Wed, 06 Sep 2000 10:30:00 -0000 Subject: Problems with libstdc++ v3 and glibc 2.2 References: Message-ID: Benjamin Kosnik writes: > Ulrich, this list of used/exported functions was presented to you a month or > two back, minus _IO_wfile_doallocate: This is too much detain. I never meant this to be the real implementation to be used with glibc 2.2. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Wed Sep 6 13:39:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Wed, 06 Sep 2000 13:39:00 -0000 Subject: signal/bsd_signal Message-ID: What's the correct BSD behavior of signal? The current standard draft says that bsd_signal (what we also call signal) can be implemented with: void (*bsd_signal(int sig, void (*funct)(int)))(int) { struct sigaction act, oact; act.sa_handler = func; act.sa_flags = SA_RESTART; sigemptyset(&act.sa_mask); sigaddset(&act.sa_mask, sig); if (sigaction(sig, &act, &oact) == -1) return(SIG_ERR); return(oact.sa_handler); } This is basically what we habe except that we don't habe the sigaddset() call. Do we have to add it or not? Define signal and bsd_signal separately? -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From roland@frob.com Wed Sep 6 14:02:00 2000 From: roland@frob.com (Roland McGrath) Date: Wed, 06 Sep 2000 14:02:00 -0000 Subject: signal/bsd_signal References: Message-ID: <200009062102.e86L2KJ27593@neuralgia.linnaean.org> > What's the correct BSD behavior of signal? The current standard draft > says that bsd_signal (what we also call signal) can be implemented > with: > > void (*bsd_signal(int sig, void (*funct)(int)))(int) > { > struct sigaction act, oact; > act.sa_handler = func; > act.sa_flags = SA_RESTART; > sigemptyset(&act.sa_mask); > sigaddset(&act.sa_mask, sig); > if (sigaction(sig, &act, &oact) == -1) > return(SIG_ERR); > return(oact.sa_handler); > } > > This is basically what we habe except that we don't habe the > sigaddset() call. Do we have to add it or not? Define signal and > bsd_signal separately? The 1003.l-1996 specification of sigaction makes that sigaddset call redundant. The delivery of the signal uses a blocked signal set formed by adding the signal (i.e. SIG) to the sa_mask set. The only observable difference between having it or not is in what value (sigaction(sig, 0, &oact), oact.sa_mask) has. From drepper@redhat.com Wed Sep 6 14:07:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Wed, 06 Sep 2000 14:07:00 -0000 Subject: signal/bsd_signal References: <200009062102.e86L2KJ27593@neuralgia.linnaean.org> Message-ID: Roland McGrath writes: > The only observable difference between having it or not is in what > value (sigaction(sig, 0, &oact), oact.sa_mask) has. Right. So adding the sigaddset() seems correct. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From roland@frob.com Wed Sep 6 14:12:00 2000 From: roland@frob.com (Roland McGrath) Date: Wed, 06 Sep 2000 14:12:00 -0000 Subject: signal/bsd_signal References: Message-ID: <200009062112.e86LCYB27609@neuralgia.linnaean.org> > Roland McGrath writes: > > > The only observable difference between having it or not is in what > > value (sigaction(sig, 0, &oact), oact.sa_mask) has. > > Right. So adding the sigaddset() seems correct. Eh? Well, it is superfluous and so I don't see why you say it "seems correct" (as opposed to its lack). If you want signal to be anally compatible with BSD, then one will have to check whether the sa_mask value reported by sigaction after a signal call contains the signal in question or not. I have to stretch to contemplate ways a program could manage to care one way or the other. From drepper@redhat.com Wed Sep 6 14:24:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Wed, 06 Sep 2000 14:24:00 -0000 Subject: signal/bsd_signal References: <200009062112.e86LCYB27609@neuralgia.linnaean.org> Message-ID: Roland McGrath writes: > I have to stretch to contemplate ways a program could manage to care > one way or the other. If the mask is returned and the bit is not set something might be handled differently than expected. I don't know of a case, I'm just looking throught the specs. If some piece in the test suite is testing this it will complain. Now it won't anymore. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From roland@frob.com Wed Sep 6 14:41:00 2000 From: roland@frob.com (Roland McGrath) Date: Wed, 06 Sep 2000 14:41:00 -0000 Subject: signal/bsd_signal References: Message-ID: <200009062141.e86LfCG27671@neuralgia.linnaean.org> > If the mask is returned and the bit is not set something might be > handled differently than expected. I don't know of a case, I'm just > looking throught the specs. If some piece in the test suite is > testing this it will complain. Now it won't anymore. What I have been saying is that I have no reason to think that seeing that bit set is the "expected behavior". I haven't checked BSD, but my offhand guess would be that the bit would not be set in sa_mask as reported by sigaction after a signal call. From drepper@redhat.com Wed Sep 6 15:04:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Wed, 06 Sep 2000 15:04:00 -0000 Subject: signal/bsd_signal References: <200009062141.e86LfCG27671@neuralgia.linnaean.org> Message-ID: Roland McGrath writes: > I haven't checked BSD, but my offhand guess would be that the bit > would not be set in sa_mask as reported by sigaction after a signal > call. I have no possibility to check it and have to believe what I see. Currently it's in favor of of adding the bit. Also, I think to remember that the signal wasn't automatically masked in early Unix versions. I.e., it would have been necessary to set the bit. I might be wrong but somebody will have to proof it. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From jakub@redhat.com Thu Sep 7 01:35:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Thu, 07 Sep 2000 01:35:00 -0000 Subject: [sg]ethostid(3) and FHS Message-ID: <20000907103807.K491@sunsite.ms.mff.cuni.cz> Hi! /var/adm does not exist in FHS for quite some time, yet sysdeps/unix/sysv/linux/gethostid.c still references (/var/adm/hostid), which means gethostid and sethostid don't work for quite some time. Any ideas on what's the best path to replace it with? >From quick skimming of FHS 2.1 it looks like /var/lib/hostid or /var/lib/misc/hostid could be ok... Jakub From kettenis@wins.uva.nl Thu Sep 7 01:39:00 2000 From: kettenis@wins.uva.nl (Mark Kettenis) Date: Thu, 07 Sep 2000 01:39:00 -0000 Subject: [sg]ethostid(3) and FHS References: <20000907103807.K491@sunsite.ms.mff.cuni.cz> Message-ID: <200009070839.e878djk14280@debye.wins.uva.nl> Date: Thu, 7 Sep 2000 10:38:08 +0200 From: Jakub Jelinek Hi! /var/adm does not exist in FHS for quite some time, yet sysdeps/unix/sysv/linux/gethostid.c still references (/var/adm/hostid), which means gethostid and sethostid don't work for quite some time. Any ideas on what's the best path to replace it with? >From quick skimming of FHS 2.1 it looks like /var/lib/hostid or /var/lib/misc/hostid could be ok... We use /etc/hostid on the Hurd, which makes sense to me since in the absence of a *real* hardware serial number (which we probably don't really want) it basically becomes a system configuration thingy. Mark From aj@suse.de Thu Sep 7 03:20:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Thu, 07 Sep 2000 03:20:00 -0000 Subject: More bsearch test cases Message-ID: FYI: I've added a number of tests to tst-bsearch that should fail. The patch has been committed already. Andreas 2000-09-07 Andreas Jaeger * stdlib/tst-bsearch.c (main): Add more test cases. ============================================================ Index: stdlib/tst-bsearch.c --- stdlib/tst-bsearch.c 2000/09/06 21:02:33 1.1 +++ stdlib/tst-bsearch.c 2000/09/07 09:56:33 @@ -56,11 +56,11 @@ { int cnt; int result = 0; + struct entry key; + struct entry *res; for (cnt = 0; cnt < narr; ++cnt) { - struct entry key; - struct entry *res; key.val = arr[cnt].val; @@ -73,6 +73,57 @@ else if (res != &arr[cnt]) { puts ("wrong entry returned"); + result = 1; + } + } + + /* And some special tests that shouldn't find any entry. */ + key.val = -1; + res = (struct entry *) bsearch (&key, arr, narr, sizeof (arr[0]), comp); + if (res != NULL) + { + puts ("found an entry that's not there"); + result = 1; + } + + key.val = 11; + res = (struct entry *) bsearch (&key, arr, narr, sizeof (arr[0]), comp); + if (res != NULL) + { + puts ("found an entry that's not there"); + result = 1; + } + + key.val = 11; + res = (struct entry *) bsearch (&key, arr, 0, sizeof (arr[0]), comp); + if (res != NULL) + { + puts ("found an entry that's not there"); + result = 1; + } + + /* Now the array contains only one element - no entry should be found. */ + for (cnt = 0; cnt < narr; ++cnt) + { + key.val = arr[cnt].val; + + res = (struct entry *) bsearch (&key, &arr[5], 1, sizeof (arr[0]), comp); + if (cnt == 5) + { + if (res == NULL) + { + printf ("entry %d not found\n", cnt); + result = 1; + } + else if (res != &arr[cnt]) + { + puts ("wrong entry returned"); + result = 1; + } + } + else if (res != NULL) + { + puts ("found an entry that's not there"); result = 1; } } -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From drepper@redhat.com Thu Sep 7 11:13:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Thu, 07 Sep 2000 11:13:00 -0000 Subject: [sg]ethostid(3) and FHS References: <20000907103807.K491@sunsite.ms.mff.cuni.cz> <200009070839.e878djk14280@debye.wins.uva.nl> Message-ID: Mark Kettenis writes: > We use /etc/hostid on the Hurd, which makes sense to me since in the > absence of a *real* hardware serial number (which we probably don't > really want) it basically becomes a system configuration thingy. I think it's the correct place. I"ve made this change now. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Thu Sep 7 11:15:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Thu, 07 Sep 2000 11:15:00 -0000 Subject: CLK_TCK on IA64 References: <200009061436.e86EaqX20216@hawking.suse.de> Message-ID: Andreas Schwab writes: > Recently the kernel has changed HZ to 1024 on IA64. has to > be updated. I've applied the patch now. Thanks, -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From hjl@valinux.com Thu Sep 7 17:47:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Thu, 07 Sep 2000 17:47:00 -0000 Subject: Recent glibc locale changes on ia64. Message-ID: <20000907173541.A586@valinux.com> My last successful "make check" in glibc 2.2 on ia64 was made on Sep. 1. Since then, I got, # cd /work/gnu/src/glibc/iconvdata # GCONV_PATH=/home/work/build/glibc/iconvdata LC_ALL=C MALLOC_TRACE=/home/work/build/glibc/iconvdata/tst-loading.mtrace /home/work/build/glibc/elf/ld-linux-ia64.so.2 --library-path /home/work/build/glibc:/home/work/build/glibc/math:/home/work/build/glibc/elf:/home/work/build/glibc/dlfcn:/home/work/build/glibc/nss:/home/work/build/glibc/nis:/home/work/build/glibc/rt:/home/work/build/glibc/resolv:/home/work/build/glibc/crypt:/home/work/build/glibc/linuxthreads /home/work/build/glibc/iconvdata/tst-loading zsh: 24325 segmentation fault GCONV_PATH=/home/work/build/glibc/iconvdata LC_ALL=C MALLOC_TRACE= I don't know if it is a hardware bug or a glibc bug. Does anyone else see it? H.J. From drepper@redhat.com Thu Sep 7 18:09:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Thu, 07 Sep 2000 18:09:00 -0000 Subject: Recent glibc locale changes on ia64. References: <20000907173541.A586@valinux.com> Message-ID: "H . J . Lu" writes: > My last successful "make check" in glibc 2.2 on ia64 was made on Sep. 1. > Since then, I got, It fails on PPC as well for whatever reason. It doesn't on x86 and this is my measuring point. Somebody will have to fix it and it's defeinitely not me since I still have no working IA-64 system with glibc 2.2. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From davem@redhat.com Thu Sep 7 21:14:00 2000 From: davem@redhat.com (David S. Miller) Date: Thu, 07 Sep 2000 21:14:00 -0000 Subject: Recent glibc locale changes on ia64. References: <20000907173541.A586@valinux.com> Message-ID: <200009080402.VAA06947@pizda.ninka.net> From: Ulrich Drepper Date: 07 Sep 2000 17:59:20 -0700 "H . J . Lu" writes: > My last successful "make check" in glibc 2.2 on ia64 was made on Sep. 1. > Since then, I got, It fails on PPC as well for whatever reason. It doesn't on x86 and this is my measuring point. Somebody will have to fix it and it's defeinitely not me since I still have no working IA-64 system with glibc 2.2. >From the descriptions I've seen of this problem, it sounds a lot like yet another unaligned memory access problem in the locale code. Isn't there a way to make the x86 signal an cpu exception when data is accessed in an unaligned fashion? Ulrich, you could make use of that if it were true. (I am rather positive that 486 and later provide such a switch, perhaps in the eflags register) This is important beyond correctness for risc-list cpus, it can turn into a quiet performance problem even on x86 which doesn't trap but executes those memory accesses much more slowly. Later, David S. Miller davem@redhat.com From drepper@redhat.com Thu Sep 7 21:40:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Thu, 07 Sep 2000 21:40:00 -0000 Subject: Recent glibc locale changes on ia64. References: <20000907173541.A586@valinux.com> <200009080402.VAA06947@pizda.ninka.net> Message-ID: "David S. Miller" writes: > >From the descriptions I've seen of this problem, it sounds a lot like > yet another unaligned memory access problem in the locale code. No. You should not jump to such a conclusion without looking at the code. Every place where locale data is accessed word-wise is protected with asserts to ensure alignment. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From aj@suse.de Fri Sep 8 00:54:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Fri, 08 Sep 2000 00:54:00 -0000 Subject: ARM patch for fcntl64 Message-ID: Here's a patch for fcntl64 for ARM. Is it ok to install? Andreas 2000-09-08 Andreas Jaeger * sysdeps/unix/sysv/linux/arm/lockf64.c: New file. * sysdeps/unix/sysv/linux/arm/fcntl.c: New file. * sysdeps/unix/sysv/linux/arm/bits/fcntl.h (F_GETLK64,F_SETLK64,F_SETLKW64): Use values from 2.4.0-test8. (F_GETLK,F_SETLK,F_SETLKW): Handle __USE_FILE_OFFSET64 correctly. ============================================================ Index: sysdeps/unix/sysv/linux/arm/bits/fcntl.h --- sysdeps/unix/sysv/linux/arm/bits/fcntl.h 2000/07/30 16:07:40 1.1 +++ sysdeps/unix/sysv/linux/arm/bits/fcntl.h 2000/09/08 07:50:44 @@ -65,14 +65,19 @@ #define F_SETFD 2 /* Set file descriptor flags. */ #define F_GETFL 3 /* Get file status flags. */ #define F_SETFL 4 /* Set file status flags. */ -#define F_GETLK 5 /* Get record locking info. */ -#define F_SETLK 6 /* Set record locking info (non-blocking). */ -#define F_SETLKW 7 /* Set record locking info (blocking). */ -/* XXX missing */ -#define F_GETLK64 5 /* Get record locking info. */ -#define F_SETLK64 6 /* Set record locking info (non-blocking). */ -#define F_SETLKW64 7 /* Set record locking info (blocking). */ +#ifndef __USE_FILE_OFFSET64 +# define F_GETLK 5 /* Get record locking info. */ +# define F_SETLK 6 /* Set record locking info (non-blocking). */ +# define F_SETLKW 7 /* Set record locking info (blocking). */ +#else +# define F_GETLK F_GETLK64 /* Get record locking info. */ +# define F_SETLK F_SETLK64 /* Set record locking info (non-blocking).*/ +# define F_SETLKW F_SETLKW64 /* Set record locking info (blocking). */ +#endif +#define F_GETLK64 12 /* Get record locking info. */ +#define F_SETLK64 13 /* Set record locking info (non-blocking). */ +#define F_SETLKW64 14 /* Set record locking info (blocking). */ #if defined __USE_BSD || defined __USE_XOPEN2K # define F_SETOWN 8 /* Get owner of socket (receiver of SIGIO). */ ============================================================ Index: sysdeps/unix/sysv/linux/arm/lockf64.c --- sysdeps/unix/sysv/linux/arm/lockf64.c created +++ sysdeps/unix/sysv/linux/arm/lockf64.c Fri Sep 8 09:49:49 2000 1.1 @@ -0,0 +1 @@ +#include ============================================================ Index: sysdeps/unix/sysv/linux/arm/fcntl.c --- sysdeps/unix/sysv/linux/arm/fcntl.c created +++ sysdeps/unix/sysv/linux/arm/fcntl.c Fri Sep 8 09:49:49 2000 1.1 @@ -0,0 +1 @@ +#include -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From aj@suse.de Fri Sep 8 00:55:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Fri, 08 Sep 2000 00:55:00 -0000 Subject: mincore patch Message-ID: Greg, you've send me the appended patch while playing around with bounded pointers. Shouldn't this be committed to CVS? Andreas ============================================================ Index: sysdeps/unix/sysv/linux/syscalls.list --- sysdeps/unix/sysv/linux/syscalls.list 2000/07/17 22:28:59 1.80 +++ sysdeps/unix/sysv/linux/syscalls.list 2000/09/08 07:54:38 @@ -22,7 +22,7 @@ klogctl EXTRA syslog i:isi klogctl lchown - lchown i:sii __lchown lchown madvise - madvise i:pii posix_madvise madvise -mincore - mincore i:iip mincore +mincore - mincore i:aip mincore mlock EXTRA mlock i:bn __mlock mlock mlockall EXTRA mlockall i:i __mlockall mlockall mmap - mmap b:aniiii __mmap mmap -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From drepper@redhat.com Fri Sep 8 01:00:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Fri, 08 Sep 2000 01:00:00 -0000 Subject: ARM patch for fcntl64 References: Message-ID: Andreas Jaeger writes: > Here's a patch for fcntl64 for ARM. > > Is it ok to install? Looks OK. Check it in, I'll test ti tomorrow. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From greg@mcgary.org Fri Sep 8 01:15:00 2000 From: greg@mcgary.org (Greg McGary) Date: Fri, 08 Sep 2000 01:15:00 -0000 Subject: mincore patch References: Message-ID: Andreas Jaeger writes: > you've send me the appended patch while playing around with bounded > pointers. Shouldn't this be committed to CVS? Thanks for reminding me. (I've moved on to fighting to get BPs into gcc in recent weeks.) That patch shouldn't go in--it was just an interim hack. Here's one that solves the complete problem: OK, Uli? 2000-09-08 Greg McGary * sysdeps/unix/sysv/linux/syscalls.list (mincore): Fix arg signature. * sysdeps/unix/make-syscalls.sh: New signature keyletter `V'. * sysdeps/generic/bp-checks.h (CHECK_N_PAGES): New macro. Index: sysdeps/unix/sysv/linux/syscalls.list =================================================================== RCS file: /cvs/glibc/libc/sysdeps/unix/sysv/linux/syscalls.list,v retrieving revision 1.80 diff -u -p -r1.80 syscalls.list --- syscalls.list 2000/07/17 22:28:59 1.80 +++ syscalls.list 2000/09/01 01:52:03 @@ -22,7 +22,7 @@ iopl - iopl i:i iopl klogctl EXTRA syslog i:isi klogctl lchown - lchown i:sii __lchown lchown madvise - madvise i:pii posix_madvise madvise -mincore - mincore i:iip mincore +mincore - mincore i:anV mincore mlock EXTRA mlock i:bn __mlock mlock mlockall EXTRA mlockall i:i __mlockall mlockall mmap - mmap b:aniiii __mmap mmap Index: sysdeps/unix/make-syscalls.sh =================================================================== RCS file: /cvs/glibc/libc/sysdeps/unix/make-syscalls.sh,v retrieving revision 1.21 diff -u -p -r1.21 make-syscalls.sh --- make-syscalls.sh 2000/08/17 07:37:00 1.21 +++ make-syscalls.sh 2000/09/01 01:52:03 @@ -21,6 +21,7 @@ # s: non-NULL string (e.g., 1st arg to open) # S: optionally-NULL string (e.g., 1st arg to acct) # v: vararg scalar (e.g., optional 3rd arg to open) +# V: byte-per-page vector (3rd arg to mincore) # W: wait status, optionally-NULL pointer to int (e.g., 2nd arg of wait4) ptr='[abBfFINpPsSW]' # all pointer keyletters @@ -232,7 +233,7 @@ shared-only-routines += $file # generate extern decls of dummy variables for each arg echo " echo '`echo $args | \ sed -e 's/<\('$typ'[1-9]\)>/extern \1, \1v;/g' \ - -e 's/<\([abBFIsS][1-9]\)>/extern char \1v;/g' \ + -e 's/<\([abBFIsSV][1-9]\)>/extern char \1v;/g' \ -e 's/<\([Wv][1-9]\)>/extern int \1v;/g'` \\'; \\" # generate bounded-pointer thunk declarator @@ -255,6 +256,7 @@ shared-only-routines += $file sed -e 's//BOUNDED_N (/' \ -e 's/<.0>//'`($callname) (`echo $arglist | \ sed -e 's/<\(a[1-9]\)>/__ptrvalue (\1a)/g' \ + -e 's/<\(n[1-9]\)>, <\(V[1-9]\)>/\1a, CHECK_N_PAGES (\2a, \1a)/g' \ -e 's/<\(b[1-9]\)>, <\(n[1-9]\)>/CHECK_N (\1a, \2a), \2a/g' \ -e 's/<\(b[1-9]\)>, <\(N[1-9]\)>/CHECK_N (\1a, *CHECK_1 (\2a)), __ptrvalue (\2a)/g' \ -e 's/<\(B[1-9]\)>, <\(n[1-9]\)>/CHECK_N_NULL_OK (\1a, \2a), \2a/g' \ Index: sysdeps/generic/bp-checks.h =================================================================== RCS file: /cvs/glibc/libc/sysdeps/generic/bp-checks.h,v retrieving revision 1.6 diff -u -p -r1.6 bp-checks.h --- bp-checks.h 2000/08/17 07:37:00 1.6 +++ bp-checks.h 2000/09/08 08:14:44 @@ -90,6 +90,13 @@ extern void *__unbounded __ubp_memchr (c (((CMD) == F_GETLK || (CMD) == F_SETLK || (CMD) == F_SETLKW) \ ? CHECK_1 ((struct flock *) ARG) : (unsigned long) (ARG)) +/* Check bounds of an array of mincore residency-status flags that + cover a region of NBYTES. Such a vector occupies one byte per page + of memory. */ +# define CHECK_N_PAGES(ARG, NBYTES) \ + ({ int _page_size_ = sysconf (_SC_PAGE_SIZE); \ + CHECK_N ((ARG), ((NBYTES) + _page_size_ - 1) / _page_size_); }) + /* Return a bounded pointer with value PTR that satisfies CHECK_N (PTR, N). */ # define BOUNDED_N(PTR, N) \ ({ __typeof (PTR) __bounded _p_; \ @@ -113,6 +120,7 @@ extern void *__unbounded __ubp_memchr (c # define CHECK_SIGSET_NULL_OK(SET) (SET) # define CHECK_IOCTL(ARG, CMD) (ARG) # define CHECK_FCNTL(ARG, CMD) (ARG) +# define CHECK_N_PAGES(ARG, NBYTES) (ARG) # define BOUNDED_N(PTR, N) (PTR) #endif /* !__BOUNDED_POINTERS__ */ From drepper@redhat.com Fri Sep 8 01:22:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Fri, 08 Sep 2000 01:22:00 -0000 Subject: mincore patch References: Message-ID: Greg McGary writes: > OK, Uli? Yes. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From bmark@us.ibm.com Fri Sep 8 07:03:00 2000 From: bmark@us.ibm.com (Mark Brown) Date: Fri, 08 Sep 2000 07:03:00 -0000 Subject: signal/bsd_signal References: Message-ID: <39B8F1D7.D50C3783@us.ibm.com> Ulrich Drepper wrote: > > What's the correct BSD behavior of signal? The current standard draft > says that bsd_signal (what we also call signal) can be implemented > with: For what it's worth, this is exactly how AIX defines it, I think should add sigaddset(). Mark -- Mark S. Brown bmark@us.ibm.com Senior Technical Staff Member 512.838.3926 T/L678.3926 IBM RS/6000 AIX System Architecture Mark Brown/Austin/IBM IBM Corporation, Austin, Texas From hjl@valinux.com Fri Sep 8 11:47:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Fri, 08 Sep 2000 11:47:00 -0000 Subject: Recent glibc locale changes on ia64. References: <20000907173541.A586@valinux.com> <200009080402.VAA06947@pizda.ninka.net> Message-ID: <20000908114624.A8755@valinux.com> On Thu, Sep 07, 2000 at 09:30:29PM -0700, Ulrich Drepper wrote: > "David S. Miller" writes: > > > >From the descriptions I've seen of this problem, it sounds a lot like > > yet another unaligned memory access problem in the locale code. > > No. You should not jump to such a conclusion without looking at the > code. Every place where locale data is accessed word-wise is > protected with asserts to ensure alignment. This is my currect patch to get "make check" to pass iconvdata under ia64. I have no idea what this patch 2000-09-03 Bruno Haible * iconv/gconv_dl.c (do_release_shlib): Don't decrement the counter below -TRIES_BEFORE_UNLOAD-1, to avoid wraparound. is supposed to fix. It looks completely bogus to me. The only place it gets decremented is assert (obj->counter > 0); --obj->counter; Even if it gets decremented by some magic, its logic looks very strange to me. Bruno, do you have a testcase for your patch? I'd like to see it myself. BTW, it also passed "make check" under ia32. Thanks. H.J. --- 2000-09-08 H.J. Lu * iconv/gconv_dl.c (do_release_shlib): Remove the bogus patch made on 2000-09-03 by Bruno Haible . 2000-09-08 Franz Sirl . * sysdeps/ia64/Makefile (sysdep-rtld-routines): New variable. Index: iconv/gconv_dl.c =================================================================== RCS file: /work/cvs/gnu/glibc/iconv/gconv_dl.c,v retrieving revision 1.1.1.3 diff -u -p -r1.1.1.3 gconv_dl.c --- iconv/gconv_dl.c 2000/09/05 04:02:03 1.1.1.3 +++ iconv/gconv_dl.c 2000/09/08 18:21:01 @@ -164,8 +164,6 @@ do_release_shlib (const void *nodep, VIS } else if (obj->counter <= 0) { - if (obj->counter >= -TRIES_BEFORE_UNLOAD) - --obj->counter; if (obj->counter < -TRIES_BEFORE_UNLOAD && obj->handle != NULL) { /* Unload the shared object. */ Index: sysdeps/ia64/Makefile =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/ia64/Makefile,v retrieving revision 1.1.1.2 diff -u -p -r1.1.1.2 Makefile --- sysdeps/ia64/Makefile 2000/09/05 04:03:07 1.1.1.2 +++ sysdeps/ia64/Makefile 2000/09/08 16:13:44 @@ -5,4 +5,5 @@ endif ifeq ($(subdir),elf) sysdep-dl-routines += dl-symaddr dl-fptr sysdep_routines += $(sysdep-dl-routines) +sysdep-rtld-routines += $(sysdep-dl-routines) endif From drepper@redhat.com Sat Sep 9 00:10:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Sat, 09 Sep 2000 00:10:00 -0000 Subject: Recent glibc locale changes on ia64. References: <20000907173541.A586@valinux.com> <200009080402.VAA06947@pizda.ninka.net> <20000908114624.A8755@valinux.com> Message-ID: "H . J . Lu" writes: > --- iconv/gconv_dl.c 2000/09/05 04:02:03 1.1.1.3 > +++ iconv/gconv_dl.c 2000/09/08 18:21:01 > @@ -164,8 +164,6 @@ do_release_shlib (const void *nodep, VIS > } > else if (obj->counter <= 0) > { > - if (obj->counter >= -TRIES_BEFORE_UNLOAD) > - --obj->counter; > if (obj->counter < -TRIES_BEFORE_UNLOAD && obj->handle != NULL) > { > /* Unload the shared object. */ The code as it is is ok. Without it nothing would get unloaded. I just checked in a patch to make things a bit clearer (at least to me) but it should not have caused any problems. If something happened at this place the problem is somewhere else. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From rth@twiddle.net Sat Sep 9 12:39:00 2000 From: rth@twiddle.net (Richard Henderson) Date: Sat, 09 Sep 2000 12:39:00 -0000 Subject: soft-fp/ChangeLog References: Message-ID: <20000909123918.B19656@twiddle.net> On Tue, Sep 05, 2000 at 09:19:43PM +0200, Andreas Jaeger wrote: > Why has soft-fp a separate ChangeLog? Because it used to be a separate add-on. r~ From hjl@lucon.org Mon Sep 11 15:35:00 2000 From: hjl@lucon.org (H . J . Lu) Date: Mon, 11 Sep 2000 15:35:00 -0000 Subject: Bad iconv/skeleton.c changes. Message-ID: <20000911153553.A13019@lucon.org> On ia64, I got In file included from utf-16.c:363: ../iconv/skeleton.c: In function `gconv': ../iconv/skeleton.c:528: warning: passing arg 5 of `from_utf16_loop_unaligned' from incompatible pointer type ../iconv/skeleton.c:528: warning: passing arg 6 of `from_utf16_loop_unaligned' from incompatible pointer type ../iconv/skeleton.c:528: incompatible type for argument 7 of `from_utf16_loop_unaligned' ../iconv/skeleton.c:528: too few arguments to function `from_utf16_loop_unaligned' H.J. From drepper@redhat.com Mon Sep 11 15:44:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Mon, 11 Sep 2000 15:44:00 -0000 Subject: Bad iconv/skeleton.c changes. References: <20000911153553.A13019@lucon.org> Message-ID: "H . J . Lu" writes: > On ia64, I got > [...] Try it now. Neither Bruno nor I test by default anything != x86. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From hjl@valinux.com Mon Sep 11 19:47:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Mon, 11 Sep 2000 19:47:00 -0000 Subject: Function descriptor and dlopen/dlclose under ia64. Message-ID: <20000911193218.A29487@valinux.com> I may know why "make check" failed in iconvdata. The failed testcase is tst-loading. It does 5000 iterations of random dlopen/dlclose. The first few iterations are ok. It fails under ia64 after a few hundreds of iterations. Remember the official function descriptor, which is created at the fly by the dynamic linker. All DSOes use the same official function descriptor. If an official function descriptor is created by dloepn a DSO, we cannot free it via dlclose if it is used by another DSO later on. Basically, we need a reference count on the official function descriptor. Otherwise, we will be in deep trouble with dlopen/dlclose. H.J. From hjl@valinux.com Mon Sep 11 23:46:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Mon, 11 Sep 2000 23:46:00 -0000 Subject: [ia64-tools] Function descriptor and dlopen/dlclose under ia64. References: <20000911193218.A29487@valinux.com> Message-ID: <20000911234602.A4971@valinux.com> On Mon, Sep 11, 2000 at 07:32:18PM -0700, H . J . Lu wrote: > I may know why "make check" failed in iconvdata. The failed testcase > is tst-loading. It does 5000 iterations of random dlopen/dlclose. > The first few iterations are ok. It fails under ia64 after a few > hundreds of iterations. > > Remember the official function descriptor, which is created at the > fly by the dynamic linker. All DSOes use the same official function > descriptor. If an official function descriptor is created by dloepn a > DSO, we cannot free it via dlclose if it is used by another DSO later > on. Basically, we need a reference count on the official function > descriptor. Otherwise, we will be in deep trouble with dlopen/dlclose. > Apparently, for some reason, the ia64 port in glibc 2.2 left out some stuff in my working ia64 glibc 2.1 port. I will take a closer look at the ia64 port in glibc 2.2 and provide a patch when I find time. -- H.J. Lu (hjl@gnu.org) From jes@linuxcare.com Tue Sep 12 01:57:00 2000 From: jes@linuxcare.com (Jes Sorensen) Date: Tue, 12 Sep 2000 01:57:00 -0000 Subject: [ia64-tools] Function descriptor and dlopen/dlclose under ia64. References: <20000911193218.A29487@valinux.com> <20000911234602.A4971@valinux.com> Message-ID: >>>>> "HJ" == H J Lu writes: HJ> Apparently, for some reason, the ia64 port in glibc 2.2 left out HJ> some stuff in my working ia64 glibc 2.1 port. I will take a closer HJ> look at the ia64 port in glibc 2.2 and provide a patch when I find HJ> time. Apparantly you never submitted patches for anything you did or told anybody why so nobody had any idea what patches were applied in ``your'' glibc port and why they were there in the first place. Besides, some of your changes in there were obviously wrong anyway. Jes From jakub@redhat.com Thu Sep 14 01:04:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Thu, 14 Sep 2000 01:04:00 -0000 Subject: [PATCH] Fix regex compile_range, kill sparc64 warnings Message-ID: <20000914100910.O491@sunsite.ms.mff.cuni.cz> Hi! TRANSLATE casts to (char), so we cannot directly use it as index into collseq array. This has shown up on Alpha and Sparc64 as segfault (because the index was promoted to (int), not (long), but did not work properly on 32bit arches either. Also, while building glibc on sparc64 I came accross some warnings... (will need to give the 64bit glibc some testing still though, right now it seems at least 64bit gcc works with it). 2000-09-14 Jakub Jelinek * posix/regex.c (compile_range): Cast collseq index to unsigned char to avoid accessing data before collseq. * sysdeps/sparc/fpu/bits/mathinline.h (__unordered_v9cmp): Avoid pasting strings together. --- libc/posix/regex.c.jj Mon Aug 14 08:47:38 2000 +++ libc/posix/regex.c Thu Sep 14 09:58:37 2000 @@ -3531,11 +3531,11 @@ compile_range (range_start_char, p_ptr, collseq = (const unsigned char *) _NL_CURRENT (LC_COLLATE, _NL_COLLATE_COLLSEQMB); - start_colseq = collseq[TRANSLATE (range_start_char)]; - end_colseq = collseq[TRANSLATE (p[0])]; + start_colseq = collseq[(unsigned char) TRANSLATE (range_start_char)]; + end_colseq = collseq[(unsigned char) TRANSLATE (p[0])]; for (this_char = 0; this_char <= (unsigned char) -1; ++this_char) { - unsigned int this_colseq = collseq[TRANSLATE (this_char)]; + unsigned int this_colseq = collseq[(unsigned char) TRANSLATE (this_char)]; if (start_colseq <= this_colseq && this_colseq <= end_colseq) { --- libc/sysdeps/sparc/fpu/bits/mathinline.h.jj Tue Jul 18 10:31:50 2000 +++ libc/sysdeps/sparc/fpu/bits/mathinline.h Thu Sep 14 09:40:45 2000 @@ -1,7 +1,7 @@ /* Inline math functions for SPARC. Copyright (C) 1999, 2000 Free Software Foundation, Inc. This file is part of the GNU C Library. - Contributed by Jakub Jelinek . + Contributed by Jakub Jelinek . The GNU C Library is free software; you can redistribute it and/or modify it under the terms of the GNU Library General Public License as @@ -62,13 +62,13 @@ if (sizeof(x) == 4 && sizeof(y) == 4) \ { \ float __x = (x); float __y = (y); \ - __asm__("fcmps\t%%fcc3,%1,%2\n\tmov" ## op ## "\t%%fcc3,1,%0" \ + __asm__("fcmps\t%%fcc3,%1,%2\n\tmov" op "\t%%fcc3,1,%0" \ : "=r" (__r) : "f" (__x), "f" (__y), "0" (0) : "cc"); \ } \ else if (sizeof(x) <= 8 && sizeof(y) <= 8) \ { \ double __x = (x); double __y = (y); \ - __asm__("fcmpd\t%%fcc3,%1,%2\n\tmov" ## op ## "\t%%fcc3,1,%0" \ + __asm__("fcmpd\t%%fcc3,%1,%2\n\tmov" op "\t%%fcc3,1,%0" \ : "=r" (__r) : "f" (__x), "f" (__y), "0" (0) : "cc"); \ } \ else \ Jakub From drepper@redhat.com Thu Sep 14 01:22:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Thu, 14 Sep 2000 01:22:00 -0000 Subject: [PATCH] Fix regex compile_range, kill sparc64 warnings References: <20000914100910.O491@sunsite.ms.mff.cuni.cz> Message-ID: Jakub Jelinek writes: > 2000-09-14 Jakub Jelinek > > * posix/regex.c (compile_range): Cast collseq index to unsigned char > to avoid accessing data before collseq. > * sysdeps/sparc/fpu/bits/mathinline.h (__unordered_v9cmp): Avoid > pasting strings together. Thanks, I've applied the patch. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From jakub@redhat.com Thu Sep 14 09:08:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Thu, 14 Sep 2000 09:08:00 -0000 Subject: [PATCH] Fix dynamic linker Message-ID: <20000914181330.P491@sunsite.ms.mff.cuni.cz> Hi! This typo was causing JDK to segfault (well, obviously, because the while loop goes until *scope == NULL, then it went back to the while condition and dereferenced it to look up r_nlist). _dl_lookup_versioned_symbol_skip has if there, not while. 2000-09-14 Jakub Jelinek * elf/dl-lookup.c (_dl_lookup_symbol_skip): Fix a typo. --- libc/elf/dl-lookup.c.jj Fri Sep 1 11:37:58 2000 +++ libc/elf/dl-lookup.c Thu Sep 14 17:48:01 2000 @@ -306,7 +306,7 @@ _dl_lookup_symbol_skip (const char *unde for (i = 0; (*scope)->r_duplist[i] != skip_map; ++i) assert (i < (*scope)->r_nduplist); - while (i >= (*scope)->r_nlist + if (i >= (*scope)->r_nlist || ! do_lookup (undef_name, hash, *ref, ¤t_value, *scope, i, skip_map, 0, 0)) while (*++scope) Jakub From drepper@redhat.com Thu Sep 14 16:50:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Thu, 14 Sep 2000 16:50:00 -0000 Subject: next pre-release Message-ID: Hi, I want to make the next prerelease before Tuesday next week. The problems I'm seeing in the moment are: - on Arm, gcc cannot handle nested functions. I filed a PR. We cannot do much about this except compiling ld-collate.c without optimization - on PPC I see problems because the binutils we have on that machine is not handling .protected correctly. Geoff is currently tested a patch. The patch HJ sent out some time ago is not entirely correct as far as we can say now. - on Alpha I see many math errors and also the vismain test in elf/ is failing. The math errors are most probably due to the kernel we are running on that machine, the elf error probably due to old, in between the versions, binutils. I'm not aware of any other issues, especially not on x86. I don't know anything about any other architecture. Andreas, if you could update the PR list so that we can look through it there might be nothing preventing me from making 2.1.94. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From aj@suse.de Thu Sep 14 22:05:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Thu, 14 Sep 2000 22:05:00 -0000 Subject: next pre-release References: Message-ID: >>>>> Ulrich Drepper writes: > I'm not aware of any other issues, especially not on x86. I don't > know anything about any other architecture. Andreas, if you could > update the PR list so that we can look through it there might be > nothing preventing me from making 2.1.94. I've updated everything already yesterday and just forgot to announce it - the list is really short now. There're no show stoppers. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From schwab@suse.de Fri Sep 15 05:52:00 2000 From: schwab@suse.de (Andreas Schwab) Date: Fri, 15 Sep 2000 05:52:00 -0000 Subject: next pre-release References: Message-ID: <200009151252.e8FCqEx10486@hawking.suse.de> Ulrich Drepper writes: |> I'm not aware of any other issues, especially not on x86. I don't |> know anything about any other architecture. I have build from yesterday's CVS on m68k and didn't get any test failures. Andreas. -- Andreas Schwab "And now for something SuSE Labs completely different." Andreas.Schwab@suse.de SuSE GmbH, Schanz????ckerstr. 10, D-90443 N????rnberg From jakub@redhat.com Fri Sep 15 05:52:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Fri, 15 Sep 2000 05:52:00 -0000 Subject: [PATCH] syscall fix for Alpha/Arm/M68k (was Re: next pre-release) References: Message-ID: <20000915145359.A2035@sunsite.ms.mff.cuni.cz> On Thu, Sep 14, 2000 at 04:50:17PM -0700, Ulrich Drepper wrote: > Hi, > > I want to make the next prerelease before Tuesday next week. The > problems I'm seeing in the moment are: > > - on Arm, gcc cannot handle nested functions. I filed a PR. We cannot > do much about this except compiling ld-collate.c without optimization > > - on PPC I see problems because the binutils we have on that machine is > not handling .protected correctly. Geoff is currently tested a patch. > The patch HJ sent out some time ago is not entirely correct as far as > we can say now. > > - on Alpha I see many math errors and also the vismain test in elf/ is > failing. The math errors are most probably due to the kernel we are > running on that machine, the elf error probably due to old, in between > the versions, binutils. > > I'm not aware of any other issues, especially not on x86. I don't > know anything about any other architecture. Andreas, if you could > update the PR list so that we can look through it there might be > nothing preventing me from making 2.1.94. Could you please install my yesterday's _dl_lookup_symbol_skip patch? That one is an issue on x86 as well. The patch below fixes sysctl on Alpha, where gcc -O2 and -O3 optimize too much and move stores into the sysctl_args structure after the syscall where they are useless. This was the reason why alphaev4 glibc would load (all stores happened past the syscall, so it returned -EFAULT) and would not start at all on alphaev6 (where name and namelen were stored and the rest were zeros). I have checked other ports and alpha, arm and m68k were the only posts not adding "memory" into syscall clobbers. But a syscall usually clobbers memory, and we don't have any macros how to tell which INLINE_SYSCALL will clobber which memory. 2000-09-15 Jakub Jelinek * sysdeps/unix/alpha/sysdep.h (inline_syscall_clobbers): Add memory clobber. * sysdeps/unix/sysv/linux/arm/sysdep.h (INLINE_SYSCALL): Likewise. * sysdeps/unix/sysv/linux/m68k/sysdep.h (INLINE_SYSCALL): Likewise. --- libc/sysdeps/unix/alpha/sysdep.h.jj Sun Nov 1 00:37:54 1998 +++ libc/sysdeps/unix/alpha/sysdep.h Fri Sep 15 14:36:26 2000 @@ -1,4 +1,4 @@ -/* Copyright (C) 1992, 1995, 1996 Free Software Foundation, Inc. +/* Copyright (C) 1992, 1995, 1996, 2000 Free Software Foundation, Inc. This file is part of the GNU C Library. Contributed by Brendan Kehoe (brendan@zen.org). @@ -131,7 +131,7 @@ __LABEL(name) \ #define inline_syscall_clobbers \ "$1", "$2", "$3", "$4", "$5", "$6", "$7", "$8", \ - "$22", "$23", "$24", "$25", "$27", "$28" + "$22", "$23", "$24", "$25", "$27", "$28", "memory" /* It is moderately important optimization-wise to limit the lifetime of the hard-register variables as much as possible. Thus we copy --- libc/sysdeps/unix/sysv/linux/arm/sysdep.h.jj Wed Aug 2 21:36:35 2000 +++ libc/sysdeps/unix/sysv/linux/arm/sysdep.h Fri Sep 15 14:37:40 2000 @@ -131,7 +131,7 @@ asm volatile ("swi %1 @ syscall " #name \ : "=r" (_a1) \ : "i" (SYS_ify(name)) ASM_ARGS_##nr \ - : "a1"); \ + : "a1" : "memory"); \ _sys_result = _a1; \ } \ if (_sys_result >= (unsigned int) -4095) \ --- libc/sysdeps/unix/sysv/linux/m68k/sysdep.h.jj Mon Nov 16 03:41:56 1998 +++ libc/sysdeps/unix/sysv/linux/m68k/sysdep.h Fri Sep 15 14:40:29 2000 @@ -1,4 +1,4 @@ -/* Copyright (C) 1996, 1997, 1998 Free Software Foundation, Inc. +/* Copyright (C) 1996, 1997, 1998, 2000 Free Software Foundation, Inc. This file is part of the GNU C Library. Written by Andreas Schwab, , December 1995. @@ -171,7 +171,7 @@ SYSCALL_ERROR_LABEL: \ asm volatile ("trap #0" \ : "=d" (_d0) \ : "0" (_d0) ASM_ARGS_##nr \ - : "d0"); \ + : "d0" : "memory"); \ _sys_result = _d0; \ } \ if (_sys_result >= (unsigned int) -4095) \ Jakub From hjl@lucon.org Fri Sep 15 09:48:00 2000 From: hjl@lucon.org (H . J . Lu) Date: Fri, 15 Sep 2000 09:48:00 -0000 Subject: next pre-release References: <200009151252.e8FCqEx10486@hawking.suse.de> Message-ID: <20000915094854.B24473@lucon.org> On Fri, Sep 15, 2000 at 02:52:14PM +0200, Andreas Schwab wrote: > Ulrich Drepper writes: > > |> I'm not aware of any other issues, especially not on x86. I don't > |> know anything about any other architecture. > > I have build from yesterday's CVS on m68k and didn't get any test > failures. ia64 is broken. But it never worked right under 2.2. I will have a patch as soon as I find time to make one. H.J. From drepper@redhat.com Fri Sep 15 10:30:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Fri, 15 Sep 2000 10:30:00 -0000 Subject: [PATCH] Fix dynamic linker References: <20000914181330.P491@sunsite.ms.mff.cuni.cz> Message-ID: Jakub Jelinek writes: > 2000-09-14 Jakub Jelinek > > * elf/dl-lookup.c (_dl_lookup_symbol_skip): Fix a typo. I've applied it now and also checked in a test. Thanks, -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Fri Sep 15 10:50:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Fri, 15 Sep 2000 10:50:00 -0000 Subject: [PATCH] syscall fix for Alpha/Arm/M68k (was Re: next pre-release) References: <20000915145359.A2035@sunsite.ms.mff.cuni.cz> Message-ID: Jakub Jelinek writes: > The patch below fixes sysctl on Alpha, where gcc -O2 and -O3 optimize too > much and move stores into the sysctl_args structure after the syscall where > they are useless. Thanks, I've applied the patch. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From kukuk@suse.de Sat Sep 16 10:15:00 2000 From: kukuk@suse.de (Thorsten Kukuk) Date: Sat, 16 Sep 2000 10:15:00 -0000 Subject: make check on Alpha and SPARC (with patch for alpha) Message-ID: <20000916191502.A2768@suse.de> Hi, I compiled the current glibc cvs version and some problems on Alpha and SPARC. On both, Alpha and SPARC tst-mtrace failed. In the tst-mtrace.out file, there are a lot of entries with "Alloc XX duplicate: ...." and 2 entries with Memory not freed. Since I don't know what the test expects, I don't know how to fix this. On Alpha, also tfformat fails, I don't know why. For tst-limits I append a patch. INT_MAX was used for "long int" in bits/xopen_lim.h which is wrong. LONG_MAX should be used. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background. From drepper@redhat.com Sat Sep 16 10:44:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Sat, 16 Sep 2000 10:44:00 -0000 Subject: make check on Alpha and SPARC (with patch for alpha) References: <20000916191502.A2768@suse.de> Message-ID: Thorsten Kukuk writes: > On both, Alpha and SPARC tst-mtrace failed. In the tst-mtrace.out > file, there are a lot of entries with "Alloc XX duplicate: ...." > and 2 entries with Memory not freed. Since I don't know what the > test expects, I don't know how to fix this. The test expects to see no errors. If these duplicate messages are genuine these is a real problem (but I actually double it). You should be able to find out with the other information in the file where the calls are made. Also, there should be no unfreed memory. Again, the other information is should help to locate the problem. The tests run fine on x86, PPC, Arm, and Andreas's said on m68k. Also, I have glibc compiled on an ev6 and this test didn't fail (some others did, but are mostly kernel-related). > On Alpha, also tfformat fails, I don't know why. Nope, this doesn't fail either. Your compiler seems to have problems. Or maybe it's your kernel. > For tst-limits I append a patch. INT_MAX was used for "long int" in > bits/xopen_lim.h which is wrong. LONG_MAX should be used. I'll fix that. Thanks, -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From hjl@valinux.com Sat Sep 16 12:07:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Sat, 16 Sep 2000 12:07:00 -0000 Subject: A patch for typo in include/bits/xopen_lim.h Message-ID: <20000916120751.A5086@valinux.com> I believe it is a typo. Here is a patch. -- H.J. Lu (hjl@gnu.org) --- 2000-09-16 H.J. Lu * include/bits/xopen_lim.h (LONG_BIT): Check LONG_MAX not INT_MAX. Index: include/bits/xopen_lim.h =================================================================== RCS file: /work/cvs/gnu/glibc/include/bits/xopen_lim.h,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 xopen_lim.h --- include/bits/xopen_lim.h 2000/05/21 21:11:02 1.1.1.1 +++ include/bits/xopen_lim.h 2000/09/16 19:05:19 @@ -104,7 +104,7 @@ #endif /* Number of bits in a word of type `long int'. */ -#if INT_MAX == 2147483647 +#if LONG_MAX == 2147483647 # define LONG_BIT 32 #else /* Safe assumption. */ From drepper@redhat.com Sat Sep 16 12:15:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Sat, 16 Sep 2000 12:15:00 -0000 Subject: A patch for typo in include/bits/xopen_lim.h References: <20000916120751.A5086@valinux.com> Message-ID: "H . J . Lu" writes: > I believe it is a typo. Here is a patch. Already fix. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From jakub@redhat.com Sat Sep 16 12:23:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Sat, 16 Sep 2000 12:23:00 -0000 Subject: [PATCH] Don't warn about stale .so symlinks during ldconfig Message-ID: <20000916212557.A622@sunsite.ms.mff.cuni.cz> Hi! ldconfig should not warn about stale .so symlinks (it already does not warn about stale .so.* symlinks). 2000-09-16 Jakub Jelinek * elf/readlib.c (process_file): Don't error for stale .so links either. --- libc/elf/readlib.c.jj Sat Sep 16 15:22:20 2000 +++ libc/elf/readlib.c Sat Sep 16 21:24:14 2000 @@ -87,7 +87,7 @@ process_file (const char *file_name, con if (file == NULL) { /* No error for stale symlink. */ - if (is_link && strstr (file_name, ".so.") != NULL) + if (is_link && strstr (file_name, ".so") != NULL) return 1; error (0, 0, _("Input file %s not found.\n"), file_name); return 1; Jakub From jakub@redhat.com Sat Sep 16 12:52:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Sat, 16 Sep 2000 12:52:00 -0000 Subject: [PATCH] Fix nexttoward on sparc64/ia64/m68k Message-ID: <20000916215500.B622@sunsite.ms.mff.cuni.cz> Hi! s_nexttoward.c is present both in ieee754/dbl-64 and ieee754/ldbl-*. In dbl-64 it is for architectures which have 64bit long double, while the ldbl-* version should be used on the other arches. On ia64/m68k/sparc64 though comes dbl-64 in Implies before ldbl-*, so s_nexttoward.c is used from dbl-64 directory. The result is that nexttoward function is missing (spotted on sparc64). i386 already has ldbl-96 first. Fixed thusly: 2000-09-16 Jakub Jelinek * sysdeps/ia64/Implies: Reorder ieee754 implies so that ldbl-* comes first. * sysdeps/m68k/Implies: Likewise. * sysdeps/sparc/sparc64/Implies: Likewise. --- libc/sysdeps/ia64/Implies.jj Sat Aug 26 00:47:11 2000 +++ libc/sysdeps/ia64/Implies Sat Sep 16 21:29:24 2000 @@ -1,5 +1,5 @@ wordsize-64 # ia64 uses IEEE 754 floating point. -ieee754/flt-32 -ieee754/dbl-64 ieee754/ldbl-96 +ieee754/dbl-64 +ieee754/flt-32 --- libc/sysdeps/m68k/Implies.jj Tue Jan 4 17:11:56 2000 +++ libc/sysdeps/m68k/Implies Sat Sep 16 21:29:35 2000 @@ -1,5 +1,5 @@ wordsize-32 # 68k uses IEEE 754 floating point. -ieee754/flt-32 -ieee754/dbl-64 ieee754/ldbl-96 +ieee754/dbl-64 +ieee754/flt-32 --- libc/sysdeps/sparc/sparc64/Implies.jj Mon Sep 11 14:45:52 2000 +++ libc/sysdeps/sparc/sparc64/Implies Sat Sep 16 21:29:52 2000 @@ -1,6 +1,6 @@ wordsize-64 # SPARC uses IEEE 754 floating point. -ieee754/flt-32 -ieee754/dbl-64 ieee754/ldbl-128 +ieee754/dbl-64 +ieee754/flt-32 sparc/sparc64/soft-fp Jakub From drepper@redhat.com Sat Sep 16 15:58:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Sat, 16 Sep 2000 15:58:00 -0000 Subject: [PATCH] Don't warn about stale .so symlinks during ldconfig References: <20000916212557.A622@sunsite.ms.mff.cuni.cz> Message-ID: Jakub Jelinek writes: > ldconfig should not warn about stale .so symlinks (it already does not warn > about stale .so.* symlinks). Seems reasonable. I've applied the patch. Thanks, -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Sat Sep 16 16:00:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Sat, 16 Sep 2000 16:00:00 -0000 Subject: [PATCH] Fix nexttoward on sparc64/ia64/m68k References: <20000916215500.B622@sunsite.ms.mff.cuni.cz> Message-ID: Jakub Jelinek writes: > s_nexttoward.c is present both in ieee754/dbl-64 and ieee754/ldbl-*. In > dbl-64 it is for architectures which have 64bit long double, while the > ldbl-* version should be used on the other arches. Thanks, I've applied the patch. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From hjl@valinux.com Sat Sep 16 16:16:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Sat, 16 Sep 2000 16:16:00 -0000 Subject: A patch for catgets/Makefile Message-ID: <20000916161617.A915@valinux.com> I know the error is ignored. But .... -- H.J. Lu (hjl@gnu.org) --- 2000-09-16 H.J. Lu * catgets/Makefile ($(objpfx)de/libc.cat): Add -p to mkdir. Index: catgets/Makefile =================================================================== RCS file: /work/cvs/gnu/glibc/catgets/Makefile,v retrieving revision 1.1.1.2 diff -u -p -r1.1.1.2 Makefile --- catgets/Makefile 2000/09/07 20:25:43 1.1.1.2 +++ catgets/Makefile 2000/09/16 23:12:52 @@ -55,7 +55,7 @@ tests: $(objpfx)de/libc.cat $(objpfx)tes $(objpfx)test1.cat: test1.msg $(objpfx)gencat $(built-program-cmd) -H $(objpfx)test1.h $@ $< $(objpfx)de/libc.cat: $(objpfx)de.msg $(objpfx)gencat - -mkdir $(objpfx)de + -mkdir -p $(objpfx)de $(built-program-cmd) $@ $< $(objpfx)tst-catgets.out: $(objpfx)de/libc.cat From hjl@valinux.com Sat Sep 16 16:39:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Sat, 16 Sep 2000 16:39:00 -0000 Subject: binutils 2.10.0.26 is released. Message-ID: <20000916163133.A1486@valinux.com> My alpha machine is shutdown. There is no alpha binary rpm this time. -- H.J. Lu (hjl@gnu.org) -- This is the beta release of binutils 2.10.0.26 for Linux, which is based on binutils 2000 00907 in CVS on sourecware.cygnus.com plus various changes. It is purely for Linux, although it has been tested on Solaris/Sparc and Solaris/x86 from time to time. I am planning to make the public release soon. Please test it as much as you can. Please report any bugs related to binutils 2.10.0.26 to hjl@lucon.org. For arm-linux targets, there are some important differences in behaviour between these tools and binutils 2.9.1.0.x. The linker emulation name has changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be passed with the linker when working with object files (or static libraries) created using older versions of the assembler. If this flag is omitted the linker will silently generate bad output when given old input files. To get the correct behaviour from gcc, amend the *link section of your specs file as follows: *link: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared} %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m armelf_linux26} %{!mapcs-26:-m armelf_linux} -p Changes from binutils 2.10.0.24: 1. Update from binutils 2000 0907. Changes from binutils 2.10.0.18: 1. Update from binutils 2000 0823. Fix DT_RPATH/DT_RUNPATH handling. Fix the ELF/ia32 DSO not compiled with PIC. 2. Try to fix the ELF visibility bug on PPC with glibc 2.2. Changes from binutils 2.10.0.12: 1. Update from binutils 2000 0720. 2. Fix the DT_NEEDED link bug. 3. Add the new DT_XXXX dynamic tags. Glibc 2.2 will use them at least on libpthread.so. Changes from binutils 2.10.0.9: 1. Update from binutils 2000 0701. Fix the parallel build in ld when PE is enabled. Changes from binutils 2.9.5.0.46: 1. Update from binutils 2000 0617. The demangler support for the new g++ ABI. Minor fix for the ELF visibility. Fix linking non-ELF relocatable object files under ELF with symbol versioning. 2. Support for linking PE relocatable object files under ia32/ELF. Changes from binutils 2.9.5.0.42: 1. Update from binutils 2000 0604. The ELF visibility attribuite should work correctly now. 2. The ia32 assembler has changed the way it assembles the "jmp" instructions to the global symbols. The old assembler will optimize the jump to the global symbol defined in the same source file so that no relocation will be used. The new assembler will use relocation for global jumps. It will mainly affect PIC asm code. The segment like .globl __setjmp __setjmp: ... jmp __sigsetjmp ... .globl __sigsetjmp __sigsetjmp: is no longer PIC safe since "jmp __sigsetjmp" jumps to a global symbol and relocation will be used. Instead, it can be changed to .globl __setjmp __setjmp: ... jmp sigsetjmp ... .globl __sigsetjmp __sigsetjmp: sigsetjmp: so that "jmp sigsetjmp" jumps to a local symbol and the new assembler will optimize out the relocation. Changes from binutils 2.9.5.0.41: 1. Update from binutils 2000 0512. 2. Add testsuite for ELF visibility. Changes from binutils 2.9.5.0.37: 1. Update from binutils 2000 0502. 2. Support STV_HIDDEN and STV_INTERNAL. Changes from binutils 2.9.5.0.35: 1. Update from binutils 2000 0418. 2. Fix an ld demangle style option bug. Changes from binutils 2.9.5.0.34: 1. Update from binutils 2000 0412. Fix a relocation bug which affects the Linux kernel compilation. 2. An ELF/PPC linker script update. Changes from binutils 2.9.5.0.33: 1. Update from binutils 2000 0404. Fix the bug report bug. Changes from binutils 2.9.5.0.32: 1. Update from binutils 2000 0403. Fix the 16bit ia32 assembler bug. Changes from binutils 2.9.5.0.31: 1. Update from binutils 2000 0331. Fix the Linux/ARM assembler bug. 2. Fix a Debian assembler security bug. Changes from binutils 2.9.5.0.29: 1. Update from binutils 2000 0319. 2. An ELF/alpha bug is fixed. Changes from binutils 2.9.5.0.27: 1. Update from binutils 2000 0301. 2. A demangler bug is fixed. 3. A better fix for undefined symbols with -Bsymbolic when building shared library. Changes from binutils 2.9.5.0.24: 1. Update from binutils 2000 0204. 2. Added -taso to linker on alpha. 3. Fixed a -shared -Bsymbolic bug when PIC is not used. Changes from binutils 2.9.5.0.22: 1. Update from binutils 2000 0113. 2. A symbol version bug is fixed. 3. A -Bsymbolic bug is fixed. Changes from binutils 2.9.5.0.21: 1. Update from binutils 1999 1202. 2. Remove a MIPS/ELF change. 3. Enable SOM for HPPA. Changes from binutils 2.9.5.0.19: 1. Update from binutils 1999 1122. An ia32 gas bug is fixed. Changes from binutils 2.9.5.0.16: 1. Update from binutils 1999 1104. 2. i370 is changed to use EM_S370 and ELFOSABI_LINUX. Update readelf. 3. Fix Compaq's demangler support. Changes from binutils 2.9.5.0.14: 1. Update from binutils 1999 1012. A gas bug which affects Linux 2.3.21 is fixed. 2. i370 update. 3. The new demangler code. You should use "--style=xxx" to select the demnangle style instead of "--lang=xxx". Changes from binutils 2.9.5.0.13: 1. Update from binutils 1999 0925. 2. Fix a -s and linker script bug. Changes from binutils 2.9.5.0.12: 1. Update from binutils 1999 0922. 2. i370 update. Changes from binutils 2.9.5.0.11: 1. Update from binutils 1999 0910. It fixed a PIC linker bug on ix86 and sparc introduced in the last release. 2. i370 update. Changes from binutils 2.9.5.0.10: 1. Update from binutils 1999 0906. It fixed a PIC linker bug on ix86 and sparc. 2. Remove elf/hppa since it is WIP. Changes from binutils 2.9.5.0.8: 1. Update from binutils 1999 0831. It allows spaces around '(' and ')' in x86 FP register names. Changes from binutils 2.9.5.0.7: 1. Update from binutils 1999 0821. 2. Some MIPS changes. Changes from binutils 2.9.5.0.6: 1. Update from binutils 1999 0813. 2. i370 update. Changes from binutils 2.9.5.0.5: 1. Update from binutils 1999 0809. An ELF/Sparc ld bug is fixed. Changes from binutils 2.9.5.0.4: 1. Update from binutils 1999 0806. A Solaris/Sparc gas bug is fixed. 2. Remove mips gas patches from binutils 2.9.1.0.25. Changes from binutils 2.9.5.0.3: 1. Update from binutils 1999 0801. 2. Support for real mode x86 gcc. Changes from binutils 2.9.4.0.8: 1. Update from binutils 1999 0719. A libc 5 related bug fix. 2. Fix a typo in mips gas. Changes from binutils 2.9.4.0.7: 1. Update from binutils 1999 0710. A weak symbol bug http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00129.html is fixed. Changes from binutils 2.9.4.0.6: 1. Update from binutils 1999 0626. Changes from binutils 2.9.4.0.5: 1. Update from binutils 1999 0620. 2. Remove my fwait fix and use the one in cvs. 3. Use "--only-section=section" instead of "--extract-section=section". for objcopy. Changes from binutils 2.9.4.0.4: 1. Update from binutils 1999 0612. 2. Remove various temporary fixes of mine since those bugs are fixed now. Changes from binutils 2.9.4.0.3: 1. Update from binutils 1999 0611. 2. Remove my ELF/Alpha bfd changes. 3. Use the local symbol copy fix in binutils 1999 0611. Changes from binutils 2.9.4.0.2: 1. Update from binutils 1999 0607. 2. Remove my Sparc hacks. 3. Fix local symbol copy. Changes from binutils 2.9.4.0.1: 1. Update from binutils 1999 0606. 2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that Linux kernel can build. 3. Fix i370 for the new gas. Changes from binutils 1999 0605: 1. Fix a -Bsymbolic bug for Linux/alpha. 2. Add ELF/i370. 3. Fix 8/16-bit relocations for i386. 4. Add --redefine-sym=old_form=new_form to objcopy. 5. Add "-j section" for objcopy. 6. Fix i386 disassembler for fwait. 7. Fix a Sparc asm bug. 8. Add Ada demangle support. 9. Fix MIPS/ELF bugs. 10. Add some vxworks suppport. 11. Fix a.out assembler. The file list: 1. binutils-2.10.0.26.tar.gz. Source code. 2. binutils-2.10.0.24-2.10.0.26.diff.gz. Patch against the previous beta source code. 3. binutils-2.10.0.26-1.i386.rpm. IA-32 binary RPM for RedHat 6.2. There is no separate source rpm. You can do # rpm -ta binutils-2.10.0.26.tar.gz to create both binary and source rpms. The primary sites for the beta Linux binutils are: 1. http://ftp.valinux.com/pub/support/hjl/binutils Thanks. H.J. Lu hjl@lucon.org 09/16/2000 From hjl@valinux.com Sat Sep 16 17:14:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Sat, 16 Sep 2000 17:14:00 -0000 Subject: elf/reldep3.c differs on ia32 and ia64 Message-ID: <20000916171403.A2706@valinux.com> For some reason, elf/reldep3.c differs on ia32 and ia64. I am enclosing the ia32 trace, ia32.2661, and the ia64 trace, ia64.24316, here. On ia64, I got variable "some_var" not reset As you can see, ia64.24316 has 24316: file=/home/work/build/glibc/elf/reldepmod1.so; needed by /home/work/build/glibc/elf/reldepmod4.so (relocation dependency) while ia32.2661 doesn't. It counts for one more open count on reldepmod1.so under ia64. It may have something to do with the function descriptor for "call_me" created by reldepmod1.so and used by reldepmod4.so. Jes, Ulrich, any ideas? Thanks. H.J. From hjl@valinux.com Sat Sep 16 17:35:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Sat, 16 Sep 2000 17:35:00 -0000 Subject: My current ia64 patch for glibc 2.2. Message-ID: <20000916173514.A3502@valinux.com> This patch makes glibc 2.2 closer to my ia64 port of glibc 2.1. I will see if there is anything else missing in glibc 2.2. Thanks. H.J. ---- 2000-09-16 H.J. Lu * sysdeps/generic/ldsodefs.h (DL_LOOKUP_ADDRESS): New. Defined if ELF_FUNCTION_PTR_IS_SPECIAL is not defined. * sysdeps/ia64/dl-lookupcfg.h (_dl_lookup_address): New prototype. (DL_LOOKUP_ADDRESS): New. Defined as _dl_lookup_address. * sysdeps/ia64/dl-fptr.c (_dl_lookup_address): New. Lookup the memory location of a function from a function descriptor. * sysdeps/ia64/Versions [ld] (GLIBC_2.2): Add _dl_lookup_address. * elf/dl-addr.c (_dl_addr): Use DL_LOOKUP_ADDRESS to get the memory location. 2000-09-16 H.J. Lu * elf/rtld.c (ELF_MACHINE_ADJUST_ARGV): New macro. Do nothing if not defined. (_dl_start_final): Use ELF_MACHINE_ADJUST_ARGV to adjust _dl_argv with _dl_skip_args. * sysdeps/ia64/dl-machine.h (ELF_MACHINE_FIXED_STACK): Removed. (ELF_MACHINE_ADJUST_ARGV): New. 2000-09-16 H.J. Lu * sysdeps/generic/ldsodefs.h (DL_UNMAP): New. Defined if DL_UNMAP_IS_SPECIAL is not defined. * sysdeps/ia64/dl-lookupcfg.h (DL_UNMAP_IS_SPECIAL): Defined. (_dl_unmap): New prototype. (DL_UNMAP): New. Defined as _dl_unmap. * sysdeps/ia64/Versions [ld] (GLIBC_2.2): Add _dl_unmap. * elf/dl-close.c (_dl_close): Replace __munmap with DL_UNMAP. 2000-08-27 H.J. Lu * sysdeps/unix/sysv/linux/ia64/fork.S: New. * sysdeps/unix/sysv/linux/ia64/vfork.S: Likewise. * sysdeps/unix/sysv/linux/ia64/clone.S: Make it dummy. No need for it. 2000-08-24 H.J. Lu * elf/soinit.c (object): FIXME. Change it to void * dummy [16]; for ia64. Index: elf/dl-addr.c =================================================================== RCS file: /work/cvs/gnu/glibc/elf/dl-addr.c,v retrieving revision 1.1.1.3 diff -u -p -r1.1.1.3 dl-addr.c --- elf/dl-addr.c 2000/07/18 00:27:21 1.1.1.3 +++ elf/dl-addr.c 2000/09/16 22:21:26 @@ -26,7 +26,7 @@ int internal_function _dl_addr (const void *address, Dl_info *info) { - const ElfW(Addr) addr = (ElfW(Addr)) address; + const ElfW(Addr) addr = DL_LOOKUP_ADDRESS (address); struct link_map *l, *match; const ElfW(Sym) *symtab, *matchsym; const char *strtab; Index: elf/dl-close.c =================================================================== RCS file: /work/cvs/gnu/glibc/elf/dl-close.c,v retrieving revision 1.1.1.8 diff -u -p -r1.1.1.8 dl-close.c --- elf/dl-close.c 2000/08/31 16:48:13 1.1.1.8 +++ elf/dl-close.c 2000/09/16 22:27:40 @@ -167,8 +167,7 @@ _dl_close (void *_map) /* We can unmap all the maps at once. We determined the start address and length when we loaded the object and the `munmap' call does the rest. */ - __munmap ((void *) imap->l_map_start, - imap->l_map_end - imap->l_map_start); + DL_UNMAP (imap); /* Finally, unlink the data structure and free it. */ #ifdef SHARED Index: elf/rtld.c =================================================================== RCS file: /work/cvs/gnu/glibc/elf/rtld.c,v retrieving revision 1.1.1.11 diff -u -p -r1.1.1.11 rtld.c --- elf/rtld.c 2000/09/16 06:40:17 1.1.1.11 +++ elf/rtld.c 2000/09/16 17:52:16 @@ -278,6 +278,12 @@ _dl_start_final (void *arg, struct link_ if (__builtin_expect (_dl_debug_statistics, 0)) print_statistics (); +#ifndef ELF_MACHINE_ADJUST_ARGV +# define ELF_MACHINE_ADJUST_ARGV(argv,skip) /* nothing */ +#endif + + ELF_MACHINE_ADJUST_ARGV (_dl_argv, _dl_skip_args); + return *start_addr; } Index: elf/soinit.c =================================================================== RCS file: /work/cvs/gnu/glibc/elf/soinit.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 soinit.c --- elf/soinit.c 2000/05/21 21:10:57 1.1.1.1 +++ elf/soinit.c 2000/08/25 00:27:01 @@ -25,12 +25,16 @@ static char __EH_FRAME_BEGIN__[] /* This must match what's in frame.h in gcc. How can one do that? */ struct object { +#if 0 void *pc_begin; void *pc_end; void *fde_begin; void *fde_array; __SIZE_TYPE__ count; struct object *next; +#else + void * dummy [16]; +#endif }; extern void __register_frame_info (const void *, struct object *); extern void __deregister_frame_info (const void *); Index: sysdeps/generic/ldsodefs.h =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/generic/ldsodefs.h,v retrieving revision 1.1.1.10 diff -u -p -r1.1.1.10 ldsodefs.h --- sysdeps/generic/ldsodefs.h 2000/08/31 16:48:50 1.1.1.10 +++ sysdeps/generic/ldsodefs.h 2000/09/16 22:29:42 @@ -69,6 +69,14 @@ typedef ElfW(Addr) lookup_t; #ifndef ELF_FUNCTION_PTR_IS_SPECIAL #define DL_SYMBOL_ADDRESS(map, ref) \ (void *) (LOOKUP_VALUE_ADDRESS (map) + ref->st_value) +#define DL_LOOKUP_ADDRESS(addr) ((ElfW(Addr)) (addr)) +#endif + +/* Unmap a loaded object, called by _dl_close (). */ +#ifndef DL_UNMAP_IS_SPECIAL +#define DL_UNMAP(map) \ + __munmap ((void *) (map)->l_map_start, (map)->l_map_end \ + - (map)->l_map_start) #endif /* For the version handling we need an array with only names and their Index: sysdeps/ia64/Versions =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/ia64/Versions,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 Versions --- sysdeps/ia64/Versions 2000/05/21 21:12:03 1.1.1.1 +++ sysdeps/ia64/Versions 2000/09/16 22:23:55 @@ -1,6 +1,7 @@ ld { GLIBC_2.2 { # ia64 specific functions in the dynamic linker, but used by libc.so. - _dl_symbol_address; + _dl_symbol_address; _dl_unmap; _dl_lookup_address; + } } Index: sysdeps/ia64/dl-fptr.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/ia64/dl-fptr.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 dl-fptr.c --- sysdeps/ia64/dl-fptr.c 2000/05/21 21:12:03 1.1.1.1 +++ sysdeps/ia64/dl-fptr.c 2000/09/16 23:43:10 @@ -184,3 +184,29 @@ _dl_unmap (struct link_map *map) __ia64_fptr_lock = 0; #endif } + +Elf64_Addr +_dl_lookup_address (const void *address) +{ + Elf64_Addr addr = (Elf64_Addr) address; + struct ia64_fptr *f; + +#ifdef _LIBC_REENTRANT + /* Make sure we are alone. */ + while (testandset (&__ia64_fptr_lock)); +#endif + + for (f = __fptr_root; f != NULL; f = f->next) + if (f == address) + { + addr = f->func; + break; + } + +#ifdef _LIBC_REENTRANT + /* Release the lock. */ + __ia64_fptr_lock = 0; +#endif + + return addr; +} Index: sysdeps/ia64/dl-lookupcfg.h =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/ia64/dl-lookupcfg.h,v retrieving revision 1.1.1.2 diff -u -p -r1.1.1.2 dl-lookupcfg.h --- sysdeps/ia64/dl-lookupcfg.h 2000/06/09 18:42:39 1.1.1.2 +++ sysdeps/ia64/dl-lookupcfg.h 2000/09/16 22:29:38 @@ -21,7 +21,16 @@ than just the address. */ #define DL_LOOKUP_RETURNS_MAP #define ELF_FUNCTION_PTR_IS_SPECIAL +#define DL_UNMAP_IS_SPECIAL void *_dl_symbol_address (const struct link_map *map, const ElfW(Sym) *ref); #define DL_SYMBOL_ADDRESS(map, ref) _dl_symbol_address(map, ref) + +Elf64_Addr _dl_lookup_address (const void *address); + +#define DL_LOOKUP_ADDRESS(addr) _dl_lookup_address (addr) + +void _dl_unmap (struct link_map *map); + +#define DL_UNMAP(map) _dl_unmap (map) Index: sysdeps/ia64/dl-machine.h =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/ia64/dl-machine.h,v retrieving revision 1.1.1.2 diff -u -p -r1.1.1.2 dl-machine.h --- sysdeps/ia64/dl-machine.h 2000/06/09 18:42:39 1.1.1.2 +++ sysdeps/ia64/dl-machine.h 2000/09/16 17:52:14 @@ -403,7 +403,7 @@ _dl_start_user: /* Since ia64's stack has to be 16byte aligned, we cannot arbitrarily move the stack pointer. */ -#define ELF_MACHINE_FIXED_STACK 1 +#define ELF_MACHINE_ADJUST_ARGV(argv,skip) (argv) -= (skip); /* Return the address of the entry point. */ extern ElfW(Addr) _dl_start_address (const struct link_map *map, Index: sysdeps/unix/sysv/linux/ia64/clone.S =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/unix/sysv/linux/ia64/clone.S,v retrieving revision 1.1.1.2 diff -u -p -r1.1.1.2 clone.S --- sysdeps/unix/sysv/linux/ia64/clone.S 2000/08/01 03:26:02 1.1.1.2 +++ sysdeps/unix/sysv/linux/ia64/clone.S 2000/08/01 03:32:58 @@ -1,76 +1 @@ -/* Copyright (C) 1999,2000 Free Software Foundation, Inc. - - The GNU C Library is free software; you can redistribute it and/or - modify it under the terms of the GNU Library General Public License as - published by the Free Software Foundation; either version 2 of the - License, or (at your option) any later version. - - The GNU C Library is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - Library General Public License for more details. - - You should have received a copy of the GNU Library General Public - License along with the GNU C Library; see the file COPYING.LIB. If not, - write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, - Boston, MA 02111-1307, USA. */ - -/* clone is even more special than fork as it mucks with stacks - and invokes a function in the right context after its all over. */ - -#include - -/* int clone(int (*fn)(void *arg), void *child_stack, int flags, void *arg); */ - -/* - * Used for both clone and fork system calls. Note that if fn is NULL - * then clone was called from fork. - */ - -ENTRY(__clone) - add r2 = -16, r33 // save space for fn and arg - cmp.ne p6,p0 = 0,r33 - ;; -(p6) add r33 = -16, r33 - add r12 = -16, r12 - ;; -(p6) st8 [r2] = r32, 8 // save fn for child - st8 [r12] = r32 // save fn for parent - ;; -(p6) st8 [r2] = r35 // save arg for child - mov r32 = r34 // put flags in out0 - DO_CALL (SYS_ify (clone)) -1: - ld8 r33 = [r12], 8 // recover fn - ;; - ld8 r32 = [r12], 8 // recover arg - - cmp.eq p6,p0=-1,r10 -(p6) br.cond.spnt.many __syscall_error // handle error - - cmp.ne p7,p0=0,r8 -(p7) ret // parent process, just return - - cmp.eq p8,p0=0,r33 -(p8) ret // fork call, return - - alloc loc0 = ar.pfs,2,2,2,0 - ;; - ld8 r2 = [in1], 8 // get address of fn - mov out0 = in0 - mov loc1 = gp // save gp across indirect call - ;; - ld8 gp = [in1] // set new gp - mov b6 = r2 - br.call.sptk b0 = b6 // call thread routine - ;; - - mov ar.pfs = loc0 - mov gp = loc1 - mov r32 = r8 // exit value - ;; - br.call.sptk b0 = _exit // we're out of here - -PSEUDO_END(__clone) - -weak_alias (__clone, clone) +/* clone doesn't work on ia64. clone2 is ok. */ --- /dev/null Wed Aug 16 09:35:32 2000 +++ sysdeps/unix/sysv/linux/ia64/fork.S Wed Jul 12 18:35:04 2000 @@ -0,0 +1,44 @@ +/* Copyright (C) 2000 Free Software Foundation, Inc. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Library General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Library General Public License for more details. + + You should have received a copy of the GNU Library General Public + License along with the GNU C Library; see the file COPYING.LIB. If not, + write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, + Boston, MA 02111-1307, USA. */ + + +#include +#define _SIGNAL_H +#include + +/* pid_t fork(void); */ +/* Implemented as a clone system call with parameters SIGCHLD and 0 */ + +ENTRY(__libc_fork) + alloc r2=ar.pfs,0,0,2,0 + mov out0=SIGCHLD /* Return SIGCHLD when child finishes */ + /* no other clone flags; nothing shared */ + mov out1=0 /* Standard sp value. */ + ;; + flushrs /* For fork, it might suffice to flush */ + /* in the kernel, but for uniformity... */ + // DELETED STOP BITS - UNNECESSARY + DO_CALL (SYS_ify (clone)) + cmp.eq p6,p0=-1,r10 + ;; +(p6) br.cond.spnt.few __syscall_error + ret +PSEUDO_END(__libc_fork) + +weak_alias (__libc_fork, __fork) +weak_alias (__libc_fork, fork) + --- /dev/null Wed Aug 16 09:35:32 2000 +++ sysdeps/unix/sysv/linux/ia64/vfork.S Sat Jul 15 14:45:20 2000 @@ -0,0 +1,50 @@ +/* Copyright (C) 2000 Free Software Foundation, Inc. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Library General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Library General Public License for more details. + + You should have received a copy of the GNU Library General Public + License along with the GNU C Library; see the file COPYING.LIB. If not, + write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, + Boston, MA 02111-1307, USA. */ + + +#include +#define _SIGNAL_H +#include + +/* The following are defined in linux/sched.h, which unfortunately */ +/* is not safe for inclusion in an assembly file. */ +#define CLONE_VM 0x00000100 /* set if VM shared between processes */ +#define CLONE_VFORK 0x00004000 /* set if the parent wants the child to wake it up on mm_release */ + +/* pid_t vfork(void); */ +/* Implemented as __clone_syscall(CLONE_VFORK | CLONE_VM | SIGCHLD, 0) */ + +ENTRY(__vfork) + alloc r2=ar.pfs,0,0,2,0 + mov out0=CLONE_VM+CLONE_VFORK+SIGCHLD + mov out1=0 /* Standard sp value. */ + ;; + flushrs /* I don't think this is necessary */ + /* here either. Otherwise the child */ + /* may save additional registers, */ + /* which will become visible in the */ + /* parent. But that should be fine. */ + // DELETED STOP BITS - UNNECESSARY + DO_CALL (SYS_ify (clone)) + cmp.eq p6,p0=-1,r10 + ;; +(p6) br.cond.spnt.few __syscall_error + ret +PSEUDO_END(__vfork) + +weak_alias (__vfork, vfork) + From drepper@redhat.com Sat Sep 16 17:59:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Sat, 16 Sep 2000 17:59:00 -0000 Subject: elf/reldep3.c differs on ia32 and ia64 References: <20000916171403.A2706@valinux.com> Message-ID: "H . J . Lu" writes: > Jes, Ulrich, any ideas? Compare the output of DL_DEBUG=bindings and find out which ones are different. There must be some symbol visible which shouldn't be. I have no time to look at IA-64. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From hjl@valinux.com Sat Sep 16 23:01:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Sat, 16 Sep 2000 23:01:00 -0000 Subject: A long double patch for ia64. Message-ID: <20000916225109.A9666@valinux.com> Here is a long double patch for ia64. H.J. ---- 2000-09-16 H.J. Lu * sysdeps/ia64/Makefile (long-double-fcts): New. Defined as yes. * sysdeps/ia64/fpu/s_isinfl.c: New. Copied from sysdeps/i386/fpu. * sysdeps/ia64/fpu/s_isnanl.c: New. Copied from sysdeps/i386/fpu. * sysdeps/ia64/fpu/s_nextafterl.c: New. Copied from sysdeps/i386/fpu. * sysdeps/ia64/fpu/bits/mathdef.h: New. Copied from sysdeps/i386/fpu/bits/mathdef.h. Index: sysdeps/ia64/Makefile =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/ia64/Makefile,v retrieving revision 1.1.1.3 diff -u -p -r1.1.1.3 Makefile --- sysdeps/ia64/Makefile 2000/09/11 22:12:00 1.1.1.3 +++ sysdeps/ia64/Makefile 2000/09/17 03:42:57 @@ -1,3 +1,6 @@ +# The ia64 `long double' is a distinct type we support. +long-double-fcts = yes + ifeq ($(subdir), csu) CPPFLAGS-start.S = -D__ASSEMBLY__ endif --- /dev/null Wed Aug 16 09:35:32 2000 +++ sysdeps/ia64/fpu/s_isinfl.c Sat Sep 16 20:59:54 2000 @@ -0,0 +1,36 @@ +/* + * Written by J.T. Conklin . + * Change for long double by Ulrich Drepper . + * Intel ia64 specific version. + * Public domain. + */ + +#if defined(LIBM_SCCS) && !defined(lint) +static char rcsid[] = "$NetBSD: $"; +#endif + +/* + * isinfl(x) returns 1 if x is inf, -1 if x is -inf, else 0; + * no branching! + */ + +#include "math.h" +#include "math_private.h" + +#ifdef __STDC__ + int __isinfl(long double x) +#else + int __isinfl(x) + long double x; +#endif +{ + int32_t se,hx,lx; + GET_LDOUBLE_WORDS(se,hx,lx,x); + /* This additional ^ 0x80000000 is necessary because in Intel's + internal representation of the implicit one is explicit. */ + lx |= (hx ^ 0x80000000) | ((se & 0x7fff) ^ 0x7fff); + lx |= -lx; + se &= 0x8000; + return ~(lx >> 31) & (1 - (se >> 14)); +} +weak_alias (__isinfl, isinfl) --- /dev/null Wed Aug 16 09:35:32 2000 +++ sysdeps/ia64/fpu/s_isnanl.c Sat Sep 16 21:00:11 2000 @@ -0,0 +1,47 @@ +/* s_isnanl.c -- long double version for ia64 of s_isnan.c. + * Conversion to long double by Ulrich Drepper, + * Cygnus Support, drepper@cygnus.com. + */ + +/* + * ==================================================== + * Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved. + * + * Developed at SunPro, a Sun Microsystems, Inc. business. + * Permission to use, copy, modify, and distribute this + * software is freely granted, provided that this notice + * is preserved. + * ==================================================== + */ + +#if defined(LIBM_SCCS) && !defined(lint) +static char rcsid[] = "$NetBSD: $"; +#endif + +/* + * isnanl(x) returns 1 is x is nan, else 0; + * no branching! + */ + +#include "math.h" +#include "math_private.h" + +#ifdef __STDC__ + int __isnanl(long double x) +#else + int __isnanl(x) + long double x; +#endif +{ + int32_t se,hx,lx; + GET_LDOUBLE_WORDS(se,hx,lx,x); + se = (se & 0x7fff) << 1; + /* The additional & 0x7fffffff is required because Intel's + extended format has the normally implicit 1 explicit + present. Sigh! */ + lx |= hx & 0x7fffffff; + se |= (u_int32_t)(lx|(-lx))>>31; + se = 0xfffe - se; + return (int)((u_int32_t)(se))>>16; +} +weak_alias (__isnanl, isnanl) --- /dev/null Wed Aug 16 09:35:32 2000 +++ sysdeps/ia64/fpu/s_nextafterl.c Sat Sep 16 21:00:18 2000 @@ -0,0 +1,104 @@ +/* s_nextafterl.c -- long double version of s_nextafter.c. + * Special version for ia64. + * Conversion to long double by Ulrich Drepper, + * Cygnus Support, drepper@cygnus.com. + */ + +/* + * ==================================================== + * Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved. + * + * Developed at SunPro, a Sun Microsystems, Inc. business. + * Permission to use, copy, modify, and distribute this + * software is freely granted, provided that this notice + * is preserved. + * ==================================================== + */ + +#if defined(LIBM_SCCS) && !defined(lint) +static char rcsid[] = "$NetBSD: $"; +#endif + +/* IEEE functions + * nextafterl(x,y) + * return the next machine floating-point number of x in the + * direction toward y. + * Special cases: + */ + +#include "math.h" +#include "math_private.h" + +#ifdef __STDC__ + long double __nextafterl(long double x, long double y) +#else + long double __nextafterl(x,y) + long double x,y; +#endif +{ + int32_t hx,hy,ix,iy; + u_int32_t lx,ly,esx,esy; + + GET_LDOUBLE_WORDS(esx,hx,lx,x); + GET_LDOUBLE_WORDS(esy,hy,ly,y); + ix = esx&0x7fff; /* |x| */ + iy = esy&0x7fff; /* |y| */ + + /* The additional &hx/&hy is required because Intel's extended format + has the normally implicit 1 explicit present. Sigh! */ + if(((ix==0x7fff)&&(((hx|lx)|-(hx|lx))&hx)>>31!=0) || /* x is nan */ + ((iy==0x7fff)&&(((hy|ly)|-(hy|ly))&hy)>>31!=0)) /* y is nan */ + return x+y; + if(x==y) return y; /* x=y, return y */ + if((ix|hx|lx)==0) { /* x == 0 */ + SET_LDOUBLE_WORDS(x,esx&0x8000,0,1);/* return +-minsubnormal */ + y = x*x; + if(y==x) return y; else return x; /* raise underflow flag */ + } + if(esx<0x8000) { /* x > 0 */ + if(ix>iy||((ix==iy) && (hx>hy||((hx==hy)&&(lx>ly))))) { + /* x > y, x -= ulp */ + if(lx==0) { + if (hx==0) esx -= 1; + hx -= 1; + } + lx -= 1; + } else { /* x < y, x += ulp */ + lx += 1; + if(lx==0) { + hx += 1; + if (hx==0) + esx += 1; + } + } + } else { /* x < 0 */ + if(esy>=0||(ix>iy||((ix==iy)&&(hx>hy||((hx==hy)&&(lx>ly)))))){ + /* x < y, x -= ulp */ + if(lx==0) { + if (hx==0) esx -= 1; + hx -= 1; + } + lx -= 1; + } else { /* x > y, x += ulp */ + lx += 1; + if(lx==0) { + hx += 1; + if (hx==0) esx += 1; + } + } + } + esy = esx&0x7fff; + if(esy==0x7fff) return x+x; /* overflow */ + if(esy==0) { /* underflow */ + y = x*x; + if(y!=x) { /* raise underflow flag */ + SET_LDOUBLE_WORDS(y,esx,hx,lx); + return y; + } + } + SET_LDOUBLE_WORDS(x,esx,hx,lx); + return x; +} +weak_alias (__nextafterl, nextafterl) +strong_alias (__nextafterl, __nexttowardl) +weak_alias (__nextafterl, nexttowardl) --- /dev/null Wed Aug 16 09:35:32 2000 +++ sysdeps/ia64/fpu/bits/mathdef.h Sat Sep 16 22:04:59 2000 @@ -0,0 +1,47 @@ +/* Copyright (C) 2000 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Library General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Library General Public License for more details. + + You should have received a copy of the GNU Library General Public + License along with the GNU C Library; see the file COPYING.LIB. If not, + write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, + Boston, MA 02111-1307, USA. */ + +#if !defined _MATH_H && !defined _COMPLEX_H +# error "Never use directly; include instead" +#endif + +#if defined __USE_ISOC99 && defined _MATH_H && !defined _MATH_H_MATHDEF +# define _MATH_H_MATHDEF 1 + +/* The ix87 FPUs evaluate all values in the 80 bit floating-point format + which is also available for the user as `long double'. Therefore we + define: */ +typedef long double float_t; /* `float' expressions are evaluated as + `long double'. */ +typedef long double double_t; /* `double' expressions are evaluated as + `long double'. */ + +/* Signal that both types are `long double'. */ +# define FLT_EVAL_METHOD 2 + +/* Define `INFINITY' as value of type `float'. */ +# define INFINITY HUGE_VALF + +/* The values returned by `ilogb' for 0 and NaN respectively. */ +# define FP_ILOGB0 (-2147483647 - 1) +# define FP_ILOGBNAN (-2147483647 - 1) + +/* Number of decimal digits for the `long double' type. */ +# define DECIMAL_DIG 18 + +#endif /* ISO C99 */ From drepper@redhat.com Sat Sep 16 23:30:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Sat, 16 Sep 2000 23:30:00 -0000 Subject: A long double patch for ia64. References: <20000916225109.A9666@valinux.com> Message-ID: "H . J . Lu" writes: > * sysdeps/ia64/fpu/s_isinfl.c: New. Copied from > sysdeps/i386/fpu. > > * sysdeps/ia64/fpu/s_isnanl.c: New. Copied from > sysdeps/i386/fpu. > > * sysdeps/ia64/fpu/s_nextafterl.c: New. Copied from > sysdeps/i386/fpu. > > * sysdeps/ia64/fpu/bits/mathdef.h: New. Copied from > sysdeps/i386/fpu/bits/mathdef.h. If these files are identical they should be simple #includes and not be copied. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From hjl@lucon.org Sat Sep 16 23:35:00 2000 From: hjl@lucon.org (H . J . Lu) Date: Sat, 16 Sep 2000 23:35:00 -0000 Subject: A long double patch for ia64. References: <20000916225109.A9666@valinux.com> Message-ID: <20000916233454.A14218@lucon.org> On Sat, Sep 16, 2000 at 11:20:22PM -0700, Ulrich Drepper wrote: > "H . J . Lu" writes: > > > * sysdeps/ia64/fpu/s_isinfl.c: New. Copied from > > sysdeps/i386/fpu. > > > > * sysdeps/ia64/fpu/s_isnanl.c: New. Copied from > > sysdeps/i386/fpu. > > > > * sysdeps/ia64/fpu/s_nextafterl.c: New. Copied from > > sysdeps/i386/fpu. I don't know for sure if they should be the same. Someone has to look up ia32 and ia64 floating point manuals. From my commone senses, 80bit long double on ia64 should be identical with ia32. > > > > * sysdeps/ia64/fpu/bits/mathdef.h: New. Copied from > > sysdeps/i386/fpu/bits/mathdef.h. > > If these files are identical they should be simple #includes and not > be copied. > I don't know if I can use #include in sysdeps/ia64/fpu/bits/mathdef.h since it is an installed header files. Please feel free to fix it right. Thanks. H.J. From drepper@redhat.com Sat Sep 16 23:50:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Sat, 16 Sep 2000 23:50:00 -0000 Subject: A long double patch for ia64. References: <20000916225109.A9666@valinux.com> <20000916233454.A14218@lucon.org> Message-ID: "H . J . Lu" writes: > I don't know if I can use #include in sysdeps/ia64/fpu/bits/mathdef.h > since it is an installed header files. The other files are not installed. > Please feel free to fix it right. I already said, I have no time for IA-64. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From hjl@valinux.com Sun Sep 17 00:02:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Sun, 17 Sep 2000 00:02:00 -0000 Subject: [ia64-tools] Re: A long double patch for ia64. References: <20000916225109.A9666@valinux.com> <20000916233454.A14218@lucon.org> Message-ID: <20000917000208.A11981@valinux.com> On Sat, Sep 16, 2000 at 11:50:24PM -0700, Ulrich Drepper wrote: > "H . J . Lu" writes: > > > I don't know if I can use #include in sysdeps/ia64/fpu/bits/mathdef.h > > since it is an installed header files. > > The other files are not installed. > > > Please feel free to fix it right. > > I already said, I have no time for IA-64. > Here is the new patch. H.J. --- 2000-09-17 H.J. Lu * sysdeps/ia64/Makefile (long-double-fcts): New. Defined as yes. * sysdeps/ia64/fpu/s_isinfl.c: New. Include sysdeps/i386/fpu/s_isinfl.c. * sysdeps/ia64/fpu/s_isnanl.c: New. Include sysdeps/i386/fpu/s_isnanl.c. * sysdeps/ia64/fpu/s_nextafterl.c: New. Include sysdeps/i386/fpu/s_nextafterl.c. * sysdeps/ia64/fpu/bits/mathdef.h: New. Copied from sysdeps/i386/fpu/bits/mathdef.h. Index: sysdeps/ia64/Makefile =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/ia64/Makefile,v retrieving revision 1.1.1.3 diff -u -p -r1.1.1.3 Makefile --- sysdeps/ia64/Makefile 2000/09/11 22:12:00 1.1.1.3 +++ sysdeps/ia64/Makefile 2000/09/17 03:42:57 @@ -1,3 +1,6 @@ +# The ia64 `long double' is a distinct type we support. +long-double-fcts = yes + ifeq ($(subdir), csu) CPPFLAGS-start.S = -D__ASSEMBLY__ endif --- /dev/null Wed Aug 16 09:35:32 2000 +++ sysdeps/ia64/fpu/bits/mathdef.h Sat Sep 16 22:04:59 2000 @@ -0,0 +1,47 @@ +/* Copyright (C) 2000 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Library General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Library General Public License for more details. + + You should have received a copy of the GNU Library General Public + License along with the GNU C Library; see the file COPYING.LIB. If not, + write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, + Boston, MA 02111-1307, USA. */ + +#if !defined _MATH_H && !defined _COMPLEX_H +# error "Never use directly; include instead" +#endif + +#if defined __USE_ISOC99 && defined _MATH_H && !defined _MATH_H_MATHDEF +# define _MATH_H_MATHDEF 1 + +/* The ix87 FPUs evaluate all values in the 80 bit floating-point format + which is also available for the user as `long double'. Therefore we + define: */ +typedef long double float_t; /* `float' expressions are evaluated as + `long double'. */ +typedef long double double_t; /* `double' expressions are evaluated as + `long double'. */ + +/* Signal that both types are `long double'. */ +# define FLT_EVAL_METHOD 2 + +/* Define `INFINITY' as value of type `float'. */ +# define INFINITY HUGE_VALF + +/* The values returned by `ilogb' for 0 and NaN respectively. */ +# define FP_ILOGB0 (-2147483647 - 1) +# define FP_ILOGBNAN (-2147483647 - 1) + +/* Number of decimal digits for the `long double' type. */ +# define DECIMAL_DIG 18 + +#endif /* ISO C99 */ --- /dev/null Wed Aug 16 09:35:32 2000 +++ sysdeps/ia64/fpu/s_isinfl.c Sat Sep 16 23:55:08 2000 @@ -0,0 +1 @@ +#include --- /dev/null Wed Aug 16 09:35:32 2000 +++ sysdeps/ia64/fpu/s_isnanl.c Sat Sep 16 23:55:34 2000 @@ -0,0 +1 @@ +#include --- /dev/null Wed Aug 16 09:35:32 2000 +++ sysdeps/ia64/fpu/s_nextafterl.c Sat Sep 16 23:55:53 2000 @@ -0,0 +1 @@ +#include From schwab@suse.de Sun Sep 17 07:49:00 2000 From: schwab@suse.de (Andreas Schwab) Date: Sun, 17 Sep 2000 07:49:00 -0000 Subject: A patch for catgets/Makefile References: <20000916161617.A915@valinux.com> Message-ID: <200009171449.e8HEnXE21834@hawking.suse.de> "H . J . Lu" writes: |> I know the error is ignored. But .... It should use $(make-target-directory). Andreas. -- Andreas Schwab "And now for something SuSE Labs completely different." Andreas.Schwab@suse.de SuSE GmbH, Schanz????ckerstr. 10, D-90443 N????rnberg From hjl@valinux.com Sun Sep 17 08:59:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Sun, 17 Sep 2000 08:59:00 -0000 Subject: A patch for catgets/Makefile References: <20000916161617.A915@valinux.com> <200009171449.e8HEnXE21834@hawking.suse.de> Message-ID: <20000917085907.A3205@valinux.com> On Sun, Sep 17, 2000 at 04:49:33PM +0200, Andreas Schwab wrote: > "H . J . Lu" writes: > > |> I know the error is ignored. But .... > > It should use $(make-target-directory). > Here is the new one. Thanks. -- H.J. Lu (hjl@gnu.org) -- 2000-09-17 H.J. Lu * catgets/Makefile ($(objpfx)de/libc.cat): Use $(make-target-directory) instead of mkdir. Index: catgets/Makefile =================================================================== RCS file: /work/cvs/gnu/glibc/catgets/Makefile,v retrieving revision 1.1.1.2 diff -u -p -r1.1.1.2 Makefile --- catgets/Makefile 2000/09/07 20:25:43 1.1.1.2 +++ catgets/Makefile 2000/09/17 15:57:56 @@ -55,7 +55,7 @@ tests: $(objpfx)de/libc.cat $(objpfx)tes $(objpfx)test1.cat: test1.msg $(objpfx)gencat $(built-program-cmd) -H $(objpfx)test1.h $@ $< $(objpfx)de/libc.cat: $(objpfx)de.msg $(objpfx)gencat - -mkdir $(objpfx)de + $(make-target-directory) $(built-program-cmd) $@ $< $(objpfx)tst-catgets.out: $(objpfx)de/libc.cat From aj@suse.de Mon Sep 18 23:44:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Mon, 18 Sep 2000 23:44:00 -0000 Subject: Problem with ldconfig Message-ID: Thorsten reported me a problem with ldconfig on Sparc64 systems - the output from 32bit ldconfig and from 64bit ldconfig are not the same, the tools/libs are not interoperable. The problem is the hwcap entry in struct file_entry_new - it was unsigned long. I'm using now uint64_t on all platforms as smallest common format. At the momement the struct is: struct file_entry_new { int flags; /* This is 1 for an ELF library. */ unsigned int key, value; /* String table indices. */ unsigned long hwcap; /* Hwcap entry. */ }; I like to use the following for file_entry_new: struct file_entry_new { int32_t flags; /* This is 1 for an ELF library. */ uint32_t key, value; /* String table indices. */ uint32_t __unused; /* Align next field always on 8 byte boundary. */ uint64_t hwcap; /* Hwcap entry. */ }; What do you think? Shall I go ahead and make a complete patch? Or do you prefer another solution. Btw. these changes will imply an increment of the ldconfig version number. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From drepper@redhat.com Mon Sep 18 23:50:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Mon, 18 Sep 2000 23:50:00 -0000 Subject: Problem with ldconfig References: Message-ID: Andreas Jaeger writes: > What do you think? Shall I go ahead and make a complete patch? Or do > you prefer another solution. > > Btw. these changes will imply an increment of the ldconfig version number. I don't consider the change as a problem as long as the libc5 compatibility is maintained. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From aj@suse.de Tue Sep 19 01:00:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Tue, 19 Sep 2000 01:00:00 -0000 Subject: Problem with ldconfig References: Message-ID: >>>>> Ulrich Drepper writes: > Andreas Jaeger writes: >> What do you think? Shall I go ahead and make a complete patch? Or do >> you prefer another solution. >> >> Btw. these changes will imply an increment of the ldconfig version number. > I don't consider the change as a problem as long as the libc5 > compatibility is maintained. I don't touch the libc5 part at all. Here's a patch that also changes cache_file_new. 64 bit experts, please check that all alignments are proper in the two structs - or do you like to see changes? Thorsten, please tell me whether this fixes the problems you noticed on sparc. Andreas 2000-09-19 Andreas Jaeger * sysdeps/generic/dl-cache.h: Include stdint.h. (struct file_entry_new): Use fixed sizes for interoperability between 32bit and 64bit systems, add __unused to make alignment explicit. (CACHE_VERSION): Increment. (struct cache_file_new): Use fixed sizes, add one more unused entry to make alignment explicit. ============================================================ Index: sysdeps/generic/dl-cache.h --- sysdeps/generic/dl-cache.h 2000/07/12 21:09:31 1.4 +++ sysdeps/generic/dl-cache.h 2000/09/19 07:41:01 @@ -17,6 +17,8 @@ write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ +#include + #ifndef _DL_CACHE_DEFAULT_ID # define _DL_CACHE_DEFAULT_ID 3 #endif @@ -66,25 +68,27 @@ }; #define CACHEMAGIC_NEW "glibc-ld.so.cache" -#define CACHE_VERSION "1.0" +#define CACHE_VERSION "1.1" struct file_entry_new { - int flags; /* This is 1 for an ELF library. */ - unsigned int key, value; /* String table indices. */ - unsigned long hwcap; /* Hwcap entry. */ + int32_t flags; /* This is 1 for an ELF library. */ + uint32_t key, value; /* String table indices. */ + uint32_t __unused; /* Align next field always on 8 byte boundary. */ + uint64_t hwcap; /* Hwcap entry. */ }; struct cache_file_new { char magic[sizeof CACHEMAGIC_NEW - 1]; char version[sizeof CACHE_VERSION - 1]; - unsigned int nlibs; /* Number of entries. */ - unsigned int len_strings; /* Size of string table. */ - unsigned int unused[4]; /* Leave space for future extensions. */ + uint32_t nlibs; /* Number of entries. */ + uint32_t len_strings; /* Size of string table. */ + uint32_t unused[5]; /* Leave space for future extensions + and align to 8 byte boundary. */ struct file_entry_new libs[0]; /* Entries describing libraries. */ - /* After this the string table of size len_strings is found. */ + /* After this the string table of size len_strings is found. */ }; /* Used to align cache_file_new. */ -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From aj@suse.de Tue Sep 19 06:09:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Tue, 19 Sep 2000 06:09:00 -0000 Subject: Update for FAQ.in: S390/MIPS Message-ID: I'd like to add the following patch to the FAQ. Is this ok? Andreas ============================================================ Index: FAQ.in --- FAQ.in 2000/08/09 07:10:58 1.105 +++ FAQ.in 2000/09/19 13:07:45 @@ -37,6 +37,7 @@ arm-*-linuxaout Linux-2.x on ARM using a.out binaries mips*-*-linux-gnu Linux-2.x on MIPS ia64-*-linux-gnu Linux-2.x on ia64 + s390-*-linux-gnu Linux-2.x on IBM S/390 Ports to other Linux platforms are in development, and may in fact work already, but no one has sent us success reports for them. Currently no @@ -63,7 +64,7 @@ You should always try to use the latest official release. Older versions may not have all the features GNU libc requires. The current releases of egcs (1.0.3 and 1.1.1) should work with the GNU C library (for powerpc see -?powerpc; for ARM see ?arm). +?powerpc; for ARM see ?arm; for MIPS see ?mips). While the GNU CC should be able to compile glibc it is nevertheless adviced to use EGCS. Comparing the sizes of glibc on Intel compiled with a recent @@ -380,6 +381,17 @@ directories. I strongly advise to upgrade your make version to 3.79 or newer. + +??mips Which tools should I use for MIPS? + +{AJ} Either use as compiler egcs 1.1.2 or the current development version of +gcc 2.96 from CVS. gcc 2.95.x does not work correctly on mips-linux. + +You need recent binutils, anything before and including 2.10 will not work +correctly. Either try the Linux binutils 2.10.0.26 from HJ Lu or the +current development version of binutils. + +For details check also my page < http://www.suse.de/~aj/glibc-mips.html >. ? Installation and configuration issues -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From hjl@valinux.com Tue Sep 19 11:52:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Tue, 19 Sep 2000 11:52:00 -0000 Subject: A patch for malloc typo Message-ID: <20000919115233.A10665@valinux.com> The order of parameters passed to mEMALIGn in memalign_hook_ini is wrong. Here is a patch. -- H.J. Lu (hjl@gnu.org) --- 2000-09-19 H.J. Lu * malloc/malloc.c (memalign_hook_ini): Fix the mEMALIGn call. Index: malloc/malloc.c =================================================================== RCS file: /work/cvs/gnu/glibc/malloc/malloc.c,v retrieving revision 1.1.1.9 diff -u -p -r1.1.1.9 malloc.c --- malloc/malloc.c 2000/08/31 16:48:37 1.1.1.9 +++ malloc/malloc.c 2000/09/19 18:50:18 @@ -1780,7 +1780,7 @@ memalign_hook_ini(sz, alignment, caller) { __memalign_hook = NULL; ptmalloc_init(); - return mEMALIGn(sz, alignment); + return mEMALIGn(alignment, sz); } void weak_variable (*__malloc_initialize_hook) __MALLOC_P ((void)) = NULL; From hjl@lucon.org Tue Sep 19 12:03:00 2000 From: hjl@lucon.org (H . J . Lu) Date: Tue, 19 Sep 2000 12:03:00 -0000 Subject: A patch for malloc typo References: <20000919115233.A10665@valinux.com> Message-ID: <20000919120252.A26643@lucon.org> On Tue, Sep 19, 2000 at 11:52:33AM -0700, H . J . Lu wrote: > The order of parameters passed to mEMALIGn in memalign_hook_ini is > wrong. Here is a patch. > > -- > H.J. Lu (hjl@gnu.org) > --- > 2000-09-19 H.J. Lu > > * malloc/malloc.c (memalign_hook_ini): Fix the mEMALIGn call. > > Index: malloc/malloc.c > =================================================================== > RCS file: /work/cvs/gnu/glibc/malloc/malloc.c,v > retrieving revision 1.1.1.9 > diff -u -p -r1.1.1.9 malloc.c > --- malloc/malloc.c 2000/08/31 16:48:37 1.1.1.9 > +++ malloc/malloc.c 2000/09/19 18:50:18 > @@ -1780,7 +1780,7 @@ memalign_hook_ini(sz, alignment, caller) > { > __memalign_hook = NULL; > ptmalloc_init(); > - return mEMALIGn(sz, alignment); > + return mEMALIGn(alignment, sz); > } > > void weak_variable (*__malloc_initialize_hook) __MALLOC_P ((void)) = NULL; Well, this patch is not right since memalign_hook_ini () has everything reversed. The code is ok. It is just that alignment and sz are very misleading. I will send a patch to fix everything. H.J. From hjl@valinux.com Tue Sep 19 12:55:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Tue, 19 Sep 2000 12:55:00 -0000 Subject: A patch for malloc typo References: <20000919115233.A10665@valinux.com> Message-ID: <20000919125509.A29516@valinux.com> On Tue, Sep 19, 2000 at 11:52:33AM -0700, H . J . Lu wrote: > The order of parameters passed to mEMALIGn in memalign_hook_ini is > wrong. Here is a patch. > This patch should have no impact on generated binaries. It just makes the code less confusing. H.J. --- 2000-09-19 H.J. Lu * malloc/malloc.h (__memalign_hook): Fix the parameter order. * malloc/malloc.c (__memalign_hook): Likewise. (memalign_hook_ini): Likewise. Index: malloc/malloc.c =================================================================== RCS file: /work/cvs/gnu/glibc/malloc/malloc.c,v retrieving revision 1.1.1.9 diff -u -p -r1.1.1.9 malloc.c --- malloc/malloc.c 2000/08/31 16:48:37 1.1.1.9 +++ malloc/malloc.c 2000/09/19 19:05:49 @@ -1772,15 +1772,15 @@ realloc_hook_ini(ptr, sz, caller) static Void_t* #if __STD_C -memalign_hook_ini(size_t sz, size_t alignment, const __malloc_ptr_t caller) +memalign_hook_ini(size_t alignment, size_t sz, const __malloc_ptr_t caller) #else -memalign_hook_ini(sz, alignment, caller) - size_t sz; size_t alignment; const __malloc_ptr_t caller; +memalign_hook_ini(alignment, sz, caller) + size_t alignment; size_t sz; const __malloc_ptr_t caller; #endif { __memalign_hook = NULL; ptmalloc_init(); - return mEMALIGn(sz, alignment); + return mEMALIGn(alignment, sz); } void weak_variable (*__malloc_initialize_hook) __MALLOC_P ((void)) = NULL; @@ -1792,7 +1792,7 @@ __malloc_ptr_t weak_variable (*__realloc __MALLOC_P ((__malloc_ptr_t __ptr, size_t __size, const __malloc_ptr_t)) = realloc_hook_ini; __malloc_ptr_t weak_variable (*__memalign_hook) - __MALLOC_P ((size_t __size, size_t __alignment, const __malloc_ptr_t)) + __MALLOC_P ((size_t __alignment, size_t __size, const __malloc_ptr_t)) = memalign_hook_ini; void weak_variable (*__after_morecore_hook) __MALLOC_P ((void)) = NULL; Index: malloc/malloc.h =================================================================== RCS file: /work/cvs/gnu/glibc/malloc/malloc.h,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 malloc.h --- malloc/malloc.h 2000/05/21 21:11:15 1.1.1.1 +++ malloc/malloc.h 2000/09/19 19:03:41 @@ -225,8 +225,8 @@ extern __malloc_ptr_t (*__malloc_hook) _ extern __malloc_ptr_t (*__realloc_hook) __MALLOC_PMT ((__malloc_ptr_t __ptr, size_t __size, __const __malloc_ptr_t)); -extern __malloc_ptr_t (*__memalign_hook) __MALLOC_PMT ((size_t __size, - size_t __alignment, +extern __malloc_ptr_t (*__memalign_hook) __MALLOC_PMT ((size_t __alignment, + size_t __size, __const __malloc_ptr_t)); extern void (*__after_morecore_hook) __MALLOC_PMT ((void)); From aj@suse.de Wed Sep 20 01:32:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Wed, 20 Sep 2000 01:32:00 -0000 Subject: Patch for make clean Message-ID: make clean missed some files, here's a patch. I've installed it already, Andreas 2000-09-20 Andreas Jaeger * iconvdata/Makefile (generated): Add tst-tables.out. * intl/Makefile (generated): Add test output. ============================================================ Index: iconvdata/Makefile --- iconvdata/Makefile 2000/09/13 09:08:16 1.83 +++ iconvdata/Makefile 2000/09/20 08:23:52 @@ -178,7 +178,8 @@ $(gen-special-modules) generated = $(generated-modules:=.h) $(generated-modules:=.stmp) \ - iconv-test.out iconv-rules tst-loading.mtrace mtrace-tst-loading + iconv-test.out iconv-rules tst-loading.mtrace \ + mtrace-tst-loading tst-tables.out ifdef objpfx generated += gconv-modules endif ============================================================ Index: intl/Makefile --- intl/Makefile 2000/09/14 23:30:51 1.32 +++ intl/Makefile 2000/09/20 08:23:52 @@ -34,7 +34,7 @@ install-others = $(inst_msgcatdir)/locale.alias -generated = msgs.h +generated = msgs.h mtrace-tst-gettext tst-gettext.mtrace generated-dirs := domaindir plural.c: plural.y -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From wmglo@dent.med.uni-muenchen.de Wed Sep 20 01:40:00 2000 From: wmglo@dent.med.uni-muenchen.de (Wolfram Gloger) Date: Wed, 20 Sep 2000 01:40:00 -0000 Subject: A patch for malloc typo References: <20000919115233.A10665@valinux.com> <20000919125509.A29516@valinux.com> Message-ID: <20000920084028.25212.qmail@md.dent.med.uni-muenchen.de> > This patch should have no impact on generated binaries. It just makes > the code less confusing. Yes, this patch is fine. Thanks, Wolfram. From bmark@us.ibm.com Wed Sep 20 09:15:00 2000 From: bmark@us.ibm.com (Mark Brown) Date: Wed, 20 Sep 2000 09:15:00 -0000 Subject: reopening fprintf I18N issue Message-ID: <39C8E240.A9E39DD4@us.ibm.com> U- Gary Miller and I have been going over the issue you present in http://www.cygnus.com/~drepper/printf.html We believe that you have misinterpreted the ISO C specification in one place (fprintf) and are understandably upset over the muddled definition for fwprintf(), which will require Austin Group work to straighten out. [For the record, Gary's first response (that glibc is currently correct and the test suite was wrong) was based on a misreading of the question you asked). On to the case: > This is the result of a run of runtest.sh in the printf subdir with the > ja_JP.eucJP locale. You have to use the most recent CVS version of glibc > to reproduce it. Please let me comment on the failures reported and > explain why I think these are errors in the test suite. > > [ OK ] printf(???%s???,??) sys[????????] = exp[????????] > ...[cut].... > [FAIL] printf([%-6.1s],??????) > sys[[]] != exp[[]] > > The outputs agree that nothing from the input string is printed since this > would mean printing an incomplete character. But the expected result is not > providing what the format specifier says: a string padded to length 6. > Note that the ISO C standard is talking about characters, which is wrong and > dangerous. The rational is clarifying this by saying these are byte counts. This is an incorrect interpretation. The printf() class of functions is always _byte_based_; a char is a byte in ISO C. Note that there is no "l" (ell) qualifier present (SUSv2), thus the argument to %s is to be a pointer to an array of char (ISO C) -- this is because it is going to be treated as bytes. Note the "if precision....that many bytes are written" sentence. As to what is going on in the test results, let me add something: [FAIL] printf([%-6.1s],??????) sys[[]] != exp[[]] ^ There should be an undisplayable single byte here if you look at the actual output! Thus, 6 bytes are indeed output, fulfilling the precision and the requirements of ISO C. The test suite should be expecting the single byte, if written properly. > [ OK ] printf([%-6.2s],??????) > sys[[?]] = exp[[?]] > [FAIL] printf([%-6.3s],??????) > sys[[?]] != exp[[?]] ^ a single byte here as well. etc. Now, onward to the swprintf() issue. Gary thinks the spec here is horribly muddled, and that both the test and glibc are doing the wrong thing. We are going to submit an aardvark to Austin Group on this. For what it is worth, glibc is closer the Gary's expected behavior. Mark Brown -- Mark S. Brown bmark@us.ibm.com Senior Technical Staff Member 512.838.3926 T/L678.3926 IBM RS/6000 AIX System Architecture Mark Brown/Austin/IBM IBM Corporation, Austin, Texas From greg@mcgary.org Wed Sep 20 17:20:00 2000 From: greg@mcgary.org (Greg McGary) Date: Wed, 20 Sep 2000 17:20:00 -0000 Subject: data aliases? Message-ID: <200009210020.RAA00718@kayak.mcgary.org> Is anyone aware of uses of strong_alias() or weak_alias() for data names in glibc? A cursory look reveals that the overwhelming majority of such aliases are for functions. Before I spend more time looking closer, I wanted to know if anyone knew the answer off the top of his/her head. Thanks, Greg From hjl@lucon.org Wed Sep 20 17:26:00 2000 From: hjl@lucon.org (H . J . Lu) Date: Wed, 20 Sep 2000 17:26:00 -0000 Subject: data aliases? References: <200009210020.RAA00718@kayak.mcgary.org> Message-ID: <20000920172623.A3857@lucon.org> On Wed, Sep 20, 2000 at 05:20:28PM -0700, Greg McGary wrote: > Is anyone aware of uses of strong_alias() or weak_alias() for data > names in glibc? A cursory look reveals that the overwhelming majority sysdeps/unix/sysv/linux/errlist.c H.J. From hjl@valinux.com Wed Sep 20 19:23:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Wed, 20 Sep 2000 19:23:00 -0000 Subject: ia64 fenv patch. Message-ID: <20000920190828.A11605@valinux.com> The ia64 fenv functions seem wrong to me. Here is a patch. With this patch, I got only make[2]: *** [/home/work/build/glibc/math/test-float.out] Error 1 make[2]: *** [/home/work/build/glibc/math/test-double.out] Error 1 make[2]: *** [/home/work/build/glibc/math/test-ldouble.out] Error 134 make[2]: *** [/home/work/build/glibc/math/test-ildoubl.out] Error 134 make[2]: *** [/home/work/build/glibc/math/test-ifloat.out] Error 1 make[2]: *** [/home/work/build/glibc/math/test-idouble.out] Error 1 in "make check". Thanks. H.J. ---- 2000-09-20 H.J. Lu * sysdeps/ia64/fpu/fclrexcpt.c (feclearexcept): Use fexcept_t instead of fenv_t. * sysdeps/ia64/fpu/fedisblxcpt.c (fedisableexcept): Fix the logic. * sysdeps/ia64/fpu/feenablxcpt.c (feenableexcept): Likewise. * sysdeps/ia64/fpu/fegetexcept.c (fegetexcept): Likewise. * sysdeps/ia64/fpu/fgetexcptflg.c (fegetexceptflag): Likewise. * sysdeps/ia64/fpu/fsetexcptflg.c (fesetexceptflag): Likewise. * sysdeps/ia64/fpu/fesetenv.c (fesetenv): Use fenv_t instead of unsigned long int. * sysdeps/ia64/fpu/fesetround.c (fesetround): Likewise. Index: sysdeps/ia64/fpu/fclrexcpt.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/ia64/fpu/fclrexcpt.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 fclrexcpt.c --- sysdeps/ia64/fpu/fclrexcpt.c 2000/05/21 21:12:03 1.1.1.1 +++ sysdeps/ia64/fpu/fclrexcpt.c 2000/09/21 01:51:20 @@ -24,13 +24,13 @@ int feclearexcept (int excepts) { - fenv_t fpsr; + fexcept_t fpsr; /* Get the current state. */ __asm__ __volatile__ ("mov.m %0=ar.fpsr" : "=r" (fpsr)); /* Clear the relevant bits. */ - fpsr &= ~(((unsigned long int) ((excepts & FE_ALL_EXCEPT) << 13))); + fpsr &= ~(((fexcept_t) ((excepts & FE_ALL_EXCEPT) << 13))); /* Put the new state in effect. */ __asm__ __volatile__ ("mov.m ar.fpsr=%0" :: "r" (fpsr) : "memory"); Index: sysdeps/ia64/fpu/fedisblxcpt.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/ia64/fpu/fedisblxcpt.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 fedisblxcpt.c --- sysdeps/ia64/fpu/fedisblxcpt.c 2000/05/21 21:12:03 1.1.1.1 +++ sysdeps/ia64/fpu/fedisblxcpt.c 2000/09/21 01:23:01 @@ -27,11 +27,13 @@ fedisableexcept (int excepts) fenv_t new_fpsr; /* Get the current fpsr. */ - __asm__ __volatile__ ("mov.m %0=ar.fpsr" : "=r" (old_fpsr)); + __asm__ __volatile__ ("mov.m %0=ar.fpsr" : "=r" (new_fpsr)); - new_fpsr = old_fpsr |= FE_ALL_EXCEPT; + excepts &= FE_ALL_EXCEPT; + old_fpsr = (~new_fpsr) & FE_ALL_EXCEPT; + new_fpsr |= (fenv_t) excepts; __asm__ __volatile__ ("mov.m ar.fpsr=%0" :: "r" (new_fpsr) : "memory"); - return (old_fpsr ^ FE_ALL_EXCEPT) & FE_ALL_EXCEPT; + return old_fpsr; } Index: sysdeps/ia64/fpu/feenablxcpt.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/ia64/fpu/feenablxcpt.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 feenablxcpt.c --- sysdeps/ia64/fpu/feenablxcpt.c 2000/05/21 21:12:03 1.1.1.1 +++ sysdeps/ia64/fpu/feenablxcpt.c 2000/09/21 01:21:48 @@ -27,12 +27,13 @@ feenableexcept (int excepts) fenv_t new_fpsr; /* Get the current fpsr. */ - __asm__ __volatile__ ("mov.m %0=ar.fpsr" : "=r " (old_fpsr)); + __asm__ __volatile__ ("mov.m %0=ar.fpsr" : "=r " (new_fpsr)); - new_fpsr = ((old_fpsr & FE_ALL_EXCEPT) - | (old_fpsr & ((unsigned long int) excepts ^ FE_ALL_EXCEPT))); + excepts &= FE_ALL_EXCEPT; + old_fpsr = (~new_fpsr) & FE_ALL_EXCEPT; + new_fpsr &= ~((fenv_t) excepts); __asm__ __volatile__ ("mov.m ar.fpsr=%0" :: "r" (new_fpsr) : "memory"); - return (old_fpsr ^ FE_ALL_EXCEPT) & FE_ALL_EXCEPT; + return old_fpsr; } Index: sysdeps/ia64/fpu/fegetexcept.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/ia64/fpu/fegetexcept.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 fegetexcept.c --- sysdeps/ia64/fpu/fegetexcept.c 2000/05/21 21:12:03 1.1.1.1 +++ sysdeps/ia64/fpu/fegetexcept.c 2000/09/21 01:27:21 @@ -27,5 +27,5 @@ fegetexcept (void) __asm__ __volatile__ ("mov.m %0=ar.fpsr" : "=r" (fpsr)); - return (fpsr ^ FE_ALL_EXCEPT) & FE_ALL_EXCEPT; + return (~fpsr) & FE_ALL_EXCEPT; } Index: sysdeps/ia64/fpu/fesetenv.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/ia64/fpu/fesetenv.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 fesetenv.c --- sysdeps/ia64/fpu/fesetenv.c 2000/05/21 21:12:03 1.1.1.1 +++ sysdeps/ia64/fpu/fesetenv.c 2000/09/21 01:28:22 @@ -30,8 +30,8 @@ fesetenv (const fenv_t *envp) Magic encoding of default values: bit 62+63 set (which will never happen for a user-space address) means it's not indirect. */ - if (((unsigned long int) envp >> 62) == 0x03) - env = (unsigned long int) envp & 0x3fffffffffffffff; + if (((fenv_t) envp >> 62) == 0x03) + env = (fenv_t) envp & 0x3fffffffffffffff; else env = *envp; Index: sysdeps/ia64/fpu/fesetround.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/ia64/fpu/fesetround.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 fesetround.c --- sysdeps/ia64/fpu/fesetround.c 2000/05/21 21:12:03 1.1.1.1 +++ sysdeps/ia64/fpu/fesetround.c 2000/09/21 01:29:11 @@ -23,7 +23,7 @@ int fesetround (int round) { - unsigned long int fpsr; + fenv_t fpsr; if (round & ~3) return 0; @@ -32,7 +32,7 @@ fesetround (int round) __asm__ __volatile__ ("mov.m %0=ar.fpsr" : "=r" (fpsr)); /* Set the relevant bits. */ - fpsr = (fpsr & ~(3UL << 10)) | ((unsigned long int) round << 10); + fpsr = (fpsr & ~(3UL << 10)) | ((fenv_t) round << 10); /* Put the new state in effect. */ __asm__ __volatile__ ("mov.m ar.fpsr=%0" :: "r" (fpsr) : "memory"); Index: sysdeps/ia64/fpu/fgetexcptflg.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/ia64/fpu/fgetexcptflg.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 fgetexcptflg.c --- sysdeps/ia64/fpu/fgetexcptflg.c 2000/05/21 21:12:03 1.1.1.1 +++ sysdeps/ia64/fpu/fgetexcptflg.c 2000/09/21 01:52:14 @@ -23,12 +23,12 @@ int fegetexceptflag (fexcept_t *flagp, int excepts) { - fenv_t fpsr; + fexcept_t fpsr; /* Get the current exceptions. */ __asm__ __volatile__ ("mov.m %0=ar.fpsr" : "=r" (fpsr)); - *flagp = (fpsr ^ FE_ALL_EXCEPT) & excepts & FE_ALL_EXCEPT; + *flagp = (fpsr >> 13) & excepts & FE_ALL_EXCEPT; /* Success. */ return 0; Index: sysdeps/ia64/fpu/fsetexcptflg.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/ia64/fpu/fsetexcptflg.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 fsetexcptflg.c --- sysdeps/ia64/fpu/fsetexcptflg.c 2000/05/21 21:12:03 1.1.1.1 +++ sysdeps/ia64/fpu/fsetexcptflg.c 2000/09/21 01:57:25 @@ -31,10 +31,10 @@ fesetexceptflag (const fexcept_t *flagp, /* Get the reverse bits so we can enable the exceptions flagged rather than disable them. */ - excepts ^= FE_ALL_EXCEPT; + fpsr &= ~(excepts & FE_ALL_EXCEPT); /* Set all the bits that were called for. */ - fpsr = (fpsr & ~FE_ALL_EXCEPT) | (*flagp & excepts & FE_ALL_EXCEPT); + fpsr |= *flagp & excepts & FE_ALL_EXCEPT; /* And store it back. */ __asm__ __volatile__ ("mov.m ar.fpsr=%0" :: "r" (fpsr) : "memory"); From hjl@valinux.com Wed Sep 20 23:49:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Wed, 20 Sep 2000 23:49:00 -0000 Subject: A glibc ia64 patch for math Message-ID: <20000920234252.A20940@valinux.com> With this patch, I only got make[2]: *** [/home/work/build/glibc/math/test-ldouble.out] Error 1 make[2]: *** [/home/work/build/glibc/math/test-ildoubl.out] Error 1 for "make check" on ia64. Those long double functions are not implemented. I assume we will get them in libm from Intel. With all my ia64 patches applied, glibc 2.2 is in very good shape under ia64 now. H.J. --- 2000-09-20 H.J. Lu * sysdeps/ia64/fpu/printf_fphex.c: New. * sysdeps/ia64/fpu/libm-test-ulps: New. --- /dev/null Thu Aug 24 02:00:32 2000 +++ sysdeps/ia64/fpu/printf_fphex.c Wed Sep 20 23:07:35 2000 @@ -0,0 +1,80 @@ +/* Print floating point number in hexadecimal notation according to ISO C99. + Copyright (C) 2000 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Library General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Library General Public License for more details. + + You should have received a copy of the GNU Library General Public + License along with the GNU C Library; see the file COPYING.LIB. If not, + write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, + Boston, MA 02111-1307, USA. */ + +#ifndef LONG_DOUBLE_DENORM_BIAS +# define LONG_DOUBLE_DENORM_BIAS (IEEE854_LONG_DOUBLE_BIAS - 1) +#endif + +#define PRINT_FPHEX_LONG_DOUBLE \ +do { \ + /* The "strange" 80 bit format on ia64 has an explicit \ + leading digit in the 64 bit mantissa. */ \ + unsigned long long int num; \ + \ + num = (((unsigned long long int) fpnum.ldbl.ieee.mantissa0) << 32 \ + | fpnum.ldbl.ieee.mantissa1); \ + \ + zero_mantissa = num == 0; \ + \ + numstr = _itoa_word (num, numbuf + sizeof numbuf, 16, \ + info->spec == 'A'); \ + wnumstr = _itowa_word (num, wnumbuf + sizeof wnumbuf, 16, \ + info->spec == 'A'); \ + \ + /* Fill with zeroes. */ \ + while (numstr > numbuf + (sizeof numbuf - 64 / 4)) \ + { \ + *--numstr = '0'; \ + *--wnumstr = L'0'; \ + } \ + \ + /* We use a full nibble for the leading digit. */ \ + leading = *numstr++; \ + \ + /* We have 3 bits from the mantissa in the leading nibble. \ + Therefore we are here using `IEEE854_LONG_DOUBLE_BIAS + 3'. */ \ + exponent = fpnum.ldbl.ieee.exponent; \ + \ + if (exponent == 0) \ + { \ + if (zero_mantissa) \ + expnegative = 0; \ + else \ + { \ + /* This is a denormalized number. */ \ + expnegative = 1; \ + /* This is a hook for the m68k long double format, where the \ + exponent bias is the same for normalized and denormalized \ + numbers. */ \ + exponent = LONG_DOUBLE_DENORM_BIAS + 3; \ + } \ + } \ + else if (exponent >= IEEE854_LONG_DOUBLE_BIAS + 3) \ + { \ + expnegative = 0; \ + exponent -= IEEE854_LONG_DOUBLE_BIAS + 3; \ + } \ + else \ + { \ + expnegative = 1; \ + exponent = -(exponent - (IEEE854_LONG_DOUBLE_BIAS + 3)); \ + } \ +} while (0) + +#include --- /dev/null Thu Aug 24 02:00:32 2000 +++ sysdeps/ia64/fpu/libm-test-ulps Wed Sep 20 23:23:49 2000 @@ -0,0 +1,1652 @@ +# Begin of automatic generation + +# acos +Test "acos (0.7) == 0.7953988301841435554": +float: 1 +ifloat: 1 +ildouble: 1150 +ldouble: 1150 + +# acosh +Test "acosh (7) == 2.6339157938496334172": +ldouble: 1 +ildouble: 1 + +# asin +Test "asin (-0.5) == -pi/6": +float: 2 +ifloat: 2 +Test "asin (0.5) == pi/6": +float: 2 +ifloat: 2 +Test "asin (0.7) == 0.7753974966107530637": +float: 2 +ifloat: 2 +double: 1 +idouble: 1 +ildouble: 1147 +ldouble: 1147 + +# asinh +Test "asinh (0.7) == 0.652666566082355786": +ildouble: 656 +ldouble: 656 + +# atan +Test "atan (0.7) == 0.6107259643892086165": +ildouble: 549 +ldouble: 549 + +# atan2 +Test "atan2 (0.4, 0.0003) == 1.5700463269355215718": +ildouble: 1 +ldouble: 1 +Test "atan2 (0.7, 1) == 0.6107259643892086165": +ildouble: 549 +ldouble: 549 + +# atanh +Test "atanh (0.7) == 0.8673005276940531944": +double: 1 +idouble: 1 +ildouble: 1605 +ldouble: 1605 + +# cabs +Test "cabs (-0.7 + 12.4 i) == 12.41974234837422060118": +float: 1 +ifloat: 1 +Test "cabs (-0.7 - 12.4 i) == 12.41974234837422060118": +float: 1 +ifloat: 1 +Test "cabs (-12.4 + 0.7 i) == 12.41974234837422060118": +float: 1 +ifloat: 1 +Test "cabs (-12.4 - 0.7 i) == 12.41974234837422060118": +float: 1 +ifloat: 1 +Test "cabs (0.7 + 1.2 i) == 1.3892443989449804508": +double: 1 +idouble: 1 +ildouble: 560 +ldouble: 560 +Test "cabs (0.7 + 12.4 i) == 12.41974234837422060118": +float: 1 +ifloat: 1 + +# cacos +Test "Real part of: cacos (-2 - 3 i) == 2.1414491111159960199 + 1.9833870299165354323 i": +Test "Imaginary part of: cacos (-2 - 3 i) == 2.1414491111159960199 + 1.9833870299165354323 i": +ildouble: 1 +ldouble: 1 +Test "Real part of: cacos (0.7 + 1.2 i) == 1.1351827477151551089 - 1.0927647857577371459 i": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +ildouble: 151 +ldouble: 151 +Test "Imaginary part of: cacos (0.7 + 1.2 i) == 1.1351827477151551089 - 1.0927647857577371459 i": +float: 2 +ifloat: 2 +ildouble: 329 +ldouble: 329 + +# cacosh +Test "Real part of: cacosh (-2 - 3 i) == -1.9833870299165354323 + 2.1414491111159960199 i": +double: 1 +float: 7 +idouble: 1 +ifloat: 7 +ildouble: 5 +ldouble: 5 +Test "Imaginary part of: cacosh (-2 - 3 i) == -1.9833870299165354323 + 2.1414491111159960199 i": +double: 1 +float: 4 +idouble: 1 +ifloat: 4 +ildouble: 1 +ldouble: 1 +Test "Real part of: cacosh (0.7 + 1.2 i) == 1.0927647857577371459 + 1.1351827477151551089 i": +float: 1 +ifloat: 1 +double: 1 +idouble: 1 +ildouble: 328 +ldouble: 328 +Test "Imaginary part of: cacosh (0.7 + 1.2 i) == 1.0927647857577371459 + 1.1351827477151551089 i": +ildouble: 151 +ldouble: 151 + +# casin +Test "Real part of: casin (-2 - 3 i) == -0.5706527843210994007 - 1.9833870299165354323 i": +Test "Imaginary part of: casin (-2 - 3 i) == -0.5706527843210994007 - 1.9833870299165354323 i": +ildouble: 1 +ldouble: 1 +Test "Real part of: casin (0.7 + 1.2 i) == 0.4356135790797415103 + 1.0927647857577371459 i": +double: 3 +float: 2 +idouble: 3 +ifloat: 2 +ildouble: 603 +ldouble: 603 +Test "Imaginary part of: casin (0.7 + 1.2 i) == 0.4356135790797415103 + 1.0927647857577371459 i": +float: 2 +ifloat: 2 +ildouble: 329 +ldouble: 329 + +# casinh +Test "Real part of: casinh (-2 - 3 i) == -1.9686379257930962917 - 0.9646585044076027920 i": +double: 5 +float: 1 +idouble: 5 +ifloat: 1 +ildouble: 6 +ldouble: 6 +Test "Imaginary part of: casinh (-2 - 3 i) == -1.9686379257930962917 - 0.9646585044076027920 i": +double: 3 +float: 6 +idouble: 3 +ifloat: 6 +ildouble: 6 +ldouble: 6 +Test "Real part of: casinh (0.7 + 1.2 i) == 0.9786545955936738768 + 0.9113541895315601156 i": +double: 1 +idouble: 1 +ildouble: 892 +ldouble: 892 +Test "Imaginary part of: casinh (0.7 + 1.2 i) == 0.9786545955936738768 + 0.9113541895315601156 i": +float: 1 +ifloat: 1 +double: 1 +idouble: 1 +ildouble: 12 +ldouble: 12 + +# catan +Test "Real part of: catan (-2 - 3 i) == -1.4099210495965755225 - 0.2290726829685387662 i": +float: 3 +ifloat: 3 +Test "Imaginary part of: catan (-2 - 3 i) == -1.4099210495965755225 - 0.2290726829685387662 i": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +ildouble: 7 +ldouble: 7 +Test "Real part of: catan (0.7 + 1.2 i) == 1.0785743834118921877 + 0.5770573776534306764 i": +float: 4 +ifloat: 4 +ildouble: 251 +ldouble: 251 +Test "Imaginary part of: catan (0.7 + 1.2 i) == 1.0785743834118921877 + 0.5770573776534306764 i": +float: 1 +ifloat: 1 +double: 1 +idouble: 1 +ildouble: 474 +ldouble: 474 + +# catanh +Test "Real part of: catanh (-2 - 3 i) == -0.1469466662255297520 - 1.3389725222944935611 i": +float: 1 +ifloat: 1 +double: 4 +idouble: 4 +ildouble: 6 +ldouble: 6 +Test "Imaginary part of: catanh (-2 - 3 i) == -0.1469466662255297520 - 1.3389725222944935611 i": +float: 4 +ifloat: 4 +Test "Real part of: catanh (0.7 + 1.2 i) == 0.2600749516525135959 + 0.9702403077950989849 i": +float: 6 +ifloat: 6 +double: 1 +idouble: 1 +ildouble: 66 +ldouble: 66 +Test "Imaginary part of: catanh (0.7 + 1.2 i) == 0.2600749516525135959 + 0.9702403077950989849 i": +float: 6 +ifloat: 6 +double: 1 +idouble: 1 +ildouble: 447 +ldouble: 447 + +# cbrt +Test "cbrt (-0.001) == -0.1": +ildouble: 716 +ldouble: 716 +Test "cbrt (-27.0) == -3.0": +double: 1 +idouble: 1 +ildouble: 1 +ldouble: 1 +Test "cbrt (0.7) == 0.8879040017426007084": +double: 1 +idouble: 1 +ildouble: 346 +ldouble: 346 +Test "cbrt (0.970299) == 0.99": +double: 1 +idouble: 1 +ildouble: 306 +ldouble: 306 + +# ccos +Test "Real part of: ccos (-2 - 3 i) == -4.1896256909688072301 - 9.1092278937553365979 i": +Test "Imaginary part of: ccos (-2 - 3 i) == -4.1896256909688072301 - 9.1092278937553365979 i": +float: 1 +ifloat: 1 +ildouble: 1 +ldouble: 1 +Test "Real part of: ccos (0.7 + 1.2 i) == 1.3848657645312111080 - 0.97242170335830028619 i": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +ildouble: 5 +ldouble: 5 +Test "Imaginary part of: ccos (0.7 + 1.2 i) == 1.3848657645312111080 - 0.97242170335830028619 i": +double: 1 +idouble: 1 +ildouble: 1901 +ldouble: 1901 + +# ccosh +Test "Real part of: ccosh (-2 - 3 i) == -3.7245455049153225654 + 0.5118225699873846088 i": +float: 1 +ifloat: 1 +Test "Imaginary part of: ccosh (-2 - 3 i) == -3.7245455049153225654 + 0.5118225699873846088 i": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +ildouble: 1 +ldouble: 1 +Test "Real part of: ccosh (0.7 + 1.2 i) == 0.4548202223691477654 + 0.7070296600921537682 i": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +ildouble: 1467 +ldouble: 1467 +Test "Imaginary part of: ccosh (0.7 + 1.2 i) == 0.4548202223691477654 + 0.7070296600921537682 i": +double: 1 +idouble: 1 +ildouble: 1183 +ldouble: 1183 + +# cexp +Test "Real part of: cexp (-2.0 - 3.0 i) == -0.1339809149295426134 - 0.0190985162611351964 i": +ildouble: 4 +ldouble: 4 +Test "Imaginary part of: cexp (-2.0 - 3.0 i) == -0.1339809149295426134 - 0.0190985162611351964 i": +float: 1 +ifloat: 1 +ildouble: 18 +ldouble: 18 +Test "Real part of: cexp (0.7 + 1.2 i) == 0.7296989091503236012 + 1.8768962328348102821 i": +float: 1 +ifloat: 1 +double: 1 +idouble: 1 +ildouble: 940 +ldouble: 940 +Test "Imaginary part of: cexp (0.7 + 1.2 i) == 0.7296989091503236012 + 1.8768962328348102821 i": +float: 1 +ifloat: 1 +ildouble: 1067 +ldouble: 1067 + +# clog +Test "Real part of: clog (-2 - 3 i) == 1.2824746787307683680 - 2.1587989303424641704 i": +Test "Imaginary part of: clog (-2 - 3 i) == 1.2824746787307683680 - 2.1587989303424641704 i": +float: 3 +ifloat: 3 +double: 1 +idouble: 1 +ildouble: 1 +ldouble: 1 + +# clog10 +Test "Real part of: clog10 (-0 + inf i) == inf + pi/2*log10(e) i": +Test "Imaginary part of: clog10 (-0 + inf i) == inf + pi/2*log10(e) i": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +Test "Real part of: clog10 (-0 - inf i) == inf - pi/2*log10(e) i": +Test "Imaginary part of: clog10 (-0 - inf i) == inf - pi/2*log10(e) i": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +Test "Real part of: clog10 (-2 - 3 i) == 0.5569716761534183846 - 0.9375544629863747085 i": +Test "Imaginary part of: clog10 (-2 - 3 i) == 0.5569716761534183846 - 0.9375544629863747085 i": +float: 5 +ifloat: 5 +double: 1 +idouble: 1 +ildouble: 1 +ldouble: 1 +Test "Real part of: clog10 (-3 + inf i) == inf + pi/2*log10(e) i": +Test "Imaginary part of: clog10 (-3 + inf i) == inf + pi/2*log10(e) i": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +Test "Real part of: clog10 (-3 - inf i) == inf - pi/2*log10(e) i": +Test "Imaginary part of: clog10 (-3 - inf i) == inf - pi/2*log10(e) i": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +Test "Real part of: clog10 (-inf + 0 i) == inf + pi*log10(e) i": +Test "Imaginary part of: clog10 (-inf + 0 i) == inf + pi*log10(e) i": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +Test "Real part of: clog10 (-inf + 1 i) == inf + pi*log10(e) i": +Test "Imaginary part of: clog10 (-inf + 1 i) == inf + pi*log10(e) i": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +Test "Real part of: clog10 (-inf + inf i) == inf + 3/4 pi*log10(e) i": +Test "Imaginary part of: clog10 (-inf + inf i) == inf + 3/4 pi*log10(e) i": +double: 1 +idouble: 1 +Test "Real part of: clog10 (-inf - 0 i) == inf - pi*log10(e) i": +Test "Imaginary part of: clog10 (-inf - 0 i) == inf - pi*log10(e) i": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +Test "Real part of: clog10 (-inf - 1 i) == inf - pi*log10(e) i": +Test "Imaginary part of: clog10 (-inf - 1 i) == inf - pi*log10(e) i": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +Test "Real part of: clog10 (0 + inf i) == inf + pi/2*log10(e) i": +Test "Imaginary part of: clog10 (0 + inf i) == inf + pi/2*log10(e) i": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +Test "Real part of: clog10 (0 - inf i) == inf - pi/2*log10(e) i": +Test "Imaginary part of: clog10 (0 - inf i) == inf - pi/2*log10(e) i": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +Test "Real part of: clog10 (0.7 + 1.2 i) == 0.1427786545038868803 + 0.4528483579352493248 i": +double: 2 +float: 1 +idouble: 2 +ifloat: 1 +ildouble: 1403 +ldouble: 1403 +Test "Imaginary part of: clog10 (0.7 + 1.2 i) == 0.1427786545038868803 + 0.4528483579352493248 i": +double: 1 +idouble: 1 +ildouble: 186 +ldouble: 186 +Test "Real part of: clog10 (3 + inf i) == inf + pi/2*log10(e) i": +Test "Imaginary part of: clog10 (3 + inf i) == inf + pi/2*log10(e) i": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +Test "Real part of: clog10 (3 - inf i) == inf - pi/2*log10(e) i": +Test "Imaginary part of: clog10 (3 - inf i) == inf - pi/2*log10(e) i": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +Test "Real part of: clog10 (inf + inf i) == inf + pi/4*log10(e) i": +Test "Imaginary part of: clog10 (inf + inf i) == inf + pi/4*log10(e) i": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +Test "Real part of: clog10 (inf - inf i) == inf - pi/4*log10(e) i": +Test "Imaginary part of: clog10 (inf - inf i) == inf - pi/4*log10(e) i": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 + +# cos +Test "cos (0.7) == 0.7648421872844884262": +float: 1 +ifloat: 1 +double: 1 +idouble: 1 +ildouble: 529 +ldouble: 529 +Test "cos (M_PI_6l * 2.0) == 0.5": +double: 1 +float: 0.5 +idouble: 1 +ifloat: 0.5 +Test "cos (M_PI_6l * 4.0) == -0.5": +double: 2 +float: 1 +idouble: 2 +ifloat: 1 +ildouble: 0.5 +ldouble: 0.5 +Test "cos (pi/2) == 0": +double: 0.2758 +float: 0.3667 +idouble: 0.2758 +ifloat: 0.3667 +ildouble: 0.25 +ldouble: 0.25 + +# cosh +Test "cosh (0.7) == 1.255169005630943018": +ildouble: 309 +ldouble: 309 + +# cpow +Test "Real part of: cpow (2 + 3 i, 4 + 0 i) == -119.0 - 120.0 i": +double: 1 +float: 4 +idouble: 1 +ifloat: 4 +Test "Imaginary part of: cpow (2 + 3 i, 4 + 0 i) == -119.0 - 120.0 i": +float: 2 +ifloat: 2 +ildouble: 4 +ldouble: 4 +Test "Real part of: cpow (e + 0 i, 0 + 2 * M_PIl i) == 1.0 + 0.0 i": +Test "Imaginary part of: cpow (e + 0 i, 0 + 2 * M_PIl i) == 1.0 + 0.0 i": +double: 1.104 +float: 2.5333 +idouble: 1.104 +ifloat: 2.5333 +ildouble: 1 +ldouble: 1 + +# csin +Test "Real part of: csin (0.7 + 1.2 i) == 1.1664563419657581376 + 1.1544997246948547371 i": +float: 1 +ifloat: 1 +ildouble: 966 +ldouble: 966 +Test "Imaginary part of: csin (0.7 + 1.2 i) == 1.1664563419657581376 + 1.1544997246948547371 i": +float: 1 +ifloat: 1 +ildouble: 168 +ldouble: 168 + +# csinh +Test "Real part of: csinh (-2 - 3 i) == 3.5905645899857799520 - 0.5309210862485198052 i": +double: 1 +idouble: 1 +Test "Imaginary part of: csinh (-2 - 3 i) == 3.5905645899857799520 - 0.5309210862485198052 i": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +ildouble: 2 +ldouble: 2 +Test "Real part of: csinh (0.7 + 1.2 i) == 0.27487868678117583582 + 1.1698665727426565139 i": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +ildouble: 413 +ldouble: 413 +Test "Imaginary part of: csinh (0.7 + 1.2 i) == 0.27487868678117583582 + 1.1698665727426565139 i": +float: 1 +ifloat: 1 +ildouble: 477 +ldouble: 477 + +# csqrt +Test "Real part of: csqrt (-2 + 3 i) == 0.8959774761298381247 + 1.6741492280355400404 i": +float: 1 +ifloat: 1 +ildouble: 1 +ldouble: 1 +Test "Imaginary part of: csqrt (-2 + 3 i) == 0.8959774761298381247 + 1.6741492280355400404 i": +Test "Real part of: csqrt (-2 - 3 i) == 0.8959774761298381247 - 1.6741492280355400404 i": +float: 1 +ifloat: 1 +ildouble: 1 +ldouble: 1 +Test "Imaginary part of: csqrt (-2 - 3 i) == 0.8959774761298381247 - 1.6741492280355400404 i": +Test "Real part of: csqrt (0.7 + 1.2 i) == 1.0220676100300264507 + 0.5870453129635652115 i": +float: 1 +ifloat: 1 +double: 1 +idouble: 1 +ildouble: 237 +ldouble: 237 +Test "Imaginary part of: csqrt (0.7 + 1.2 i) == 1.0220676100300264507 + 0.5870453129635652115 i": +float: 1 +ifloat: 1 +ildouble: 128 +ldouble: 128 + +# ctan +Test "Real part of: ctan (-2 - 3 i) == 0.0037640256415042482 - 1.0032386273536098014 i": +double: 1 +idouble: 1 +ildouble: 437 +ldouble: 437 +Test "Imaginary part of: ctan (-2 - 3 i) == 0.0037640256415042482 - 1.0032386273536098014 i": +float: 1 +ifloat: 1 +ildouble: 1 +ldouble: 1 +Test "Real part of: ctan (0.7 + 1.2 i) == 0.1720734197630349001 + 0.9544807059989405538 i": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +ildouble: 690 +ldouble: 690 +Test "Imaginary part of: ctan (0.7 + 1.2 i) == 0.1720734197630349001 + 0.9544807059989405538 i": +float: 1 +ifloat: 1 +double: 1 +idouble: 1 +ildouble: 367 +ldouble: 367 + +# ctanh +Test "Real part of: ctanh (-2 - 3 i) == -0.9653858790221331242 + 0.0098843750383224937 i": +float: 2 +ifloat: 2 +double: 2 +idouble: 2 +ildouble: 2 +ldouble: 2 +Test "Imaginary part of: ctanh (-2 - 3 i) == -0.9653858790221331242 + 0.0098843750383224937 i": +float: 1 +ifloat: 1 +ildouble: 23 +ldouble: 23 +Test "Real part of: ctanh (0 + pi/4 i) == 0.0 + 1.0 i": +Test "Imaginary part of: ctanh (0 + pi/4 i) == 0.0 + 1.0 i": +float: 1 +ifloat: 1 +double: 0.5 +idouble: 0.5 +Test "Real part of: ctanh (0.7 + 1.2 i) == 1.3472197399061191630 + 0.4778641038326365540 i": +float: 1 +ifloat: 1 +double: 2 +idouble: 2 +ildouble: 286 +ldouble: 286 +Test "Imaginary part of: ctanh (0.7 + 1.2 i) == 1.3472197399061191630 + 0.4778641038326365540 i": +float: 1 +ifloat: 1 +double: 2 +idouble: 2 +ildouble: 3074 +ldouble: 3074 + +# erfc +Test "erfc (0.7) == 0.32219880616258152702": +double: 1 +idouble: 1 +Test "erfc (1.2) == 0.089686021770364619762": +float: 2 +double: 1 +idouble: 1 +ifloat: 2 +Test "erfc (2.0) == 0.0046777349810472658379": +double: 1 +idouble: 1 +Test "erfc (4.1) == 0.67000276540848983727e-8": +double: 24 +float: 12 +idouble: 24 +ifloat: 12 + +# exp +Test "exp (0.7) == 2.0137527074704765216": +ildouble: 412 +ldouble: 412 + +# exp10 +Test "exp10 (-1) == 0.1": +float: 1 +ifloat: 1 +double: 2 +idouble: 2 +ildouble: 818 +ldouble: 818 +Test "exp10 (0.7) == 5.0118723362727228500": +float: 1 +ifloat: 1 +double: 1 +idouble: 1 +ildouble: 1182 +ldouble: 1182 +Test "exp10 (3) == 1000": +float: 2 +ifloat: 2 +double: 6 +idouble: 6 +ildouble: 8 +ldouble: 8 + +# exp2 +Test "exp2 (0.7) == 1.6245047927124710452": +ildouble: 462 +ldouble: 462 + +# expm1 +Test "expm1 (1) == M_El - 1.0": +float: 1 +ifloat: 1 +double: 1 +idouble: 1 + +# fmod +Test "fmod (-6.5, -2.3) == -1.9": +double: 2 +float: 1 +idouble: 2 +ifloat: 1 +ildouble: 4096 +ldouble: 4096 +Test "fmod (-6.5, 2.3) == -1.9": +double: 2 +float: 1 +idouble: 2 +ifloat: 1 +ildouble: 4096 +ldouble: 4096 +Test "fmod (6.5, -2.3) == 1.9": +double: 2 +float: 1 +idouble: 2 +ifloat: 1 +ildouble: 4096 +ldouble: 4096 +Test "fmod (6.5, 2.3) == 1.9": +double: 2 +float: 1 +idouble: 2 +ifloat: 1 +ildouble: 4096 +ldouble: 4096 + +# gamma +Test "gamma (-0.5) == log(2*sqrt(pi))": +double: 1 +idouble: 1 + +# hypot +Test "hypot (-0.7, -12.4) == 12.41974234837422060118": +float: 1 +ifloat: 1 +ildouble: 406 +ldouble: 406 +Test "hypot (-0.7, 12.4) == 12.41974234837422060118": +float: 1 +ifloat: 1 +ildouble: 406 +ldouble: 406 +Test "hypot (-12.4, -0.7) == 12.41974234837422060118": +float: 1 +ifloat: 1 +ildouble: 406 +ldouble: 406 +Test "hypot (-12.4, 0.7) == 12.41974234837422060118": +float: 1 +ifloat: 1 +ildouble: 406 +ldouble: 406 +Test "hypot (0.7, -12.4) == 12.41974234837422060118": +float: 1 +ifloat: 1 +ildouble: 406 +ldouble: 406 +Test "hypot (0.7, 1.2) == 1.3892443989449804508": +double: 1 +idouble: 1 +ildouble: 560 +ldouble: 560 +Test "hypot (0.7, 12.4) == 12.41974234837422060118": +float: 1 +ifloat: 1 +ildouble: 406 +ldouble: 406 +Test "hypot (12.4, -0.7) == 12.41974234837422060118": +float: 1 +ifloat: 1 +ildouble: 406 +ldouble: 406 +Test "hypot (12.4, 0.7) == 12.41974234837422060118": +float: 1 +ifloat: 1 +ildouble: 406 +ldouble: 406 + +# j0 +Test "j0 (10.0) == -0.24593576445134833520": +float: 1 +ifloat: 1 +Test "j0 (2.0) == 0.22389077914123566805": +float: 1 +ifloat: 1 +double: 1 +idouble: 1 +Test "j0 (8.0) == 0.17165080713755390609": +float: 1 +ifloat: 1 +Test "j0 (10.0) == -0.24593576445134833520": +double: 2 +idouble: 2 + +# j1 +Test "j1 (10.0) == 0.043472746168861436670": +float: 2 +ifloat: 2 +double: 2 +idouble: 2 +Test "j1 (2.0) == 0.57672480775687338720": +double: 1 +idouble: 1 +Test "j1 (8.0) == 0.23463634685391462438": +float: 1 +ifloat: 1 +double: 1 +idouble: 1 + +# jn +Test "jn (0, 10.0) == -0.24593576445134833520": +float: 1 +ifloat: 1 +double: 2 +idouble: 2 +Test "jn (0, 2.0) == 0.22389077914123566805": +float: 1 +ifloat: 1 +double: 1 +idouble: 1 +Test "jn (0, 8.0) == 0.17165080713755390609": +float: 1 +ifloat: 1 +Test "jn (1, 10.0) == 0.043472746168861436670": +float: 2 +ifloat: 2 +double: 2 +idouble: 2 +Test "jn (1, 2.0) == 0.57672480775687338720": +double: 1 +idouble: 1 +Test "jn (1, 8.0) == 0.23463634685391462438": +float: 1 +ifloat: 1 +double: 1 +idouble: 1 +Test "jn (10, -1.0) == 0.26306151236874532070e-9": +float: 1 +ifloat: 1 +Test "jn (10, 0.1) == 0.26905328954342155795e-19": +float: 4 +ifloat: 4 +double: 6 +idouble: 6 +Test "jn (10, 0.7) == 0.75175911502153953928e-11": +double: 4 +float: 1 +idouble: 4 +ifloat: 1 +Test "jn (10, 1.0) == 0.26306151236874532070e-9": +float: 1 +ifloat: 1 +Test "jn (10, 2.0) == 0.25153862827167367096e-6": +float: 3 +ifloat: 3 +double: 2 +idouble: 2 +Test "jn (10, 10.0) == 0.20748610663335885770": +float: 2 +ifloat: 2 +double: 4 +idouble: 4 +Test "jn (3, 0.1) == 0.000020820315754756261429": +double: 1 +idouble: 1 +Test "jn (3, 0.7) == 0.0069296548267508408077": +float: 1 +ifloat: 1 +double: 2 +idouble: 2 +Test "jn (3, 2.0) == 0.12894324947440205110": +float: 1 +ifloat: 1 +double: 1 +idouble: 1 +Test "jn (3, 10.0) == 0.058379379305186812343": +float: 1 +ifloat: 1 +double: 3 +idouble: 3 + +# lgamma +Test "lgamma (-0.5) == log(2*sqrt(pi))": +double: 1 +idouble: 1 +Test "lgamma (0.7) == 0.26086724653166651439": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +Test "lgamma (1.2) == -0.853740900033158497197e-1": +double: 1 +float: 2 +idouble: 1 +ifloat: 2 + +# log +Test "log (0.7) == -0.35667494393873237891": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +ildouble: 2341 +ldouble: 2341 +Test "log (e) == 1": +float: 0.5 +ifloat: 0.5 + +# log10 +Test "log10 (0.7) == -0.15490195998574316929": +float: 1 +ifloat: 1 +double: 1 +idouble: 1 +ildouble: 2033 +ldouble: 2033 +Test "log10 (e) == log10(e)": +float: 1 +ifloat: 1 +ildouble: 1 +ldouble: 1 + +# log1p +Test "log1p (-0.3) == -0.35667494393873237891": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +ildouble: 585 +ldouble: 585 + +# log2 +Test "log2 (0.7) == -0.51457317282975824043": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +ildouble: 1688 +ldouble: 1688 + +# pow +Test "pow (0.7, 1.2) == 0.65180494056638638188": +ildouble: 725 +ldouble: 725 + +# sin +Test "sin (0.7) == 0.64421768723769105367": +ildouble: 627 +ldouble: 627 + +# sincos +Test "sincos (0.7, &sin_res, &cos_res) puts 0.64421768723769105367 in sin_res": +ildouble: 627 +ldouble: 627 +Test "sincos (0.7, &sin_res, &cos_res) puts 0.76484218728448842626 in cos_res": +float: 1 +ifloat: 1 +double: 1 +idouble: 1 +ildouble: 528 +ldouble: 528 +Test "sincos (M_PI_6l*2.0, &sin_res, &cos_res) puts 0.5 in cos_res": +double: 1 +float: 0.5 +idouble: 1 +ifloat: 0.5 +Test "sincos (M_PI_6l*2.0, &sin_res, &cos_res) puts 0.866025403784438646764 in sin_res": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +ildouble: 1 +ldouble: 1 +Test "sincos (pi/2, &sin_res, &cos_res) puts 0 in cos_res": +double: 0.2758 +float: 0.3667 +idouble: 0.2758 +ifloat: 0.3667 +ildouble: 0.25 +ldouble: 0.25 +Test "sincos (pi/6, &sin_res, &cos_res) puts 0.866025403784438646764 in cos_res": +float: 1 +ifloat: 1 + + +# sinh +Test "sinh (0.7) == 0.75858370183953350346": +float: 1 +ifloat: 1 +double: 1 +idouble: 1 +ildouble: 1028 +ldouble: 1029 + +# sqrt +Test "sqrt (0.7) == 0.83666002653407554798": +ildouble: 489 +ldouble: 489 +Test "sqrt (15239.9025) == 123.45": +ildouble: 325 +ldouble: 325 + +# tan +Test "tan (0.7) == 0.84228838046307944813": +ildouble: 1401 +ldouble: 1401 +Test "tan (pi/4) == 1": +double: 0.5 +idouble: 0.5 + +# tanh +Test "tanh (0.7) == 0.60436777711716349631": +float: 1 +ifloat: 1 +double: 1 +idouble: 1 +ildouble: 521 +ldouble: 521 + +# tgamma +Test "tgamma (-0.5) == -2 sqrt (pi)": +double: 2 +float: 1 +idouble: 2 +ifloat: 1 +Test "tgamma (0.5) == sqrt (pi)": +float: 1 +ifloat: 1 +Test "tgamma (0.7) == 1.29805533264755778568": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 + +# y0 +Test "y0 (0.1) == -1.5342386513503668441": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +Test "y0 (0.7) == -0.19066492933739506743": +float: 1 +ifloat: 1 +double: 2 +idouble: 2 +Test "y0 (1.0) == 0.088256964215676957983": +double: 2 +float: 1 +idouble: 2 +ifloat: 1 +Test "y0 (1.5) == 0.38244892379775884396": +float: 1 +ifloat: 1 +double: 2 +idouble: 2 +Test "y0 (2.0) == 0.51037567264974511960": +double: 1 +idouble: 1 +Test "y0 (10.0) == 0.055671167283599391424": +float: 1 +ifloat: 1 +double: 2 +idouble: 2 +Test "y0 (8.0) == 0.22352148938756622053": +float: 1 +ifloat: 1 +double: 1 +idouble: 1 + +# y1 +Test "y1 (0.1) == -6.4589510947020269877": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +Test "y1 (0.7) == -1.1032498719076333697": +float: 1 +ifloat: 1 +double: 1 +idouble: 1 +Test "y1 (1.0) == -0.78121282130028871655": +double: 1 +idouble: 1 +Test "y1 (1.5) == -0.41230862697391129595": +float: 1 +ifloat: 1 +Test "y1 (10.0) == 0.24901542420695388392": +double: 3 +float: 2 +idouble: 3 +ifloat: 2 +Test "y1 (2.0) == -0.10703243154093754689": +double: 1 +float: 2 +idouble: 1 +ifloat: 2 +Test "y1 (8.0) == -0.15806046173124749426": +float: 2 +ifloat: 2 +double: 1 +idouble: 1 + +# yn +Test "yn (0, 0.1) == -1.5342386513503668441": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +Test "yn (0, 0.7) == -0.19066492933739506743": +float: 1 +ifloat: 1 +double: 2 +idouble: 2 +Test "yn (0, 1.0) == 0.088256964215676957983": +double: 2 +float: 1 +idouble: 2 +ifloat: 1 +Test "yn (0, 1.5) == 0.38244892379775884396": +float: 1 +ifloat: 1 +double: 2 +idouble: 2 +Test "yn (0, 2.0) == 0.51037567264974511960": +double: 1 +idouble: 1 +Test "yn (0, 10.0) == 0.055671167283599391424": +float: 1 +ifloat: 1 +double: 2 +idouble: 2 +Test "yn (0, 8.0) == 0.22352148938756622053": +float: 1 +ifloat: 1 +double: 1 +idouble: 1 +Test "yn (1, 0.1) == -6.4589510947020269877": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +Test "yn (1, 0.7) == -1.1032498719076333697": +float: 1 +ifloat: 1 +double: 1 +idouble: 1 +Test "yn (1, 1.0) == -0.78121282130028871655": +double: 1 +idouble: 1 +Test "yn (1, 1.5) == -0.41230862697391129595": +float: 1 +ifloat: 1 +Test "yn (1, 10.0) == 0.24901542420695388392": +double: 3 +float: 2 +idouble: 3 +ifloat: 2 +Test "yn (1, 2.0) == -0.10703243154093754689": +double: 1 +float: 2 +idouble: 1 +ifloat: 2 +Test "yn (1, 8.0) == -0.15806046173124749426": +float: 2 +ifloat: 2 +double: 1 +idouble: 1 +Test "yn (10, 0.1) == -0.11831335132045197885e19": +double: 2 +float: 1 +idouble: 2 +ifloat: 1 +Test "yn (10, 0.7) == -0.42447194260703866924e10": +double: 6 +float: 3 +idouble: 6 +ifloat: 3 +Test "yn (10, 1.0) == -0.12161801427868918929e9": +float: 2 +ifloat: 2 +double: 1 +idouble: 1 +Test "yn (10, 10.0) == -0.35981415218340272205": +double: 2 +float: 1 +idouble: 2 +ifloat: 1 +Test "yn (10, 2.0) == -129184.54220803928264": +float: 1 +ifloat: 1 +double: 3 +idouble: 3 +Test "yn (3, 0.1) == -5099.3323786129048894": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +Test "yn (3, 0.7) == -15.819479052819633505": +float: 1 +ifloat: 1 +double: 2 +idouble: 2 +Test "yn (3, 2.0) == -1.1277837768404277861": +float: 1 +ifloat: 1 +double: 1 +idouble: 1 +Test "yn (3, 10.0) == -0.25136265718383732978": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 + +# Maximal error of functions: +Function: "acos": +ildouble: 1149 +ldouble: 1149 + +Function: "asin": +float: 2 +ifloat: 2 +double: 1 +idouble: 1 +ildouble: 1147 +ldouble: 1147 + +Function: "asinh": +double: 1 +idouble: 1 +ildouble: 656 +ldouble: 656 + +Function: "atan": +ildouble: 549 +ldouble: 549 + +Function: "atan2": +ildouble: 549 +ldouble: 549 + +Function: "atanh": +double: 1 +idouble: 1 +ildouble: 1605 +ldouble: 1605 + +Function: "cabs": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +ildouble: 560 +ldouble: 560 + +Function: Real part of "cacos": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +ildouble: 151 +ldouble: 151 + +Function: Imaginary part of "cacos": +float: 2 +ifloat: 2 +ildouble: 329 +ldouble: 329 + +Function: Real part of "cacosh": +float: 7 +ifloat: 7 +double: 1 +idouble: 1 +ildouble: 328 +ldouble: 328 + +Function: Imaginary part of "cacosh": +float: 3 +ifloat: 3 +double: 1 +idouble: 1 +ildouble: 151 +ldouble: 151 + +Function: Real part of "casin": +double: 3 +float: 2 +idouble: 3 +ifloat: 2 +ildouble: 603 +ldouble: 603 + +Function: Imaginary part of "casin": +float: 2 +ifloat: 2 +ildouble: 329 +ldouble: 329 + +Function: Real part of "casinh": +double: 5 +float: 1 +idouble: 5 +ifloat: 1 +ildouble: 892 +ldouble: 892 + +Function: Imaginary part of "casinh": +double: 3 +float: 6 +idouble: 3 +ifloat: 6 +ildouble: 12 +ldouble: 12 + +Function: Real part of "catan": +float: 4 +ifloat: 4 +ildouble: 251 +ldouble: 251 + +Function: Imaginary part of "catan": +float: 1 +ifloat: 1 +double: 1 +idouble: 1 +ildouble: 474 +ldouble: 474 + +Function: Real part of "catanh": +double: 4 +idouble: 4 +ildouble: 66 +ldouble: 66 + +Function: Imaginary part of "catanh": +float: 6 +ifloat: 6 +double: 1 +idouble: 1 +ildouble: 447 +ldouble: 447 + +Function: "cbrt": +double: 1 +idouble: 1 +ildouble: 716 +ldouble: 716 + +Function: Real part of "ccos": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +ildouble: 5 +ldouble: 5 + +Function: Imaginary part of "ccos": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +ildouble: 1901 +ldouble: 1901 + +Function: Real part of "ccosh": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +ildouble: 1467 +ldouble: 1467 + +Function: Imaginary part of "ccosh": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +ildouble: 1183 +ldouble: 1183 + +Function: Real part of "cexp": +float: 1 +ifloat: 1 +double: 1 +idouble: 1 +ildouble: 940 +ldouble: 940 + +Function: Imaginary part of "cexp": +float: 1 +ifloat: 1 +ildouble: 1067 +ldouble: 1067 + +Function: Real part of "clog": + +Function: Imaginary part of "clog": +float: 3 +ifloat: 3 +double: 1 +idouble: 1 +ildouble: 1 +ldouble: 1 + +Function: Real part of "clog10": +double: 2 +float: 1 +idouble: 2 +ifloat: 1 +ildouble: 1402 +ldouble: 1402 + +Function: Imaginary part of "clog10": +float: 5 +ifloat: 5 +double: 1 +idouble: 1 +ildouble: 186 +ldouble: 186 + +Function: "cos": +double: 2 +float: 1 +idouble: 2 +ifloat: 1 +ildouble: 529 +ldouble: 529 + +Function: "cosh": +ildouble: 309 +ldouble: 309 + +Function: Real part of "cpow": +double: 1 +float: 4 +idouble: 1 +ifloat: 4 + +Function: Imaginary part of "cpow": +double: 1.104 +float: 2.5333 +idouble: 1.104 +ifloat: 2.5333 +ildouble: 2 +ldouble: 2 + +Function: Real part of "csin": +float: 1 +ifloat: 1 +ildouble: 966 +ldouble: 966 + +Function: Imaginary part of "csin": +float: 1 +ifloat: 1 +ildouble: 168 +ldouble: 168 + +Function: Real part of "csinh": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +ildouble: 413 +ldouble: 413 + +Function: Imaginary part of "csinh": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +ildouble: 477 +ldouble: 477 + +Function: Real part of "csqrt": +float: 1 +ifloat: 1 +double: 1 +idouble: 1 +ildouble: 237 +ldouble: 237 + +Function: Imaginary part of "csqrt": +float: 2 +ifloat: 2 +ildouble: 128 +ldouble: 128 + +Function: Real part of "ctan": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +ildouble: 690 +ldouble: 690 + +Function: Imaginary part of "ctan": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +ildouble: 367 +ldouble: 367 + +Function: Real part of "ctanh": +float: 2 +ifloat: 2 +double: 2 +idouble: 2 +ildouble: 286 +ldouble: 286 + +Function: Imaginary part of "ctanh": +float: 2 +ifloat: 2 +double: 2 +idouble: 2 +ildouble: 3074 +ldouble: 3074 + +Function: "erfc": +double: 24 +float: 12 +idouble: 24 +ifloat: 12 + +Function: "exp": +ildouble: 412 +ldouble: 412 + +Function: "exp10": +float: 2 +ifloat: 2 +double: 6 +idouble: 6 +ildouble: 1182 +ldouble: 1182 + +Function: "exp2": +ildouble: 462 +ldouble: 462 + +Function: "expm1": +float: 1 +ifloat: 1 +double: 1 +idouble: 1 +ildouble: 825 +ldouble: 825 + +Function: "fmod": +double: 2 +float: 1 +idouble: 2 +ifloat: 1 +ildouble: 4096 +ldouble: 4096 + +Function: "gamma": +double: 1 +idouble: 1 + +Function: "hypot": +float: 1 +ifloat: 1 +double: 1 +idouble: 1 +ildouble: 560 +ldouble: 560 + +Function: "j0": +float: 1 +ifloat: 1 +double: 2 +idouble: 2 + +Function: "j1": +float: 2 +ifloat: 2 +double: 2 +idouble: 2 + +Function: "jn": +float: 4 +ifloat: 4 +double: 6 +idouble: 6 + +Function: "lgamma": +double: 1 +float: 2 +idouble: 1 +ifloat: 2 + +Function: "log": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +ildouble: 2341 +ldouble: 2341 + +Function: "log10": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +ildouble: 2033 +ldouble: 2033 + +Function: "log1p": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +ildouble: 585 +ldouble: 585 + +Function: "log2": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +ildouble: 1688 +ldouble: 1688 + +Function: "pow": +ildouble: 725 +ldouble: 725 + +Function: "sin": +ildouble: 627 +ldouble: 627 + +Function: "sincos": +double: 1 +float: 1 +idouble: 1 +ifloat: 1 +ildouble: 627 +ldouble: 627 + +Function: "sinh": +float: 1 +ifloat: 1 +double: 1 +idouble: 1 +ildouble: 1028 +ldouble: 1029 + +Function: "sqrt": +ildouble: 489 +ldouble: 489 + +Function: "tan": +double: 0.5 +idouble: 0.5 +ildouble: 1401 +ldouble: 1401 + +Function: "tanh": +float: 1 +ifloat: 1 +double: 1 +idouble: 1 +ildouble: 521 +ldouble: 521 + +Function: "tgamma": +double: 2 +float: 1 +idouble: 2 +ifloat: 1 + +Function: "y0": +double: 2 +float: 1 +idouble: 2 +ifloat: 1 + +Function: "y1": +double: 3 +float: 2 +idouble: 3 +ifloat: 2 + +Function: "yn": +double: 6 +float: 3 +idouble: 6 +ifloat: 3 + +# end of automatic generation From aj@suse.de Thu Sep 21 00:29:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Thu, 21 Sep 2000 00:29:00 -0000 Subject: A glibc ia64 patch for math References: <20000920234252.A20940@valinux.com> Message-ID: >>>>> H J Lu writes: HJ> With this patch, I only got HJ> make[2]: *** [/home/work/build/glibc/math/test-ldouble.out] Error 1 HJ> make[2]: *** [/home/work/build/glibc/math/test-ildoubl.out] Error 1 HJ> for "make check" on ia64. Those long double functions are not HJ> implemented. I assume we will get them in libm from Intel. With all Which functions are missing? I might be able to handle that in the tests. Andreas HJ> my ia64 patches applied, glibc 2.2 is in very good shape under ia64 HJ> now. Glad to hear! Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From schwab@suse.de Thu Sep 21 01:51:00 2000 From: schwab@suse.de (Andreas Schwab) Date: Thu, 21 Sep 2000 01:51:00 -0000 Subject: ia64 fenv patch. References: <20000920190828.A11605@valinux.com> Message-ID: <200009210851.e8L8piF25186@hawking.suse.de> "H . J . Lu" writes: |> Index: sysdeps/ia64/fpu/fegetexcept.c |> =================================================================== |> RCS file: /work/cvs/gnu/glibc/sysdeps/ia64/fpu/fegetexcept.c,v |> retrieving revision 1.1.1.1 |> diff -u -p -r1.1.1.1 fegetexcept.c |> --- sysdeps/ia64/fpu/fegetexcept.c 2000/05/21 21:12:03 1.1.1.1 |> +++ sysdeps/ia64/fpu/fegetexcept.c 2000/09/21 01:27:21 |> @@ -27,5 +27,5 @@ fegetexcept (void) |> |> __asm__ __volatile__ ("mov.m %0=ar.fpsr" : "=r" (fpsr)); |> |> - return (fpsr ^ FE_ALL_EXCEPT) & FE_ALL_EXCEPT; |> + return (~fpsr) & FE_ALL_EXCEPT; What's wrong with this? Both expressions are equivalent. Andreas. -- Andreas Schwab "And now for something SuSE Labs completely different." Andreas.Schwab@suse.de SuSE GmbH, Schanz????ckerstr. 10, D-90443 N????rnberg From hjl@valinux.com Thu Sep 21 07:34:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Thu, 21 Sep 2000 07:34:00 -0000 Subject: [ia64-tools] Re: ia64 fenv patch. References: <20000920190828.A11605@valinux.com> <200009210851.e8L8piF25186@hawking.suse.de> Message-ID: <20000921072447.A1382@valinux.com> On Thu, Sep 21, 2000 at 10:51:44AM +0200, Andreas Schwab wrote: > "H . J . Lu" writes: > > |> Index: sysdeps/ia64/fpu/fegetexcept.c > |> =================================================================== > |> RCS file: /work/cvs/gnu/glibc/sysdeps/ia64/fpu/fegetexcept.c,v > |> retrieving revision 1.1.1.1 > |> diff -u -p -r1.1.1.1 fegetexcept.c > |> --- sysdeps/ia64/fpu/fegetexcept.c 2000/05/21 21:12:03 1.1.1.1 > |> +++ sysdeps/ia64/fpu/fegetexcept.c 2000/09/21 01:27:21 > |> @@ -27,5 +27,5 @@ fegetexcept (void) > |> > |> __asm__ __volatile__ ("mov.m %0=ar.fpsr" : "=r" (fpsr)); > |> > |> - return (fpsr ^ FE_ALL_EXCEPT) & FE_ALL_EXCEPT; > |> + return (~fpsr) & FE_ALL_EXCEPT; > > What's wrong with this? Both expressions are equivalent. > I have so many problems with those functions. I just copied them from ia32 :-(. Also it looks nicer :-). -- H.J. Lu (hjl@gnu.org) From hjl@valinux.com Thu Sep 21 07:35:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Thu, 21 Sep 2000 07:35:00 -0000 Subject: [ia64-tools] Re: A glibc ia64 patch for math References: <20000920234252.A20940@valinux.com> Message-ID: <20000921073016.B1382@valinux.com> On Thu, Sep 21, 2000 at 09:04:41AM +0200, Andreas Jaeger wrote: > >>>>> H J Lu writes: > > HJ> With this patch, I only got > HJ> make[2]: *** [/home/work/build/glibc/math/test-ldouble.out] Error 1 > HJ> make[2]: *** [/home/work/build/glibc/math/test-ildoubl.out] Error 1 > > HJ> for "make check" on ia64. Those long double functions are not > HJ> implemented. I assume we will get them in libm from Intel. With all > Which functions are missing? I might be able to handle that in the > tests. > Here is the list. I hope I didn't miss anything. Thanks. H.J. --- __atanl not implemented __erfcl not implemented __erfl not implemented __expm1l not implemented __ieee754_acosl not implemented __ieee754_asinl not implemented __ieee754_exp2l not implemented __ieee754_expl not implemented __ieee754_fmodl not implemented __ieee754_j0l not implemented __ieee754_j1l not implemented __ieee754_jnl not implemented __ieee754_lgammal_r not implemented __ieee754_log10l not implemented __ieee754_logl not implemented __ieee754_powl not implemented __ieee754_rem_pio2l not implemented __ieee754_sqrtl not implemented __ieee754_y0l not implemented __ieee754_y1l not implemented __ieee754_ynl not implemented __kernel_cosl not implemented __kernel_sinl not implemented __kernel_tanl not implemented __log1pl not implemented __log2l not implemented From aj@suse.de Thu Sep 21 08:01:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Thu, 21 Sep 2000 08:01:00 -0000 Subject: [ia64-tools] Re: A glibc ia64 patch for math References: <20000920234252.A20940@valinux.com> <20000921073016.B1382@valinux.com> Message-ID: >>>>> H J Lu writes: > On Thu, Sep 21, 2000 at 09:04:41AM +0200, Andreas Jaeger wrote: >> >>>>> H J Lu writes: >> HJ> With this patch, I only got HJ> make[2]: *** [/home/work/build/glibc/math/test-ldouble.out] Error 1 HJ> make[2]: *** [/home/work/build/glibc/math/test-ildoubl.out] Error 1 >> HJ> for "make check" on ia64. Those long double functions are not HJ> implemented. I assume we will get them in libm from Intel. With all >> Which functions are missing? I might be able to handle that in the >> tests. >> > Here is the list. I hope I didn't miss anything. > Thanks. > H.J. > --- > __atanl not implemented > __erfcl not implemented > __erfl not implemented > __expm1l not implemented > __ieee754_acosl not implemented > __ieee754_asinl not implemented > __ieee754_exp2l not implemented > __ieee754_expl not implemented > __ieee754_fmodl not implemented > __ieee754_j0l not implemented > __ieee754_j1l not implemented > __ieee754_jnl not implemented > __ieee754_lgammal_r not implemented > __ieee754_log10l not implemented > __ieee754_logl not implemented > __ieee754_powl not implemented > __ieee754_rem_pio2l not implemented > __ieee754_sqrtl not implemented > __ieee754_y0l not implemented > __ieee754_y1l not implemented > __ieee754_ynl not implemented > __kernel_cosl not implemented > __kernel_sinl not implemented > __kernel_tanl not implemented > __log1pl not implemented > __log2l not implemented Here's a patch - I'll commit it later. Please test it and tell me if this fixes the issues. I hope I didn't introduce any copy&paste errors :-(. Andreas 2000-09-21 Andreas Jaeger * math/libm-test.inc (atan_test): (expm1_test): Likewise. (acos_test): Likewise. (asin_test): Likewise. (exp_test): Likewise. (fmod_test): Likewise. (log10_test): Likewise. (log_test): Likewise. (pow_test): Likewise. (sqrt_test): Likewise. (cos_test): Likewise. (sin_test): Likewise. (tan_test): Likewise. (log1p_test): Likewise. (log2_test): Likewise. ============================================================ Index: math/libm-test.inc --- math/libm-test.inc 2000/06/21 05:53:50 1.12 +++ math/libm-test.inc 2000/09/21 15:00:01 @@ -693,6 +693,12 @@ static void acos_test (void) { + errno = 0; + FUNC(acos) (0); + if (errno == ENOSYS) + /* Function not implemented. */ + return; + START (acos); TEST_f_f (acos, plus_infty, nan_value, INVALID_EXCEPTION); @@ -734,6 +740,11 @@ static void asin_test (void) { + errno = 0; + FUNC(asin) (0); + if (errno == ENOSYS) + /* Function not implemented. */ + return; START (asin); @@ -776,6 +787,11 @@ static void atan_test (void) { + errno = 0; + FUNC(atan) (0); + if (errno == ENOSYS) + /* Function not implemented. */ + return; START (atan); @@ -1749,6 +1765,12 @@ static void cos_test (void) { + errno = 0; + FUNC(cos) (0); + if (errno == ENOSYS) + /* Function not implemented. */ + return; + START (cos); TEST_f_f (cos, 0, 1); @@ -2185,6 +2207,12 @@ static void exp_test (void) { + errno = 0; + FUNC(exp) (0); + if (errno == ENOSYS) + /* Function not implemented. */ + return; + START (exp); TEST_f_f (exp, 0, 1); @@ -2260,6 +2288,12 @@ static void expm1_test (void) { + errno = 0; + FUNC(expm1) (0); + if (errno == ENOSYS) + /* Function not implemented. */ + return; + START (expm1); TEST_f_f (expm1, 0, 0); @@ -2451,6 +2485,11 @@ static void fmod_test (void) { + errno = 0; + FUNC(fmod) (0, 0); + if (errno == ENOSYS) + /* Function not implemented. */ + return; START (fmod); @@ -2880,6 +2919,11 @@ static void log_test (void) { + errno = 0; + FUNC(log) (1); + if (errno == ENOSYS) + /* Function not implemented. */ + return; START (log); TEST_f_f (log, 0, minus_infty, DIVIDE_BY_ZERO_EXCEPTION); @@ -2903,6 +2947,12 @@ static void log10_test (void) { + errno = 0; + FUNC(log10) (1); + if (errno == ENOSYS) + /* Function not implemented. */ + return; + START (log10); TEST_f_f (log10, 0, minus_infty, DIVIDE_BY_ZERO_EXCEPTION); @@ -2930,6 +2980,12 @@ static void log1p_test (void) { + errno = 0; + FUNC(log1p) (0); + if (errno == ENOSYS) + /* Function not implemented. */ + return; + START (log1p); TEST_f_f (log1p, 0, 0); @@ -2952,6 +3008,12 @@ static void log2_test (void) { + errno = 0; + FUNC(log2) (1); + if (errno == ENOSYS) + /* Function not implemented. */ + return; + START (log2); TEST_f_f (log2, 0, minus_infty, DIVIDE_BY_ZERO_EXCEPTION); @@ -3167,6 +3229,12 @@ pow_test (void) { + errno = 0; + FUNC(pow) (0, 0); + if (errno == ENOSYS) + /* Function not implemented. */ + return; + START (pow); TEST_ff_f (pow, 0, 0, 1); @@ -3546,6 +3614,12 @@ static void sin_test (void) { + errno = 0; + FUNC(sin) (0); + if (errno == ENOSYS) + /* Function not implemented. */ + return; + START (sin); TEST_f_f (sin, 0, 0); @@ -3608,6 +3682,12 @@ static void sqrt_test (void) { + errno = 0; + FUNC(sqrt) (1); + if (errno == ENOSYS) + /* Function not implemented. */ + return; + START (sqrt); TEST_f_f (sqrt, 0, 0); @@ -3635,6 +3715,12 @@ static void tan_test (void) { + errno = 0; + FUNC(tan) (0); + if (errno == ENOSYS) + /* Function not implemented. */ + return; + START (tan); TEST_f_f (tan, 0, 0); -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From hjl@valinux.com Thu Sep 21 08:30:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Thu, 21 Sep 2000 08:30:00 -0000 Subject: [ia64-tools] Re: A glibc ia64 patch for math References: <20000920234252.A20940@valinux.com> <20000921073016.B1382@valinux.com> Message-ID: <20000921082551.A2979@valinux.com> On Thu, Sep 21, 2000 at 05:01:07PM +0200, Andreas Jaeger wrote: > > Here's a patch - I'll commit it later. Please test it and tell me if > this fixes the issues. I hope I didn't introduce any copy&paste > errors :-(. Thanks. > @@ -2451,6 +2485,11 @@ > static void > fmod_test (void) > { > + errno = 0; > + FUNC(fmod) (0, 0); > + if (errno == ENOSYS) > + /* Function not implemented. */ > + return; > You cannot test fmod () like that :-). I still got many failures on long double. I am enclosing a few here: testing long double (without inline functions) Failure: Test: atan2 (-0, 1) == -0 Result: is: 0.00000000000000000000e+00 0x0.00000000000000000000p+0 should be: -0.00000000000000000000e+00 -0x0.00000000000000000000p+0 difference: 0.00000000000000000000e+00 0x0.00000000000000000000p+0 ulp : 0.0000 max.ulp : 0.0000 Failure: Test: atan2 (-inf, 1) == -pi/2 Result: is: 0.00000000000000000000e+00 0x0.00000000000000000000p+0 should be: -1.57079632679489661926e+00 -0xc.90fdaa22168c23500000000000000000000p-3 difference: 1.57079632679489661926e+00 0xc.90fdaa22168c23500000000000000000000p-3 ulp : 14488038916154245685.0000 max.ulp : 0.0000 I put math/test-ldouble.out and math/test-ildoubl.out at http://ftp.valinux.com/ftp/pub/support/hjl/ia64/test-ldouble.out http://ftp.valinux.com/ftp/pub/support/hjl/ia64/test-ildouble.out I am afraid I won't be able to look into it until the week after next week. I hope someone can take look at those long double functions. They are ok on ia32. But ia32 uses 80bit long double with 12bytes and ia64 uses 80bit long double with 16bytes. Thanks. H.J. From drepper@redhat.com Thu Sep 21 20:48:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Thu, 21 Sep 2000 20:48:00 -0000 Subject: cut off Message-ID: I'm in North Carolina in the moment and they failed to set up the net connections until today. I should be able to check mail from now on. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From hjl@lucon.org Thu Sep 21 21:16:00 2000 From: hjl@lucon.org (H . J . Lu) Date: Thu, 21 Sep 2000 21:16:00 -0000 Subject: elm 2.5.3 and glibc 2.1.93 Message-ID: <20000921211643.A6161@lucon.org> With glibc 2.1.93, I got # elm Cannot lock folder - giving up. Please try again in a few minutes. >From strace, I got open("/var/spool/mail/hjl", O_RDWR) = 4 fcntl64(4, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = -1 ENOSYS (Function not implemented) fcntl(4, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = 0 write(1, "\33[?1l\33>", 7^[[?1l^[>) = 7 write(1, "\33[24;1H\r\n", 9^[[24;1H^M) = 9 write(1, "\33[2J\33[?47l\0338", 12^[[2J^[[?47l^[8) = 12 ioctl(0, SNDCTL_TMR_STOP, {B9600 opost isig icanon echo ...}) = 0 write(2, "Cannot lock folder - giving up. "..., 67Cannot lock folder - giving up. Please try again in a few minutes.) = 67 It looks like elm 2.5.3 may check errno even when fcntl returns 0. I believe it is a glibc bug. Here is my patch. Someone please double check if there are any more functions like that need fix. Thanks. H.J. --- /work/gnu/import/libc/sysdeps/unix/sysv/linux/i386/fcntl.c Thu Sep 7 08:45:36 2000 +++ ./fcntl.c Thu Sep 21 21:15:25 2000 @@ -50,10 +50,13 @@ __libc_fcntl (int fd, int cmd, ...) # ifdef __NR_fcntl64 if (! __have_no_fcntl64) { + int saved_errno = errno; int result = INLINE_SYSCALL (fcntl64, 3, fd, cmd, arg); + if (result >= 0 || errno != ENOSYS) return result; + __set_errno (saved_errno); __have_no_fcntl64 = 1; } # endif From hjl@lucon.org Fri Sep 22 00:17:00 2000 From: hjl@lucon.org (H . J . Lu) Date: Fri, 22 Sep 2000 00:17:00 -0000 Subject: Patch: Re: elm 2.5.3 and glibc 2.1.93 References: <20000921211643.A6161@lucon.org> Message-ID: <20000922001715.A10256@lucon.org> On Thu, Sep 21, 2000 at 09:16:43PM -0700, H . J . Lu wrote: > With glibc 2.1.93, I got > > # elm > Cannot lock folder - giving up. Please try again in a few minutes. > > >From strace, I got > > open("/var/spool/mail/hjl", O_RDWR) = 4 > fcntl64(4, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = -1 ENOSYS (Function not implemented) > fcntl(4, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = 0 > write(1, "\33[?1l\33>", 7^[[?1l^[>) = 7 > write(1, "\33[24;1H\r\n", 9^[[24;1H^M) = 9 > write(1, "\33[2J\33[?47l\0338", 12^[[2J^[[?47l^[8) = 12 > ioctl(0, SNDCTL_TMR_STOP, {B9600 opost isig icanon echo ...}) = 0 > write(2, "Cannot lock folder - giving up. "..., 67Cannot lock folder - giving up. Please try again in a few minutes.) = 67 > > It looks like elm 2.5.3 may check errno even when fcntl returns 0. I > believe it is a glibc bug. Here is my patch. Someone please double > check if there are any more functions like that need fix. > Here is a patch for the problems I found. H.J. ---- 2000-09-21 H.J. Lu * sysdeps/posix/pathconf.c (__pathconf): Use __set_errno to set errno. * sysdeps/unix/sysv/linux/powerpc/chown.c (__chown): Likewise. * sysdeps/unix/sysv/linux/pread.c (__libc_pread): Save and restore errno if necessary. * sysdeps/unix/sysv/linux/pread64.c (__libc_pread64): Likewise. * sysdeps/unix/sysv/linux/pwrite.c (__libc_pwrite): Likewise. * sysdeps/unix/sysv/linux/pwrite64.c (__libc_pwrite64): Likewise. * sysdeps/unix/sysv/linux/setegid.c (setegid): Likewise. * sysdeps/unix/sysv/linux/seteuid.c (seteuid): Likewise. * sysdeps/unix/sysv/linux/alpha/adjtime.c (__adjtime): Likewise. (__adjtimex_tv64): Likewise. * sysdeps/unix/sysv/linux/i386/fcntl.c (__libc_fcntl): Likewise. * sysdeps/unix/sysv/linux/i386/fxstat.c (__fxstat): Likewise. * sysdeps/unix/sysv/linux/i386/getrlimit.c (__new_getrlimit): Likewise. * sysdeps/unix/sysv/linux/i386/lockf64.c (lockf64): Likewise. * sysdeps/unix/sysv/linux/i386/lxstat.c (__lxstat): Likewise. * sysdeps/unix/sysv/linux/i386/seteuid.c (seteuid): Likewise. * sysdeps/unix/sysv/linux/i386/setrlimit.c (__new_setrlimit): Likewise. * sysdeps/unix/sysv/linux/i386/xstat.c (__xstat): Likewise. * sysdeps/unix/sysv/linux/mips/pread.c (__libc_pread): Likewise. * sysdeps/unix/sysv/linux/mips/pread64.c (__libc_pread64): Likewise. * sysdeps/unix/sysv/linux/mips/pwrite.c (__libc_pwrite): Likewise. * sysdeps/unix/sysv/linux/mips/pwrite64.c (__libc_pwrite64): Likewise. * sysdeps/unix/sysv/linux/powerpc/pread.c (__libc_pread): Likewise. * sysdeps/unix/sysv/linux/powerpc/pread64.c (__libc_pread64): Likewise. * sysdeps/unix/sysv/linux/powerpc/pwrite.c (__libc_pwrite): Likewise. * sysdeps/unix/sysv/linux/powerpc/pwrite64.c (__libc_pwrite64): Likewise. * sysdeps/unix/sysv/linux/sparc/sparc32/setegid.c (setegid): Likewise. * sysdeps/unix/sysv/linux/sparc/sparc32/seteuid.c (seteuid): Likewise. Index: sysdeps/posix/pathconf.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/posix/pathconf.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 pathconf.c --- sysdeps/posix/pathconf.c 2000/09/22 05:54:49 1.1.1.1 +++ sysdeps/posix/pathconf.c 2000/09/22 06:30:11 @@ -70,7 +70,7 @@ __pathconf (const char *path, int name) { if (errno == ENOSYS) { - errno = save_errno; + __set_errno (save_errno); return NAME_MAX; } return -1; Index: sysdeps/unix/sysv/linux/pread.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/unix/sysv/linux/pread.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 pread.c --- sysdeps/unix/sysv/linux/pread.c 2000/09/22 05:54:57 1.1.1.1 +++ sysdeps/unix/sysv/linux/pread.c 2000/09/22 06:01:36 @@ -47,14 +47,20 @@ __libc_pread (fd, buf, count, offset) off_t offset; { ssize_t result; +# if __ASSUME_PREAD_SYSCALL == 0 + int saved_errno = errno; +# endif /* First try the syscall. */ result = INLINE_SYSCALL (pread, 5, fd, CHECK_N (buf, count), count, __LONG_LONG_PAIR (0, offset)); # if __ASSUME_PREAD_SYSCALL == 0 if (result == -1 && errno == ENOSYS) - /* No system call available. Use the emulation. */ - result = __emulate_pread (fd, buf, count, offset); + { + /* No system call available. Use the emulation. */ + __set_errno (saved_errno); + result = __emulate_pread (fd, buf, count, offset); + } # endif return result; Index: sysdeps/unix/sysv/linux/pread64.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/unix/sysv/linux/pread64.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 pread64.c --- sysdeps/unix/sysv/linux/pread64.c 2000/09/22 05:54:57 1.1.1.1 +++ sysdeps/unix/sysv/linux/pread64.c 2000/09/22 06:02:22 @@ -46,6 +46,9 @@ __libc_pread64 (fd, buf, count, offset) off64_t offset; { ssize_t result; +# if __ASSUME_PREAD_SYSCALL == 0 + int saved_errno = errno; +# endif /* First try the syscall. */ result = INLINE_SYSCALL (pread, 5, fd, CHECK_N (buf, count), count, @@ -53,8 +56,11 @@ __libc_pread64 (fd, buf, count, offset) (off_t) (offset & 0xffffffff))); # if __ASSUME_PREAD_SYSCALL == 0 if (result == -1 && errno == ENOSYS) - /* No system call available. Use the emulation. */ - result = __emulate_pread64 (fd, buf, count, offset); + { + __set_errno (saved_errno); + /* No system call available. Use the emulation. */ + result = __emulate_pread64 (fd, buf, count, offset); + } # endif return result; Index: sysdeps/unix/sysv/linux/pwrite.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/unix/sysv/linux/pwrite.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 pwrite.c --- sysdeps/unix/sysv/linux/pwrite.c 2000/09/22 05:54:57 1.1.1.1 +++ sysdeps/unix/sysv/linux/pwrite.c 2000/09/22 06:02:53 @@ -47,14 +47,20 @@ __libc_pwrite (fd, buf, count, offset) off_t offset; { ssize_t result; +# if __ASSUME_PWRITE_SYSCALL == 0 + int saved_errno = errno; +# endif /* First try the syscall. */ result = INLINE_SYSCALL (pwrite, 5, fd, CHECK_N (buf, count), count, __LONG_LONG_PAIR (0, offset)); # if __ASSUME_PWRITE_SYSCALL == 0 if (result == -1 && errno == ENOSYS) - /* No system call available. Use the emulation. */ - result = __emulate_pwrite (fd, buf, count, offset); + { + __set_errno (saved_errno); + /* No system call available. Use the emulation. */ + result = __emulate_pwrite (fd, buf, count, offset); + } # endif return result; Index: sysdeps/unix/sysv/linux/pwrite64.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/unix/sysv/linux/pwrite64.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 pwrite64.c --- sysdeps/unix/sysv/linux/pwrite64.c 2000/09/22 05:54:57 1.1.1.1 +++ sysdeps/unix/sysv/linux/pwrite64.c 2000/09/22 06:03:25 @@ -46,6 +46,9 @@ __libc_pwrite64 (fd, buf, count, offset) off64_t offset; { ssize_t result; +# if __ASSUME_PWRITE_SYSCALL == 0 + int saved_errno = errno; +# endif /* First try the syscall. */ result = INLINE_SYSCALL (pwrite, 5, fd, CHECK_N (buf, count), count, @@ -53,8 +56,11 @@ __libc_pwrite64 (fd, buf, count, offset) (off_t) (offset & 0xffffffff))); # if __ASSUME_PWRITE_SYSCALL == 0 if (result == -1 && errno == ENOSYS) - /* No system call available. Use the emulation. */ - result = __emulate_pwrite64 (fd, buf, count, offset); + { + __set_errno (saved_errno); + /* No system call available. Use the emulation. */ + result = __emulate_pwrite64 (fd, buf, count, offset); + } # endif return result; Index: sysdeps/unix/sysv/linux/setegid.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/unix/sysv/linux/setegid.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 setegid.c --- sysdeps/unix/sysv/linux/setegid.c 2000/09/22 05:54:57 1.1.1.1 +++ sysdeps/unix/sysv/linux/setegid.c 2000/09/22 06:35:25 @@ -29,6 +29,7 @@ int setegid (gid_t gid) { int result; + int saved_errno = errno; if (gid == (gid_t) ~0) { @@ -39,10 +40,14 @@ setegid (gid_t gid) /* First try the syscall. */ result = __setresgid (-1, gid, -1); if (result == -1 && errno == ENOSYS) - /* No system call available. Use emulation. This may not work - since `setregid' also sets the saved group ID when GID is not - equal to the real group ID, making it impossible to switch back. */ - result = __setregid (-1, gid); + { + /* No system call available. Use emulation. This may not work + since `setregid' also sets the saved group ID when GID is not + equal to the real group ID, making it impossible to switch + back. */ + __set_errno (saved_errno); + result = __setregid (-1, gid); + } return result; } Index: sysdeps/unix/sysv/linux/seteuid.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/unix/sysv/linux/seteuid.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 seteuid.c --- sysdeps/unix/sysv/linux/seteuid.c 2000/09/22 05:54:57 1.1.1.1 +++ sysdeps/unix/sysv/linux/seteuid.c 2000/09/22 06:33:33 @@ -31,6 +31,9 @@ int seteuid (uid_t uid) { int result; +# if __ASSUME_SETRESUID_SYSCALL == 0 + int saved_errno = errno; +# endif if (uid == (uid_t) ~0) { @@ -42,10 +45,14 @@ seteuid (uid_t uid) result = __setresuid (-1, uid, -1); # if __ASSUME_SETRESUID_SYSCALL == 0 if (result == -1 && errno == ENOSYS) - /* No system call available. Use emulation. This may not work - since `setreuid' also sets the saved user ID when UID is not - equal to the real user ID, making it impossible to switch back. */ - result = __setreuid (-1, uid); + { + __set_errno (saved_errno); + /* No system call available. Use emulation. This may not work + since `setreuid' also sets the saved user ID when UID is not + equal to the real user ID, making it impossible to switch + back. */ + result = __setreuid (-1, uid); + } # endif return result; Index: sysdeps/unix/sysv/linux/alpha/adjtime.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/unix/sysv/linux/alpha/adjtime.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 adjtime.c --- sysdeps/unix/sysv/linux/alpha/adjtime.c 2000/09/22 05:54:57 1.1.1.1 +++ sysdeps/unix/sysv/linux/alpha/adjtime.c 2000/09/22 06:13:09 @@ -94,12 +94,16 @@ __adjtime (itv, otv) struct timeval *otv; { int ret; + int saved_errno = errno; if (!missing_adjtimex) { ret = __adjtime_tv64 (itv, otv); if (ret && errno == ENOSYS) - missing_adjtimex = 1; + { + __set_errno (saved_errno); + missing_adjtimex = 1; + } } if (missing_adjtimex) @@ -127,13 +131,17 @@ int __adjtimex_tv64 (struct timex *tx) { int ret; + int saved_errno = errno; if (!missing_adjtimex) - { - ret = __syscall_adjtimex_tv64 (tx); - if (ret && errno == ENOSYS) - missing_adjtimex = 1; - } + { + ret = __syscall_adjtimex_tv64 (tx); + if (ret && errno == ENOSYS) + { + __set_errno (saved_errno); + missing_adjtimex = 1; + } + } if (missing_adjtimex) { Index: sysdeps/unix/sysv/linux/i386/fcntl.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/unix/sysv/linux/i386/fcntl.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 fcntl.c --- sysdeps/unix/sysv/linux/i386/fcntl.c 2000/09/22 05:55:00 1.1.1.1 +++ sysdeps/unix/sysv/linux/i386/fcntl.c 2000/09/22 05:56:52 @@ -50,10 +50,13 @@ __libc_fcntl (int fd, int cmd, ...) # ifdef __NR_fcntl64 if (! __have_no_fcntl64) { + int saved_errno = errno; int result = INLINE_SYSCALL (fcntl64, 3, fd, cmd, arg); + if (result >= 0 || errno != ENOSYS) return result; + __set_errno (saved_errno); __have_no_fcntl64 = 1; } # endif Index: sysdeps/unix/sysv/linux/i386/fxstat.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/unix/sysv/linux/i386/fxstat.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 fxstat.c --- sysdeps/unix/sysv/linux/i386/fxstat.c 2000/09/22 05:55:00 1.1.1.1 +++ sysdeps/unix/sysv/linux/i386/fxstat.c 2000/09/22 06:13:56 @@ -73,6 +73,7 @@ __fxstat (int vers, int fd, struct stat if (! __have_no_stat64) { struct stat64 buf64; + int saved_errno = errno; result = INLINE_SYSCALL (fstat64, 2, fd, __ptrvalue (&buf64)); @@ -82,6 +83,7 @@ __fxstat (int vers, int fd, struct stat if (result != -1 || errno != ENOSYS) return result; + __set_errno (saved_errno); __have_no_stat64 = 1; } # endif Index: sysdeps/unix/sysv/linux/i386/getrlimit.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/unix/sysv/linux/i386/getrlimit.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 getrlimit.c --- sysdeps/unix/sysv/linux/i386/getrlimit.c 2000/09/22 05:55:00 1.1.1.1 +++ sysdeps/unix/sysv/linux/i386/getrlimit.c 2000/09/22 06:14:41 @@ -48,6 +48,7 @@ __new_getrlimit (enum __rlimit_resource # ifdef __NR_ugetrlimit if (__have_no_new_getrlimit <= 0) { + int saved_errno = errno; result = INLINE_SYSCALL (ugetrlimit, 2, resource, CHECK_1 (rlimits)); /* If the system call is available remember this fact and return. */ @@ -57,6 +58,7 @@ __new_getrlimit (enum __rlimit_resource return result; } + __set_errno (saved_errno); /* Remember that the system call is not available. */ __have_no_new_getrlimit = 1; } Index: sysdeps/unix/sysv/linux/i386/lockf64.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/unix/sysv/linux/i386/lockf64.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 lockf64.c --- sysdeps/unix/sysv/linux/i386/lockf64.c 2000/09/22 05:55:01 1.1.1.1 +++ sysdeps/unix/sysv/linux/i386/lockf64.c 2000/09/22 06:15:48 @@ -95,6 +95,7 @@ lockf64 (int fd, int cmd, off64_t len64) # ifdef __NR_fcntl64 if (!__have_no_fcntl64) { + int saved_errno = errno; int res = INLINE_SYSCALL (fcntl64, 3, fd, F_GETLK64, &fl64); /* If errno == ENOSYS try the 32bit interface if len64 can @@ -108,7 +109,10 @@ lockf64 (int fd, int cmd, off64_t len64) return -1; } else if (errno == ENOSYS) - __have_no_fcntl64 = 1; + { + __set_errno (saved_errno); + __have_no_fcntl64 = 1; + } else /* res < 0 && errno != ENOSYS. */ return -1; @@ -169,6 +173,7 @@ lockf64 (int fd, int cmd, off64_t len64) if (!__have_no_fcntl64) { + int saved_errno = errno; int res = INLINE_SYSCALL (fcntl64, 3, fd, cmd64, &fl64); /* If errno == ENOSYS try the 32bit interface if len64 can @@ -176,6 +181,7 @@ lockf64 (int fd, int cmd, off64_t len64) if (res == 0 || errno != ENOSYS) return res; + __set_errno (saved_errno); __have_no_fcntl64 = 1; if (len64 != (off64_t) len) Index: sysdeps/unix/sysv/linux/i386/lxstat.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/unix/sysv/linux/i386/lxstat.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 lxstat.c --- sysdeps/unix/sysv/linux/i386/lxstat.c 2000/09/22 05:55:00 1.1.1.1 +++ sysdeps/unix/sysv/linux/i386/lxstat.c 2000/09/22 06:16:04 @@ -76,6 +76,7 @@ __lxstat (int vers, const char *name, st if (! __have_no_stat64) { struct stat64 buf64; + int saved_errno = errno; result = INLINE_SYSCALL (lstat64, 2, CHECK_STRING (name), __ptrvalue (&buf64)); if (result == 0) @@ -84,6 +85,7 @@ __lxstat (int vers, const char *name, st if (result != -1 || errno != ENOSYS) return result; + __set_errno (saved_errno); __have_no_stat64 = 1; } # endif Index: sysdeps/unix/sysv/linux/i386/seteuid.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/unix/sysv/linux/i386/seteuid.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 seteuid.c --- sysdeps/unix/sysv/linux/i386/seteuid.c 2000/09/22 05:55:00 1.1.1.1 +++ sysdeps/unix/sysv/linux/i386/seteuid.c 2000/09/22 06:17:30 @@ -32,13 +32,20 @@ seteuid (uid_t uid) int result; /* First try the syscall. */ #ifdef __NR_setresuid + int saved_errno = errno; result = __setresuid (-1, uid, -1); if (result == -1 && errno == ENOSYS) - /* No system call available. Use emulation. This may not work - since `setreuid' also sets the saved user ID when UID is not - equal to the real user ID, making it impossible to switch back. */ -#endif + { + /* No system call available. Use emulation. This may not work + since `setreuid' also sets the saved user ID when UID is not + equal to the real user ID, making it impossible to switch + back. */ + __set_errno (saved_errno); + result = __setreuid (-1, uid); + } +#else result = __setreuid (-1, uid); +#endif return result; } Index: sysdeps/unix/sysv/linux/i386/setrlimit.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/unix/sysv/linux/i386/setrlimit.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 setrlimit.c --- sysdeps/unix/sysv/linux/i386/setrlimit.c 2000/09/22 05:55:01 1.1.1.1 +++ sysdeps/unix/sysv/linux/i386/setrlimit.c 2000/09/22 06:20:26 @@ -49,10 +49,13 @@ __new_setrlimit (enum __rlimit_resource # ifdef __NR_ugetrlimit if (__have_no_new_getrlimit == 0) { + int saved_errno = errno; /* Check if the new ugetrlimit syscall exists. We must do this first because older kernels don't reject negative rlimit values in setrlimit. */ int result = INLINE_SYSCALL (ugetrlimit, 2, resource, __ptrvalue (&rlimits_small)); + + __set_errno (saved_errno); if (result != -1 || errno != ENOSYS) /* The syscall exists. */ __have_no_new_getrlimit = -1; Index: sysdeps/unix/sysv/linux/i386/xstat.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/unix/sysv/linux/i386/xstat.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 xstat.c --- sysdeps/unix/sysv/linux/i386/xstat.c 2000/09/22 05:55:01 1.1.1.1 +++ sysdeps/unix/sysv/linux/i386/xstat.c 2000/09/22 06:21:04 @@ -75,6 +75,7 @@ __xstat (int vers, const char *name, str if (! __have_no_stat64) { struct stat64 buf64; + int saved_errno = errno; result = INLINE_SYSCALL (stat64, 2, CHECK_STRING (name), __ptrvalue (&buf64)); @@ -84,6 +85,7 @@ __xstat (int vers, const char *name, str if (result != -1 || errno != ENOSYS) return result; + __set_errno (saved_errno); __have_no_stat64 = 1; } # endif Index: sysdeps/unix/sysv/linux/mips/pread.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/unix/sysv/linux/mips/pread.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 pread.c --- sysdeps/unix/sysv/linux/mips/pread.c 2000/09/22 05:55:02 1.1.1.1 +++ sysdeps/unix/sysv/linux/mips/pread.c 2000/09/22 06:21:55 @@ -46,14 +46,20 @@ __libc_pread (fd, buf, count, offset) off_t offset; { ssize_t result; +# if __ASSUME_PREAD_SYSCALL == 0 + int saved_errno = errno; +# endif /* First try the syscall. */ result = INLINE_SYSCALL (pread, 6, fd, CHECK_N (buf, count), count, 0, __LONG_LONG_PAIR (0, offset)); # if __ASSUME_PREAD_SYSCALL == 0 if (result == -1 && errno == ENOSYS) - /* No system call available. Use the emulation. */ - result = __emulate_pread (fd, buf, count, offset); + { + __set_errno (saved_errno); + /* No system call available. Use the emulation. */ + result = __emulate_pread (fd, buf, count, offset); + } # endif return result; } Index: sysdeps/unix/sysv/linux/mips/pread64.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/unix/sysv/linux/mips/pread64.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 pread64.c --- sysdeps/unix/sysv/linux/mips/pread64.c 2000/09/22 05:55:02 1.1.1.1 +++ sysdeps/unix/sysv/linux/mips/pread64.c 2000/09/22 06:22:28 @@ -47,6 +47,9 @@ __libc_pread64 (fd, buf, count, offset) off64_t offset; { ssize_t result; +# if __ASSUME_PREAD_SYSCALL == 0 + int saved_errno = errno; +# endif /* First try the syscall. */ result = INLINE_SYSCALL (pread, 6, fd, CHECK_N (buf, count), count, 0, @@ -54,8 +57,11 @@ __libc_pread64 (fd, buf, count, offset) (off_t) (offset & 0xffffffff))); # if __ASSUME_PREAD_SYSCALL == 0 if (result == -1 && errno == ENOSYS) - /* No system call available. Use the emulation. */ - result = __emulate_pread64 (fd, buf, count, offset); + { + __set_errno (saved_errno); + /* No system call available. Use the emulation. */ + result = __emulate_pread64 (fd, buf, count, offset); + } # endif return result; } Index: sysdeps/unix/sysv/linux/mips/pwrite.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/unix/sysv/linux/mips/pwrite.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 pwrite.c --- sysdeps/unix/sysv/linux/mips/pwrite.c 2000/09/22 05:55:02 1.1.1.1 +++ sysdeps/unix/sysv/linux/mips/pwrite.c 2000/09/22 06:22:58 @@ -45,14 +45,20 @@ __libc_pwrite (fd, buf, count, offset) off_t offset; { ssize_t result; +# if __ASSUME_PWRITE_SYSCALL == 0 + int saved_errno = errno; +# endif /* First try the syscall. */ result = INLINE_SYSCALL (pwrite, 6, fd, CHECK_N (buf, count), count, 0, __LONG_LONG_PAIR (0, offset)); # if __ASSUME_PWRITE_SYSCALL == 0 if (result == -1 && errno == ENOSYS) - /* No system call available. Use the emulation. */ - result = __emulate_pwrite (fd, buf, count, offset); + { + __set_errno (saved_errno); + /* No system call available. Use the emulation. */ + result = __emulate_pwrite (fd, buf, count, offset); + } # endif return result; Index: sysdeps/unix/sysv/linux/mips/pwrite64.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/unix/sysv/linux/mips/pwrite64.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 pwrite64.c --- sysdeps/unix/sysv/linux/mips/pwrite64.c 2000/09/22 05:55:02 1.1.1.1 +++ sysdeps/unix/sysv/linux/mips/pwrite64.c 2000/09/22 06:23:28 @@ -45,6 +45,9 @@ __libc_pwrite64 (fd, buf, count, offset) off64_t offset; { ssize_t result; +# if __ASSUME_PWRITE_SYSCALL == 0 + int saved_errno = errno; +# endif /* First try the syscall. */ result = INLINE_SYSCALL (pwrite, 6, fd, CHECK_N (buf, count), count, 0, @@ -52,8 +55,11 @@ __libc_pwrite64 (fd, buf, count, offset) (off_t) (offset & 0xffffffff))); # if __ASSUME_PWRITE_SYSCALL == 0 if (result == -1 && errno == ENOSYS) - /* No system call available. Use the emulation. */ - result = __emulate_pwrite64 (fd, buf, count, offset); + { + __set_errno (saved_errno); + /* No system call available. Use the emulation. */ + result = __emulate_pwrite64 (fd, buf, count, offset); + } # endif return result; Index: sysdeps/unix/sysv/linux/powerpc/chown.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/unix/sysv/linux/powerpc/chown.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 chown.c --- sysdeps/unix/sysv/linux/powerpc/chown.c 2000/09/22 05:55:03 1.1.1.1 +++ sysdeps/unix/sysv/linux/powerpc/chown.c 2000/09/22 06:25:27 @@ -66,14 +66,14 @@ __chown (const char *file, uid_t owner, err = __readlink (file, link, PATH_MAX+1); if (err == -1) { - errno = old_errno; + __set_errno (old_errno); return __lchown(file, owner, group); } filelen = strlen (file) + 1; if (filelen > sizeof(path)) { - errno = ENAMETOOLONG; + __set_errno (ENAMETOOLONG); return -1; } memcpy (path, file, filelen); @@ -86,7 +86,7 @@ __chown (const char *file, uid_t owner, if (err >= PATH_MAX+1) { - errno = ENAMETOOLONG; + __set_errno (ENAMETOOLONG); return -1; } @@ -106,7 +106,7 @@ __chown (const char *file, uid_t owner, filelen--; if (filelen + linklen > sizeof(path)) { - errno = ENAMETOOLONG; + __set_errno (ENAMETOOLONG); return -1; } memcpy (path+filelen, link, linklen); @@ -116,7 +116,7 @@ __chown (const char *file, uid_t owner, if (err == -1) { - errno = old_errno; + __set_errno (old_errno); return __lchown(path, owner, group); } } Index: sysdeps/unix/sysv/linux/powerpc/pread.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/unix/sysv/linux/powerpc/pread.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 pread.c --- sysdeps/unix/sysv/linux/powerpc/pread.c 2000/09/22 05:55:03 1.1.1.1 +++ sysdeps/unix/sysv/linux/powerpc/pread.c 2000/09/22 06:25:57 @@ -40,12 +40,16 @@ __libc_pread (fd, buf, count, offset) off_t offset; { ssize_t result; + int saved_errno = errno; /* First try the syscall. */ result = __syscall_pread (fd, buf, count, (off64_t) offset); if (result == -1 && errno == ENOSYS) - /* No system call available. Use the emulation. */ - result = __emulate_pread (fd, buf, count, offset); + { + __set_errno (saved_errno); + /* No system call available. Use the emulation. */ + result = __emulate_pread (fd, buf, count, offset); + } return result; } Index: sysdeps/unix/sysv/linux/powerpc/pread64.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/unix/sysv/linux/powerpc/pread64.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 pread64.c --- sysdeps/unix/sysv/linux/powerpc/pread64.c 2000/09/22 05:55:03 1.1.1.1 +++ sysdeps/unix/sysv/linux/powerpc/pread64.c 2000/09/22 06:26:20 @@ -40,12 +40,16 @@ __libc_pread64 (fd, buf, count, offset) off64_t offset; { ssize_t result; + int saved_errno = errno; /* First try the syscall. */ result = __syscall_pread (fd, buf, count, offset); if (result == -1 && errno == ENOSYS) - /* No system call available. Use the emulation. */ - result = __emulate_pread64 (fd, buf, count, offset); + { + __set_errno (saved_errno); + /* No system call available. Use the emulation. */ + result = __emulate_pread64 (fd, buf, count, offset); + } return result; } Index: sysdeps/unix/sysv/linux/powerpc/pwrite.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/unix/sysv/linux/powerpc/pwrite.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 pwrite.c --- sysdeps/unix/sysv/linux/powerpc/pwrite.c 2000/09/22 05:55:03 1.1.1.1 +++ sysdeps/unix/sysv/linux/powerpc/pwrite.c 2000/09/22 06:26:44 @@ -40,12 +40,16 @@ __libc_pwrite (fd, buf, count, offset) off_t offset; { ssize_t result; + int saved_errno = errno; /* First try the syscall. */ result = __syscall_pwrite (fd, buf, count, (off64_t) offset); if (result == -1 && errno == ENOSYS) - /* No system call available. Use the emulation. */ - result = __emulate_pwrite (fd, buf, count, offset); + { + __set_errno (saved_errno); + /* No system call available. Use the emulation. */ + result = __emulate_pwrite (fd, buf, count, offset); + } return result; } Index: sysdeps/unix/sysv/linux/powerpc/pwrite64.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/unix/sysv/linux/powerpc/pwrite64.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 pwrite64.c --- sysdeps/unix/sysv/linux/powerpc/pwrite64.c 2000/09/22 05:55:03 1.1.1.1 +++ sysdeps/unix/sysv/linux/powerpc/pwrite64.c 2000/09/22 06:27:05 @@ -40,12 +40,16 @@ __libc_pwrite64 (fd, buf, count, offset) off64_t offset; { ssize_t result; + int saved_errno = errno; /* First try the syscall. */ result = __syscall_pwrite (fd, buf, count, offset); if (result == -1 && errno == ENOSYS) - /* No system call available. Use the emulation. */ - result = __emulate_pwrite64 (fd, buf, count, offset); + { + __set_errno (saved_errno); + /* No system call available. Use the emulation. */ + result = __emulate_pwrite64 (fd, buf, count, offset); + } return result; } Index: sysdeps/unix/sysv/linux/sparc/sparc32/setegid.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/unix/sysv/linux/sparc/sparc32/setegid.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 setegid.c --- sysdeps/unix/sysv/linux/sparc/sparc32/setegid.c 2000/09/22 05:55:06 1.1.1.1 +++ sysdeps/unix/sysv/linux/sparc/sparc32/setegid.c 2000/09/22 06:27:56 @@ -29,6 +29,7 @@ int setegid (gid_t gid) { int result; + int saved_errno = errno; if (gid == (gid_t) ~0) { @@ -39,10 +40,14 @@ setegid (gid_t gid) /* First try the syscall. */ result = __setresgid (-1, gid, -1); if (result == -1 && errno == ENOSYS) - /* No system call available. Use emulation. This may not work - since `setregid' also sets the saved group ID when GID is not - equal to the real group ID, making it impossible to switch back. */ - result = __setregid (-1, gid); + { + /* No system call available. Use emulation. This may not work + since `setregid' also sets the saved group ID when GID is not + equal to the real group ID, making it impossible to switch + back. */ + __set_errno (saved_errno); + result = __setregid (-1, gid); + } return result; } Index: sysdeps/unix/sysv/linux/sparc/sparc32/seteuid.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/unix/sysv/linux/sparc/sparc32/seteuid.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 seteuid.c --- sysdeps/unix/sysv/linux/sparc/sparc32/seteuid.c 2000/09/22 05:55:06 1.1.1.1 +++ sysdeps/unix/sysv/linux/sparc/sparc32/seteuid.c 2000/09/22 06:28:28 @@ -42,10 +42,14 @@ seteuid (uid_t uid) result = __setresuid (-1, uid, -1); # if __ASSUME_SETRESUID_SYSCALL == 0 if (result == -1 && errno == ENOSYS) - /* No system call available. Use emulation. This may not work - since `setreuid' also sets the saved user ID when UID is not - equal to the real user ID, making it impossible to switch back. */ - result = __setreuid (-1, uid); + { + __set_errno (saved_errno); + /* No system call available. Use emulation. This may not work + since `setreuid' also sets the saved user ID when UID is not + equal to the real user ID, making it impossible to switch + back. */ + result = __setreuid (-1, uid); + } # endif return result; From schwab@suse.de Fri Sep 22 01:13:00 2000 From: schwab@suse.de (Andreas Schwab) Date: Fri, 22 Sep 2000 01:13:00 -0000 Subject: elm 2.5.3 and glibc 2.1.93 References: <20000921211643.A6161@lucon.org> Message-ID: <200009220813.e8M8DkR01945@hawking.suse.de> "H . J . Lu" writes: |> With glibc 2.1.93, I got |> |> # elm |> Cannot lock folder - giving up. Please try again in a few minutes. |> |> >From strace, I got |> |> open("/var/spool/mail/hjl", O_RDWR) = 4 |> fcntl64(4, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = -1 ENOSYS (Function not implemented) |> fcntl(4, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = 0 |> write(1, "\33[?1l\33>", 7^[[?1l^[>) = 7 |> write(1, "\33[24;1H\r\n", 9^[[24;1H^M) = 9 |> write(1, "\33[2J\33[?47l\0338", 12^[[2J^[[?47l^[8) = 12 |> ioctl(0, SNDCTL_TMR_STOP, {B9600 opost isig icanon echo ...}) = 0 |> write(2, "Cannot lock folder - giving up. "..., 67Cannot lock folder - giving up. Please try again in a few minutes.) = 67 |> |> It looks like elm 2.5.3 may check errno even when fcntl returns 0. This is broken. The value of errno is only defined if the syscall failed. Andreas. -- Andreas Schwab "And now for something SuSE Labs completely different." Andreas.Schwab@suse.de SuSE GmbH, Schanz????ckerstr. 10, D-90443 N????rnberg From jes@linuxcare.com Fri Sep 22 02:16:00 2000 From: jes@linuxcare.com (Jes Sorensen) Date: Fri, 22 Sep 2000 02:16:00 -0000 Subject: [ia64-tools] Re: Re: ia64 fenv patch. References: <20000920190828.A11605@valinux.com> <200009210851.e8L8piF25186@hawking.suse.de> <20000921072447.A1382@valinux.com> Message-ID: >>>>> "HJ" == H J Lu writes: HJ> On Thu, Sep 21, 2000 at 10:51:44AM +0200, Andreas Schwab wrote: >> What's wrong with this? Both expressions are equivalent. >> HJ> I have so many problems with those functions. I just copied them HJ> from ia32 :-(. Also it looks nicer :-). There was a reason why I put in most of the type casts in the beginning, you have to make sure that the C manipulations do not play the default truncate to int size. You claim in your patch that the logic was wrong - could you try and explain what was actually wrong instead of just saying something was wrong? It's somewhat hard to judge a patch if you don't try and tell us what it is trying to solve. Jes From jakub@redhat.com Fri Sep 22 05:05:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Fri, 22 Sep 2000 05:05:00 -0000 Subject: [PATCH] Missing __THROW in crypt.h Message-ID: <20000922140737.A11108@sunsite.ms.mff.cuni.cz> Hi! This patch makes it possible to include both crypt.h and unistd.h (or stdlib.h) together in a C++ program with _GNU_SOURCE. 2000-09-22 Jakub Jelinek * crypt/crypt.h (crypt, setkey, encrypt): Add __THROW. (crypt_r, setkey_r, encrypt_r): Likewise. --- libc/crypt/crypt.h.jj Sat Mar 4 01:47:30 2000 +++ libc/crypt/crypt.h Fri Sep 22 14:04:23 2000 @@ -30,14 +30,14 @@ __BEGIN_DECLS /* Encrypt at most 8 characters from KEY using salt to perturb DES. */ -extern char *crypt (__const char *__key, __const char *__salt); +extern char *crypt (__const char *__key, __const char *__salt) __THROW; /* Setup DES tables according KEY. */ -extern void setkey (__const char *__key); +extern void setkey (__const char *__key) __THROW; /* Encrypt data in BLOCK in place if EDFLAG is zero; otherwise decrypt block in place. */ -extern void encrypt (char *__block, int __edflag); +extern void encrypt (char *__block, int __edflag) __THROW; #ifdef __USE_GNU /* Reentrant versions of the functions above. The additional argument @@ -57,13 +57,13 @@ struct crypt_data }; extern char *crypt_r (__const char *__key, __const char *__salt, - struct crypt_data * __restrict __data); + struct crypt_data * __restrict __data) __THROW; extern void setkey_r (__const char *__key, - struct crypt_data * __restrict __data); + struct crypt_data * __restrict __data) __THROW; extern void encrypt_r (char *__block, int __edflag, - struct crypt_data * __restrict __data); + struct crypt_data * __restrict __data) __THROW; #endif __END_DECLS Jakub From bmark@us.ibm.com Fri Sep 22 06:36:00 2000 From: bmark@us.ibm.com (Mark Brown) Date: Fri, 22 Sep 2000 06:36:00 -0000 Subject: elm 2.5.3 and glibc 2.1.93 References: <20000921211643.A6161@lucon.org> Message-ID: <39CB6031.69BEAD9A@us.ibm.com> Hi- Elm may be broken. POSIX APIs are not required to "reset" errno when a successful return is indicated (unless they specifically say they do). Thus, elm shouldn't be checking for errno after a sucessful call. Mark "H . J . Lu" wrote: > > With glibc 2.1.93, I got > # elm > Cannot lock folder - giving up. Please try again in a few minutes. > > From strace, I got > > open("/var/spool/mail/hjl", O_RDWR) = 4 > fcntl64(4, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = -1 ENOSYS (Function not implemented) > fcntl(4, F_SETLK, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}) = 0 > write(1, "\33[?1l\33>", 7^[[?1l^[>) = 7 > write(1, "\33[24;1H\r\n", 9^[[24;1H^M) = 9 > write(1, "\33[2J\33[?47l\0338", 12^[[2J^[[?47l^[8) = 12 > ioctl(0, SNDCTL_TMR_STOP, {B9600 opost isig icanon echo ...}) = 0 > write(2, "Cannot lock folder - giving up. "..., 67Cannot lock folder - giving up. Please try again in a few minutes.) = 67 > > It looks like elm 2.5.3 may check errno even when fcntl returns 0. I > believe it is a glibc bug. Here is my patch. Someone please double > check if there are any more functions like that need fix. > > Thanks. > > H.J. > --- /work/gnu/import/libc/sysdeps/unix/sysv/linux/i386/fcntl.c Thu Sep 7 08:45:36 2000 > +++ ./fcntl.c Thu Sep 21 21:15:25 2000 > @@ -50,10 +50,13 @@ __libc_fcntl (int fd, int cmd, ...) > # ifdef __NR_fcntl64 > if (! __have_no_fcntl64) > { > + int saved_errno = errno; > int result = INLINE_SYSCALL (fcntl64, 3, fd, cmd, arg); > + > if (result >= 0 || errno != ENOSYS) > return result; > > + __set_errno (saved_errno); > __have_no_fcntl64 = 1; > } > # endif -- Mark S. Brown bmark@us.ibm.com Senior Technical Staff Member 512.838.3926 T/L678.3926 IBM RS/6000 AIX System Architecture Mark Brown/Austin/IBM IBM Corporation, Austin, Texas From hjl@lucon.org Fri Sep 22 07:31:00 2000 From: hjl@lucon.org (H . J . Lu) Date: Fri, 22 Sep 2000 07:31:00 -0000 Subject: elm 2.5.3 and glibc 2.1.93 References: <20000921211643.A6161@lucon.org> <200009220813.e8M8DkR01945@hawking.suse.de> Message-ID: <20000922073141.A20303@lucon.org> On Fri, Sep 22, 2000 at 10:13:46AM +0200, Andreas Schwab wrote: > |> > |> It looks like elm 2.5.3 may check errno even when fcntl returns 0. > > This is broken. The value of errno is only defined if the syscall failed. > Elm may be broken. But it is no excuse for glibc to mess with errno. H.J. From hjl@lucon.org Fri Sep 22 07:33:00 2000 From: hjl@lucon.org (H . J . Lu) Date: Fri, 22 Sep 2000 07:33:00 -0000 Subject: [ia64-tools] Re: Re: ia64 fenv patch. References: <20000920190828.A11605@valinux.com> <200009210851.e8L8piF25186@hawking.suse.de> <20000921072447.A1382@valinux.com> Message-ID: <20000922073351.B20303@lucon.org> On Fri, Sep 22, 2000 at 11:16:22AM +0200, Jes Sorensen wrote: > >>>>> "HJ" == H J Lu writes: > > HJ> On Thu, Sep 21, 2000 at 10:51:44AM +0200, Andreas Schwab wrote: > >> What's wrong with this? Both expressions are equivalent. > >> > > HJ> I have so many problems with those functions. I just copied them > HJ> from ia32 :-(. Also it looks nicer :-). > > There was a reason why I put in most of the type casts in the > beginning, you have to make sure that the C manipulations do not play > the default truncate to int size. If you do it right, it shouldn't be an issue. > > You claim in your patch that the logic was wrong - could you try and > explain what was actually wrong instead of just saying something was > wrong? It's somewhat hard to judge a patch if you don't try and tell > us what it is trying to solve. Have you tried to fix all those "make check" failures under ia64? H.J. From jakub@redhat.com Fri Sep 22 08:30:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Fri, 22 Sep 2000 08:30:00 -0000 Subject: elm 2.5.3 and glibc 2.1.93 References: <20000921211643.A6161@lucon.org> <200009220813.e8M8DkR01945@hawking.suse.de> <20000922073141.A20303@lucon.org> Message-ID: <20000922173328.B11108@sunsite.ms.mff.cuni.cz> On Fri, Sep 22, 2000 at 07:31:41AM -0700, H . J . Lu wrote: > On Fri, Sep 22, 2000 at 10:13:46AM +0200, Andreas Schwab wrote: > > |> > > |> It looks like elm 2.5.3 may check errno even when fcntl returns 0. > > > > This is broken. The value of errno is only defined if the syscall failed. > > > > Elm may be broken. But it is no excuse for glibc to mess with errno. Why should glibc work around bugs in broken packages? Jakub From hjl@lucon.org Fri Sep 22 08:47:00 2000 From: hjl@lucon.org (H . J . Lu) Date: Fri, 22 Sep 2000 08:47:00 -0000 Subject: elm 2.5.3 and glibc 2.1.93 References: <20000921211643.A6161@lucon.org> <200009220813.e8M8DkR01945@hawking.suse.de> <20000922073141.A20303@lucon.org> <20000922173328.B11108@sunsite.ms.mff.cuni.cz> Message-ID: <20000922084713.A20885@lucon.org> On Fri, Sep 22, 2000 at 05:33:28PM +0200, Jakub Jelinek wrote: > On Fri, Sep 22, 2000 at 07:31:41AM -0700, H . J . Lu wrote: > > On Fri, Sep 22, 2000 at 10:13:46AM +0200, Andreas Schwab wrote: > > > |> > > > |> It looks like elm 2.5.3 may check errno even when fcntl returns 0. > > > > > > This is broken. The value of errno is only defined if the syscall failed. > > > > > > > Elm may be broken. But it is no excuse for glibc to mess with errno. > > Why should glibc work around bugs in broken packages? > Take a look at glibc and ask why we have to save/restore errno all over places where we support both new and old system calls. There are reasons behind that. I don't recall the details. Someone may remember it. H.J. From aj@suse.de Fri Sep 22 09:00:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Fri, 22 Sep 2000 09:00:00 -0000 Subject: elm 2.5.3 and glibc 2.1.93 References: <20000921211643.A6161@lucon.org> <200009220813.e8M8DkR01945@hawking.suse.de> <20000922073141.A20303@lucon.org> <20000922173328.B11108@sunsite.ms.mff.cuni.cz> <20000922084713.A20885@lucon.org> Message-ID: >>>>> H J Lu writes: > On Fri, Sep 22, 2000 at 05:33:28PM +0200, Jakub Jelinek wrote: >> On Fri, Sep 22, 2000 at 07:31:41AM -0700, H . J . Lu wrote: >> > On Fri, Sep 22, 2000 at 10:13:46AM +0200, Andreas Schwab wrote: >> > > |> >> > > |> It looks like elm 2.5.3 may check errno even when fcntl returns 0. >> > > >> > > This is broken. The value of errno is only defined if the syscall failed. >> > > >> > >> > Elm may be broken. But it is no excuse for glibc to mess with errno. >> >> Why should glibc work around bugs in broken packages? >> > Take a look at glibc and ask why we have to save/restore errno all > over places where we support both new and old system calls. There are > reasons behind that. I don't recall the details. Someone may remember > it. Initially we used to save/restore errno, later we noticed that this is not needed. All new code (at least code that Ulrich and I recently added) doesn't save/restore errno - only older code does. I agree, we should unify this, but so far nobody spoke up. Btw. this issue of saving/restoring errno has been discussed already on the list and we came to the conclusion that it's not needed in this situation. elm seems to be broken, glibc is fine. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From hjl@lucon.org Fri Sep 22 09:09:00 2000 From: hjl@lucon.org (H . J . Lu) Date: Fri, 22 Sep 2000 09:09:00 -0000 Subject: elm 2.5.3 and glibc 2.1.93 References: <20000921211643.A6161@lucon.org> <200009220813.e8M8DkR01945@hawking.suse.de> <20000922073141.A20303@lucon.org> <20000922173328.B11108@sunsite.ms.mff.cuni.cz> <20000922084713.A20885@lucon.org> Message-ID: <20000922090949.A27119@lucon.org> On Fri, Sep 22, 2000 at 05:52:01PM +0200, Andreas Jaeger wrote: > > > Take a look at glibc and ask why we have to save/restore errno all > > over places where we support both new and old system calls. There are > > reasons behind that. I don't recall the details. Someone may remember > > it. > Initially we used to save/restore errno, later we noticed that this is > not needed. All new code (at least code that Ulrich and I recently > added) doesn't save/restore errno - only older code does. I agree, we > should unify this, but so far nobody spoke up. > > Btw. this issue of saving/restoring errno has been discussed already > on the list and we came to the conclusion that it's not needed in this > situation. It has been a while since I ran vsx. Has anyone else ever tried vsx on glibc? H.J. From hjl@lucon.org Fri Sep 22 09:16:00 2000 From: hjl@lucon.org (H . J . Lu) Date: Fri, 22 Sep 2000 09:16:00 -0000 Subject: elm 2.5.3 and glibc 2.1.93 References: <20000921211643.A6161@lucon.org> <200009220813.e8M8DkR01945@hawking.suse.de> <20000922073141.A20303@lucon.org> <20000922173328.B11108@sunsite.ms.mff.cuni.cz> <20000922084713.A20885@lucon.org> Message-ID: <20000922091644.B27119@lucon.org> On Fri, Sep 22, 2000 at 05:52:01PM +0200, Andreas Jaeger wrote: > Initially we used to save/restore errno, later we noticed that this is > not needed. All new code (at least code that Ulrich and I recently > added) doesn't save/restore errno - only older code does. I agree, we > should unify this, but so far nobody spoke up. > I think it is a bad idea. If we believe it is ok not to save/restore errno, we should do it for all functions. I can provide a patch if we are 100% sure that it is ok to do so. H.J. From hjl@lucon.org Fri Sep 22 09:40:00 2000 From: hjl@lucon.org (H . J . Lu) Date: Fri, 22 Sep 2000 09:40:00 -0000 Subject: elm 2.5.3 and glibc 2.1.93 References: <20000921211643.A6161@lucon.org> <200009220813.e8M8DkR01945@hawking.suse.de> <20000922073141.A20303@lucon.org> <20000922173328.B11108@sunsite.ms.mff.cuni.cz> <20000922084713.A20885@lucon.org> Message-ID: <20000922093954.A27377@lucon.org> On Fri, Sep 22, 2000 at 05:52:01PM +0200, Andreas Jaeger wrote: > > > Take a look at glibc and ask why we have to save/restore errno all > > over places where we support both new and old system calls. There are > > reasons behind that. I don't recall the details. Someone may remember > > it. > Initially we used to save/restore errno, later we noticed that this is > not needed. All new code (at least code that Ulrich and I recently > added) doesn't save/restore errno - only older code does. I agree, we > should unify this, but so far nobody spoke up. > > Btw. this issue of saving/restoring errno has been discussed already > on the list and we came to the conclusion that it's not needed in this > situation. > This is from glibc texinfo: The initial value of `errno' at program startup is zero. Many library functions are guaranteed to set it to certain nonzero values when they encounter certain kinds of errors. These error conditions are listed for each function. These functions do not change `errno' when they succeed; thus, the value of `errno' after a successful call is not necessarily zero, and you should not use `errno' to determine _whether_ a call failed. The proper way to do that is documented for each function. _If_ the call failed, you can examine `errno'. Many library functions can set `errno' to a nonzero value as a result of calling other library functions which might fail. You should assume that any library function might alter `errno' when the function returns an error. >From here, I conclude "The glibc functions do not change `errno' when they succeed." By not saving/restoring errno, we have changed documented glibc behavior. We should be consistent on it. H.J. From hjl@lucon.org Fri Sep 22 09:49:00 2000 From: hjl@lucon.org (H . J . Lu) Date: Fri, 22 Sep 2000 09:49:00 -0000 Subject: elm 2.5.3 and glibc 2.1.93 References: <20000921211643.A6161@lucon.org> <200009220813.e8M8DkR01945@hawking.suse.de> <20000922073141.A20303@lucon.org> <20000922173328.B11108@sunsite.ms.mff.cuni.cz> <20000922084713.A20885@lucon.org> <20000922093954.A27377@lucon.org> Message-ID: <20000922094929.A27517@lucon.org> On Fri, Sep 22, 2000 at 09:39:54AM -0700, H . J . Lu wrote: > > >From here, I conclude "The glibc functions do not change `errno' when > they succeed." By not saving/restoring errno, we have changed > documented glibc behavior. We should be consistent on it. > One possible glibc code may look like: if (foo (....) == -1) { if (bar (...) == -1) exit (1); switch (errno) { case xxx: break; case xxx: break; default: /* Ooops, unknown error. Quit. */ exit (2); } } Since bar () may change errno now, this perfect valid glibc code may not work right now. I will guess this code will work on most of other Unixes. H.J. From drepper@redhat.com Fri Sep 22 10:27:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Fri, 22 Sep 2000 10:27:00 -0000 Subject: elm 2.5.3 and glibc 2.1.93 References: <20000921211643.A6161@lucon.org> <200009220813.e8M8DkR01945@hawking.suse.de> <20000922073141.A20303@lucon.org> <20000922173328.B11108@sunsite.ms.mff.cuni.cz> <20000922084713.A20885@lucon.org> <20000922093954.A27377@lucon.org> Message-ID: "H . J . Lu" writes: > >From here, I conclude "The glibc functions do not change `errno' when > they succeed." By not saving/restoring errno, we have changed > documented glibc behavior. We should be consistent on it. I've not written this and it is a stupid assumption. errno must be changeable. Everything depending on errno not being changed is broken. There are exceptions: strtol() etc. But nothing else. The reason is simply that the user must not make any assuptions about the implementation. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From hjl@lucon.org Fri Sep 22 10:40:00 2000 From: hjl@lucon.org (H . J . Lu) Date: Fri, 22 Sep 2000 10:40:00 -0000 Subject: elm 2.5.3 and glibc 2.1.93 References: <20000921211643.A6161@lucon.org> <200009220813.e8M8DkR01945@hawking.suse.de> <20000922073141.A20303@lucon.org> <20000922173328.B11108@sunsite.ms.mff.cuni.cz> <20000922084713.A20885@lucon.org> <20000922093954.A27377@lucon.org> Message-ID: <20000922103956.A27944@lucon.org> On Fri, Sep 22, 2000 at 10:27:46AM -0700, Ulrich Drepper wrote: > "H . J . Lu" writes: > > > >From here, I conclude "The glibc functions do not change `errno' when > > they succeed." By not saving/restoring errno, we have changed > > documented glibc behavior. We should be consistent on it. > > I've not written this and it is a stupid assumption. errno must be You may not have written it. But it is there and used to be accurate. Users may do many stupid things. But I won't call reading and following the glibc manual is stupid. What I am afraid of is elm may not be the only one. H.J. From drepper@redhat.com Fri Sep 22 10:57:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Fri, 22 Sep 2000 10:57:00 -0000 Subject: [PATCH] Missing __THROW in crypt.h References: <20000922140737.A11108@sunsite.ms.mff.cuni.cz> Message-ID: Jakub Jelinek writes: > 2000-09-22 Jakub Jelinek > > * crypt/crypt.h (crypt, setkey, encrypt): Add __THROW. > (crypt_r, setkey_r, encrypt_r): Likewise. OK. Andreas, could you add it? -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From aj@suse.de Fri Sep 22 11:03:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Fri, 22 Sep 2000 11:03:00 -0000 Subject: [PATCH] Missing __THROW in crypt.h References: <20000922140737.A11108@sunsite.ms.mff.cuni.cz> Message-ID: >>>>> Ulrich Drepper writes: > Jakub Jelinek writes: >> 2000-09-22 Jakub Jelinek >> >> * crypt/crypt.h (crypt, setkey, encrypt): Add __THROW. >> (crypt_r, setkey_r, encrypt_r): Likewise. > OK. Andreas, could you add it? Yes, will do now, Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From bmark@us.ibm.com Fri Sep 22 11:52:00 2000 From: bmark@us.ibm.com (Mark Brown) Date: Fri, 22 Sep 2000 11:52:00 -0000 Subject: elm 2.5.3 and glibc 2.1.93 References: <20000921211643.A6161@lucon.org> <200009220813.e8M8DkR01945@hawking.suse.de> <20000922073141.A20303@lucon.org> <20000922173328.B11108@sunsite.ms.mff.cuni.cz> <20000922084713.A20885@lucon.org> <20000922093954.A27377@lucon.org> Message-ID: <39CBAA6F.CD942F5E@us.ibm.com> "H . J . Lu" wrote: > Many library functions can set `errno' to a nonzero value as a > result of calling other library functions which might fail. You > should assume that any library function might alter `errno' when > the function returns an error. > > From here, I conclude "The glibc functions do not change `errno' when > they succeed." By not saving/restoring errno, we have changed > documented glibc behavior. We should be consistent on it. This doesn't follow. The text immediately above yours says that successful routines *can* change errno inadvertantly, and that you should not depend on errno *unless* the call reports failure. Mark -- Mark S. Brown bmark@us.ibm.com Senior Technical Staff Member 512.838.3926 T/L678.3926 IBM RS/6000 AIX System Architecture Mark Brown/Austin/IBM IBM Corporation, Austin, Texas From hjl@lucon.org Fri Sep 22 12:03:00 2000 From: hjl@lucon.org (H . J . Lu) Date: Fri, 22 Sep 2000 12:03:00 -0000 Subject: elm 2.5.3 and glibc 2.1.93 References: <20000921211643.A6161@lucon.org> <200009220813.e8M8DkR01945@hawking.suse.de> <20000922073141.A20303@lucon.org> <20000922173328.B11108@sunsite.ms.mff.cuni.cz> <20000922084713.A20885@lucon.org> <20000922093954.A27377@lucon.org> <39CBAA6F.CD942F5E@us.ibm.com> Message-ID: <20000922120351.A28723@lucon.org> On Fri, Sep 22, 2000 at 01:52:32PM -0500, Mark Brown wrote: > > > "H . J . Lu" wrote: > > Many library functions can set `errno' to a nonzero value as a > > result of calling other library functions which might fail. You > > should assume that any library function might alter `errno' when > > the function returns an error. > > > > From here, I conclude "The glibc functions do not change `errno' when > > they succeed." By not saving/restoring errno, we have changed > > documented glibc behavior. We should be consistent on it. > > This doesn't follow. The text immediately above yours says that successful > routines *can* change errno inadvertantly, and that you should not depend > on errno *unless* the call reports failure. This is straight from manual/texi: --- The initial value of @code{errno} at program startup is zero. Many library functions are guaranteed to set it to certain nonzero values when they encounter certain kinds of errors. These error conditions are listed for each function. These functions do not change @code{errno} when they succeed; --- I have quoted it in my previous email. Did I read it wrong? H.J. From bmark@us.ibm.com Fri Sep 22 13:29:00 2000 From: bmark@us.ibm.com (Mark Brown) Date: Fri, 22 Sep 2000 13:29:00 -0000 Subject: elm 2.5.3 and glibc 2.1.93 References: <20000921211643.A6161@lucon.org> <200009220813.e8M8DkR01945@hawking.suse.de> <20000922073141.A20303@lucon.org> <20000922173328.B11108@sunsite.ms.mff.cuni.cz> <20000922084713.A20885@lucon.org> <20000922093954.A27377@lucon.org> <39CBAA6F.CD942F5E@us.ibm.com> <20000922120351.A28723@lucon.org> Message-ID: <39CBC116.CBBAAF2D@us.ibm.com> "H . J . Lu" wrote: > The initial value of @code{errno} at program startup is zero. Many > library functions are guaranteed to set it to certain nonzero values > when they encounter certain kinds of errors. These error conditions are > listed for each function. These functions do not change @code{errno} > when they succeed; > --- > > I have quoted it in my previous email. Did I read it wrong? Nope, I apologize -- but that last sentence is both bad and wrong, IMHO. -- Mark S. Brown bmark@us.ibm.com Senior Technical Staff Member 512.838.3926 T/L678.3926 IBM RS/6000 AIX System Architecture Mark Brown/Austin/IBM IBM Corporation, Austin, Texas From hjl@lucon.org Fri Sep 22 13:41:00 2000 From: hjl@lucon.org (H . J . Lu) Date: Fri, 22 Sep 2000 13:41:00 -0000 Subject: elm 2.5.3 and glibc 2.1.93 References: <20000921211643.A6161@lucon.org> <200009220813.e8M8DkR01945@hawking.suse.de> <20000922073141.A20303@lucon.org> <20000922173328.B11108@sunsite.ms.mff.cuni.cz> <20000922084713.A20885@lucon.org> <20000922093954.A27377@lucon.org> <39CBAA6F.CD942F5E@us.ibm.com> <20000922120351.A28723@lucon.org> <39CBC116.CBBAAF2D@us.ibm.com> Message-ID: <20000922134054.A29402@lucon.org> On Fri, Sep 22, 2000 at 03:29:10PM -0500, Mark Brown wrote: > > > "H . J . Lu" wrote: > > The initial value of @code{errno} at program startup is zero. Many > > library functions are guaranteed to set it to certain nonzero values > > when they encounter certain kinds of errors. These error conditions are > > listed for each function. These functions do not change @code{errno} > > when they succeed; > > --- > > > > I have quoted it in my previous email. Did I read it wrong? > > Nope, I apologize -- but that last sentence is both bad and wrong, IMHO. > Right or wrong. It is the documented glibc behavior and used to be accurates. If we changed it, some applications may not work right. H.J. From kettenis@wins.uva.nl Sat Sep 23 06:19:00 2000 From: kettenis@wins.uva.nl (Mark Kettenis) Date: Sat, 23 Sep 2000 06:19:00 -0000 Subject: elm 2.5.3 and glibc 2.1.93 References: <20000921211643.A6161@lucon.org> <200009220813.e8M8DkR01945@hawking.suse.de> <20000922073141.A20303@lucon.org> <20000922173328.B11108@sunsite.ms.mff.cuni.cz> <20000922084713.A20885@lucon.org> <20000922093954.A27377@lucon.org> <39CBAA6F.CD942F5E@us.ibm.com> <20000922120351.A28723@lucon.org> <39CBC116.CBBAAF2D@us.ibm.com> Message-ID: <200009231319.e8NDJXq00529@delius.kettenis.local> Date: Fri, 22 Sep 2000 15:29:10 -0500 From: Mark Brown "H . J . Lu" wrote: > The initial value of @code{errno} at program startup is zero. Many > library functions are guaranteed to set it to certain nonzero values > when they encounter certain kinds of errors. These error conditions are > listed for each function. These functions do not change @code{errno} > when they succeed; > --- > > I have quoted it in my previous email. Did I read it wrong? Nope, I apologize -- but that last sentence is both bad and wrong, IMHO. There is some confusion between ISO C and POSIX here. The copy of the ISC C 9X draft I have here says (7.5 Errors ): [#3] The value of errno is zero at program startup, but is never set to zero by any library function.159) The value of errno may be set to nonzero by a library function call whether or not there is an error, provided the use of errno is not documented in the description of the function in this International Standard. Which implies that if errno is documented for an ISO C function, it may not be set to non-zero by a successfull call of function. That's probably what led to the bit of text in the glibc documentation that HJ quoted. The Austin draft clearly states that (2.3 Error Numbers): The value of errno should only be examined when it is indicated to be valid by a function's return value. I assume that this is equivalent to what the current POSIX standard says. Since fcntl is not an ISO C function, its current behaviour is perfectly fine, and elm isn't a POSIX conforming application and should be fixed. Somebody, preferably a native speaker, should probably clarify the glibc manual on this issue. Mark From hjl@lucon.org Sat Sep 23 08:45:00 2000 From: hjl@lucon.org (H . J . Lu) Date: Sat, 23 Sep 2000 08:45:00 -0000 Subject: elm 2.5.3 and glibc 2.1.93 References: <200009220813.e8M8DkR01945@hawking.suse.de> <20000922073141.A20303@lucon.org> <20000922173328.B11108@sunsite.ms.mff.cuni.cz> <20000922084713.A20885@lucon.org> <20000922093954.A27377@lucon.org> <39CBAA6F.CD942F5E@us.ibm.com> <20000922120351.A28723@lucon.org> <39CBC116.CBBAAF2D@us.ibm.com> <200009231319.e8NDJXq00529@delius.kettenis.local> Message-ID: <20000923084519.A4138@lucon.org> On Sat, Sep 23, 2000 at 03:19:33PM +0200, Mark Kettenis wrote: > The Austin draft clearly states that (2.3 Error Numbers): > > The value of errno should only be examined when it is indicated to > be valid by a function's return value. > > I assume that this is equivalent to what the current POSIX standard > says. > > Since fcntl is not an ISO C function, its current behaviour is > perfectly fine, and elm isn't a POSIX conforming application and > should be fixed. > > Somebody, preferably a native speaker, should probably clarify the > glibc manual on this issue. > See the code segment in http://sources.redhat.com/ml/libc-hacker/2000-09/msg00148.html It doesn't violate any standard if glibc doesn't change errno for successful return as stated in the glibc manual. For the better or worse, we just cannot change the documented glibc behavior unless we have a really good reason. Otherwise, we can just delete the whole glibc manual since it doesn't mean anything and the glibc behavior can change at any time. Please think what it meanes to the Linux application developers. At least, we will lose any credibility we have in the glibc manual. We cannot even tell them "read and follow the glibc manual." What does it tell the world? I'd like to remove all bunch of old compatibilty stuff in glibc. Why cannot we do that? Rememeber for some projects, changing the source for the glibc change may not be acceptable. They may not even have the source code. Even if they do, it may not be changed so easily. H.J. From hjl@lucon.org Sat Sep 23 09:22:00 2000 From: hjl@lucon.org (H . J . Lu) Date: Sat, 23 Sep 2000 09:22:00 -0000 Subject: ISO C and errno Message-ID: <20000923092159.A4539@lucon.org> If ISO C says errno is unchanged for a succesful return, there are many ISO C functions in glibc call the none ISO C system calls which change errno in the current glibc. H.J. From kettenis@wins.uva.nl Sat Sep 23 09:37:00 2000 From: kettenis@wins.uva.nl (Mark Kettenis) Date: Sat, 23 Sep 2000 09:37:00 -0000 Subject: elm 2.5.3 and glibc 2.1.93 References: <200009220813.e8M8DkR01945@hawking.suse.de> <20000922073141.A20303@lucon.org> <20000922173328.B11108@sunsite.ms.mff.cuni.cz> <20000922084713.A20885@lucon.org> <20000922093954.A27377@lucon.org> <39CBAA6F.CD942F5E@us.ibm.com> <20000922120351.A28723@lucon.org> <39CBC116.CBBAAF2D@us.ibm.com> <200009231319.e8NDJXq00529@delius.kettenis.local> <20000923084519.A4138@lucon.org> Message-ID: <200009231637.e8NGbIj00862@delius.kettenis.local> Date: Sat, 23 Sep 2000 08:45:19 -0700 From: "H . J . Lu" On Sat, Sep 23, 2000 at 03:19:33PM +0200, Mark Kettenis wrote: > The Austin draft clearly states that (2.3 Error Numbers): > > The value of errno should only be examined when it is indicated to > be valid by a function's return value. > > I assume that this is equivalent to what the current POSIX standard > says. > > Since fcntl is not an ISO C function, its current behaviour is > perfectly fine, and elm isn't a POSIX conforming application and > should be fixed. > > Somebody, preferably a native speaker, should probably clarify the > glibc manual on this issue. > See the code segment in http://sources.redhat.com/ml/libc-hacker/2000-09/msg00148.html That code is broken. It probably works on most Unixes if bar is a system call, but if it isn't, it is likely to fail on quite a few of them. It doesn't violate any standard if glibc doesn't change errno for successful return as stated in the glibc manual. For the better or worse, we just cannot change the documented glibc behavior unless we have a really good reason. Otherwise, we can just delete the whole glibc manual since it doesn't mean anything and the glibc behavior can change at any time. Changing errno can be a rather expensive operation. Please think what it meanes to the Linux application developers. At least, we will lose any credibility we have in the glibc manual. We cannot even tell them "read and follow the glibc manual." What does it tell the world? My copy of the manual says that: ... you should not use `errno' to determine _whether_ a call failed. The proper way to do that is documented for each function. _If_ the call the failed, you can examine `errno'. So people who have been reading the manual should not have written incorrect code. It is true that the language in the manual is contradictory. That is a bug in the manual and should be fixed in the manual. Not by penalizing correctly written code. Mark From kettenis@wins.uva.nl Sat Sep 23 09:44:00 2000 From: kettenis@wins.uva.nl (Mark Kettenis) Date: Sat, 23 Sep 2000 09:44:00 -0000 Subject: ISO C and errno References: <20000923092159.A4539@lucon.org> Message-ID: <200009231644.e8NGiJO00877@delius.kettenis.local> Date: Sat, 23 Sep 2000 09:21:59 -0700 From: "H . J . Lu" If ISO C says errno is unchanged for a succesful return, there are many ISO C functions in glibc call the none ISO C system calls which change errno in the current glibc. Only ISO C functions that are documented to store an error value in errno are required to leave it alone if they return successfully. Those functions should save and restore errno if necessary, and AFAIK they do so. Mark From hjl@lucon.org Sat Sep 23 09:44:00 2000 From: hjl@lucon.org (H . J . Lu) Date: Sat, 23 Sep 2000 09:44:00 -0000 Subject: elm 2.5.3 and glibc 2.1.93 References: <20000922173328.B11108@sunsite.ms.mff.cuni.cz> <20000922084713.A20885@lucon.org> <20000922093954.A27377@lucon.org> <39CBAA6F.CD942F5E@us.ibm.com> <20000922120351.A28723@lucon.org> <39CBC116.CBBAAF2D@us.ibm.com> <200009231319.e8NDJXq00529@delius.kettenis.local> <20000923084519.A4138@lucon.org> <200009231637.e8NGbIj00862@delius.kettenis.local> Message-ID: <20000923094406.A4690@lucon.org> On Sat, Sep 23, 2000 at 06:37:18PM +0200, Mark Kettenis wrote: > My copy of the manual says that: > > ... you should not use `errno' to determine _whether_ a call > failed. The proper way to do that is documented for each > function. _If_ the call the failed, you can examine `errno'. > Read my code again. It does just that. It only assumes errno is unchanged when bar () returns 0 since glibc manual says so. H.J. From hjl@lucon.org Sat Sep 23 09:45:00 2000 From: hjl@lucon.org (H . J . Lu) Date: Sat, 23 Sep 2000 09:45:00 -0000 Subject: elm 2.5.3 and glibc 2.1.93 References: <20000922173328.B11108@sunsite.ms.mff.cuni.cz> <20000922084713.A20885@lucon.org> <20000922093954.A27377@lucon.org> <39CBAA6F.CD942F5E@us.ibm.com> <20000922120351.A28723@lucon.org> <39CBC116.CBBAAF2D@us.ibm.com> <200009231319.e8NDJXq00529@delius.kettenis.local> <20000923084519.A4138@lucon.org> <200009231637.e8NGbIj00862@delius.kettenis.local> Message-ID: <20000923094527.B4690@lucon.org> On Sat, Sep 23, 2000 at 06:37:18PM +0200, Mark Kettenis wrote: > Date: Sat, 23 Sep 2000 08:45:19 -0700 > From: "H . J . Lu" > > On Sat, Sep 23, 2000 at 03:19:33PM +0200, Mark Kettenis wrote: > > The Austin draft clearly states that (2.3 Error Numbers): > > > > The value of errno should only be examined when it is indicated to > > be valid by a function's return value. > > > > I assume that this is equivalent to what the current POSIX standard > > says. > > > > Since fcntl is not an ISO C function, its current behaviour is > > perfectly fine, and elm isn't a POSIX conforming application and > > should be fixed. > > Please remember many ISO C functions in glibc may call fcntl (). What do you want to do with them? H.J. From drepper@redhat.com Sat Sep 23 10:11:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Sat, 23 Sep 2000 10:11:00 -0000 Subject: ISO C and errno References: <20000923092159.A4539@lucon.org> <200009231644.e8NGiJO00877@delius.kettenis.local> Message-ID: Mark Kettenis writes: > Only ISO C functions that are documented to store an error value in > errno are required to leave it alone if they return successfully. > Those functions should save and restore errno if necessary, and AFAIK > they do so. The only functions in ISO C which use errno are the math functions and strto*(). They do the right thing. I don't know why you continue hitting on this. Wrong code cannot be expected to run. It only means that writing compatible applications is harder since you don't see some bugs. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From hjl@lucon.org Sat Sep 23 10:21:00 2000 From: hjl@lucon.org (H . J . Lu) Date: Sat, 23 Sep 2000 10:21:00 -0000 Subject: ISO C and errno References: <20000923092159.A4539@lucon.org> <200009231644.e8NGiJO00877@delius.kettenis.local> Message-ID: <20000923102145.A5008@lucon.org> On Sat, Sep 23, 2000 at 10:11:47AM -0700, Ulrich Drepper wrote: > > I don't know why you continue hitting on this. Wrong code cannot be > expected to run. It only means that writing compatible applications > is harder since you don't see some bugs. It is written that way only because the glibc manual says it is ok to do so. Can you blame the application developers for that? Please keep in mind sometimes it is not that easy to change the source code even if it is available. It may bring bad reputations to glibc and Linux as we are getting into the corporate world. I simply cannot tell the application developers that oops, we made a mistake in the glibc manual, you have to change your code. It is ok to remove those wordings in the new glibc manual. It doesn't mean we can abandon the existing applications. I have been defending glibc for a long time. With changes like this, it makes harder and harder for me to do so. H.J. From drepper@redhat.com Sat Sep 23 10:23:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Sat, 23 Sep 2000 10:23:00 -0000 Subject: ISO C and errno References: <20000923092159.A4539@lucon.org> <200009231644.e8NGiJO00877@delius.kettenis.local> <20000923102145.A5008@lucon.org> Message-ID: "H . J . Lu" writes: > It is written that way only because the glibc manual says it is ok to > do so. No. Elm people don't read the manual. Definitely not. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From kukuk@suse.de Sat Sep 23 12:59:00 2000 From: kukuk@suse.de (Thorsten Kukuk) Date: Sat, 23 Sep 2000 12:59:00 -0000 Subject: sunrpc/svc_udp.c (IP_PKTINFO) broken Message-ID: <20000923215934.A21878@suse.de> Hi, the following patch: 2000-02-17 H.J. Lu * sunrpc/rpc/svc.h (SVCXPRT): Add a "xp_pad" field at the end. * sunrpc/svc_udp.c (svcudp_bufcreate): Turn on IP_PKTINFO if available. (svcudp_recv): Set up message with the new "xp_pad" field for IP_PKTINFO. (svcudp_reply): Support IP_PKTINFO if available. breaks RPC/udp connections on SPARC. Run ypbind on SPARC and try to run ypwhich to reproduce it. Can anybody look at it who knows something about IP_PKTINFO ? Has anybody tested this on other architectures ? If not, we should revert it before we release final 2.2. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background. From hjl@lucon.org Sat Sep 23 17:39:00 2000 From: hjl@lucon.org (H . J . Lu) Date: Sat, 23 Sep 2000 17:39:00 -0000 Subject: sunrpc/svc_udp.c (IP_PKTINFO) broken References: <20000923215934.A21878@suse.de> Message-ID: <20000923173912.B7842@lucon.org> On Sat, Sep 23, 2000 at 09:59:34PM +0200, Thorsten Kukuk wrote: > > Hi, > > the following patch: > > 2000-02-17 H.J. Lu > > * sunrpc/rpc/svc.h (SVCXPRT): Add a "xp_pad" field at the end. > > * sunrpc/svc_udp.c (svcudp_bufcreate): Turn on IP_PKTINFO if > available. > (svcudp_recv): Set up message with the new "xp_pad" field for > IP_PKTINFO. > (svcudp_reply): Support IP_PKTINFO if available. > > breaks RPC/udp connections on SPARC. Run ypbind on SPARC and > try to run ypwhich to reproduce it. > Can anybody look at it who knows something about IP_PKTINFO ? > Has anybody tested this on other architectures ? We have been using it on ia32 with glibc 2.1. Otherwise, RPC over UDP won't work with IP aliases cross a firwall. I will check it out on ia32 with glibc 2.2 next week. > If not, we should revert it before we release final 2.2. H.J. From kukuk@suse.de Sat Sep 23 22:25:00 2000 From: kukuk@suse.de (Thorsten Kukuk) Date: Sat, 23 Sep 2000 22:25:00 -0000 Subject: sunrpc/svc_udp.c (IP_PKTINFO) broken References: <20000923215934.A21878@suse.de> <20000923173912.B7842@lucon.org> Message-ID: <20000924072520.A17218@suse.de> On Sat, Sep 23, H . J . Lu wrote: > On Sat, Sep 23, 2000 at 09:59:34PM +0200, Thorsten Kukuk wrote: > > > > Hi, > > > > the following patch: > > > > 2000-02-17 H.J. Lu > > > > * sunrpc/rpc/svc.h (SVCXPRT): Add a "xp_pad" field at the end. > > > > * sunrpc/svc_udp.c (svcudp_bufcreate): Turn on IP_PKTINFO if > > available. > > (svcudp_recv): Set up message with the new "xp_pad" field for > > IP_PKTINFO. > > (svcudp_reply): Support IP_PKTINFO if available. > > > > breaks RPC/udp connections on SPARC. Run ypbind on SPARC and > > try to run ypwhich to reproduce it. > > Can anybody look at it who knows something about IP_PKTINFO ? > > Has anybody tested this on other architectures ? > > We have been using it on ia32 with glibc 2.1. Otherwise, RPC over UDP > won't work with IP aliases cross a firwall. I will check it out on > ia32 with glibc 2.2 next week. It works fine on ia32. It does not work on sparc and sparc64. I don't know if it is a bigendian problem or if IP_PKTINFO does not work on SPARC. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background. From hjl@lucon.org Sun Sep 24 00:14:00 2000 From: hjl@lucon.org (H . J . Lu) Date: Sun, 24 Sep 2000 00:14:00 -0000 Subject: sunrpc/svc_udp.c (IP_PKTINFO) broken References: <20000923215934.A21878@suse.de> <20000923173912.B7842@lucon.org> <20000924072520.A17218@suse.de> Message-ID: <20000924001404.A10291@lucon.org> On Sun, Sep 24, 2000 at 07:25:20AM +0200, Thorsten Kukuk wrote: > On Sat, Sep 23, H . J . Lu wrote: > > > On Sat, Sep 23, 2000 at 09:59:34PM +0200, Thorsten Kukuk wrote: > > > > > > Hi, > > > > > > the following patch: > > > > > > 2000-02-17 H.J. Lu > > > > > > * sunrpc/rpc/svc.h (SVCXPRT): Add a "xp_pad" field at the end. > > > > > > * sunrpc/svc_udp.c (svcudp_bufcreate): Turn on IP_PKTINFO if > > > available. > > > (svcudp_recv): Set up message with the new "xp_pad" field for > > > IP_PKTINFO. > > > (svcudp_reply): Support IP_PKTINFO if available. > > > > > > breaks RPC/udp connections on SPARC. Run ypbind on SPARC and > > > try to run ypwhich to reproduce it. > > > Can anybody look at it who knows something about IP_PKTINFO ? > > > Has anybody tested this on other architectures ? > > > > We have been using it on ia32 with glibc 2.1. Otherwise, RPC over UDP > > won't work with IP aliases cross a firwall. I will check it out on > > ia32 with glibc 2.2 next week. > > It works fine on ia32. It does not work on sparc and sparc64. I > don't know if it is a bigendian problem or if IP_PKTINFO does not > work on SPARC. Can you find out why IP_PKTINFO doesn't work on sparc? As far as I can remember, IP_PKTINFO doesn't do much. My patch only keeps what it is received and sends it back verbatim. The only thing I can think of is alignment. H.J. From kukuk@suse.de Sun Sep 24 02:00:00 2000 From: kukuk@suse.de (Thorsten Kukuk) Date: Sun, 24 Sep 2000 02:00:00 -0000 Subject: 32/64bit glibc and header files Message-ID: <20000924110005.A1970@suse.de> Hi, If we have on a system a 32bit and a 64bit version of glibc (for example on UltraSPARC), we have different paths for the libraries. gcc has a switch for using 32 or 64bit. But what should we do with the header files ? As far as I can see there is only one directory (/usr/include) for both versions. On UltraSPARC we have at least 5 header files which are not the same on 32bit and 64bit systems (bits/endian.h [no real problem], bits/siginfo.h, bits/syscall.h, gnu/stubs.h and ieee754.h). Is there any solution ? Can gcc search in different subdirectories depending if I use -m32 or -m 64 ? Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background. From kukuk@suse.de Sun Sep 24 02:04:00 2000 From: kukuk@suse.de (Thorsten Kukuk) Date: Sun, 24 Sep 2000 02:04:00 -0000 Subject: glibc 2.1.94 bootstraping Message-ID: <20000924110415.B1970@suse.de> Hi, With glibc 2.1.94 bootstraping without installed /usr/lib/crt*.o files is not possible. The locale stuff needs them. Is it possible to fix this so that we use the new glibc ones and not old installed one ? Can it make any trouble if we use crt*.o from glibc 2.1.x building glibc 2.2 ? Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background. From drepper@redhat.com Sun Sep 24 07:49:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Sun, 24 Sep 2000 07:49:00 -0000 Subject: 32/64bit glibc and header files References: <20000924110005.A1970@suse.de> Message-ID: Thorsten Kukuk writes: > same on 32bit and 64bit systems (bits/endian.h [no real problem], > bits/siginfo.h, bits/syscall.h, gnu/stubs.h and ieee754.h). > > Is there any solution ? Can gcc search in different subdirectories > depending if I use -m32 or -m 64 ? All these headers should have appropriate #ifs to recognize the current platform. This is already done in some/most/all? places. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Sun Sep 24 07:50:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Sun, 24 Sep 2000 07:50:00 -0000 Subject: glibc 2.1.94 bootstraping References: <20000924110415.B1970@suse.de> Message-ID: Thorsten Kukuk writes: > With glibc 2.1.94 bootstraping without installed /usr/lib/crt*.o > files is not possible. The locale stuff needs them. This is not enough information. What happens? > Can it make any trouble if we use crt*.o from glibc 2.1.x building > glibc 2.2 ? Possibly. I don't know in the moment. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From kukuk@suse.de Sun Sep 24 09:11:00 2000 From: kukuk@suse.de (Thorsten Kukuk) Date: Sun, 24 Sep 2000 09:11:00 -0000 Subject: glibc 2.1.94 bootstraping References: <20000924110415.B1970@suse.de> Message-ID: <20000924181129.A16839@suse.de> On Sun, Sep 24, Ulrich Drepper wrote: > Thorsten Kukuk writes: > > > With glibc 2.1.94 bootstraping without installed /usr/lib/crt*.o > > files is not possible. The locale stuff needs them. > > This is not enough information. What happens? If you don't have /usr/lib/crt*.o files installed from an old glibc version, make fails in iconvdata. It couldn't find the crt files for creating the shared libraries. Seems it only fails in iconvdata, the other shared libraries could be created. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background. From drepper@redhat.com Sun Sep 24 09:11:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Sun, 24 Sep 2000 09:11:00 -0000 Subject: ldconfig stuff Message-ID: I was looking (admittedly the first time) closely at the ldconfig code. There are a few things which I do not really like: - in search dir, whenever a directory is seen it is immediately processed. This is semantically not necessary and not beneficial for the performance. The directories should be queued and then processed once the current directory is done. - the use of chroot seems unnecessary. We know when ldconfig uses a filename whether it has to be interpreted with the prefix or not. chroot() is quite nice but has the problems of not being available everywhere and also requiring the use of ldconfig by root (which hits me personally since installing in my chroot() test environment should work without being root). It would be nice if somebody could look into this. I've already added some code in ldconfig to make more use of d_type information. Please take a look at the change since this kind of use is repeating in many places. This little change reduced the number of syscals made by a ldconfig run in my minimal chroot() environment from 629 to 543. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From aj@suse.de Sun Sep 24 09:41:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Sun, 24 Sep 2000 09:41:00 -0000 Subject: ldconfig stuff References: Message-ID: >>>>> Ulrich Drepper writes: > I was looking (admittedly the first time) closely at the ldconfig > code. There are a few things which I do not really like: > - in search dir, whenever a directory is seen it is immediately processed. > This is semantically not necessary and not beneficial for the performance. > The directories should be queued and then processed once the current > directory is done. Here's a patch, I might look later into the other problem. Ok to commit? Andreas 2000-09-24 Andreas Jaeger * elf/ldconfig.c (add_dir): Move logic to add entry to list to new function add_single_dir. (add_single_dir): New function. (search_dir): Use add_single_dir instead of recursing. ============================================================ Index: elf/ldconfig.c --- elf/ldconfig.c 2000/09/24 16:02:59 1.6 +++ elf/ldconfig.c 2000/09/24 16:36:44 @@ -258,12 +258,42 @@ "Andreas Jaeger"); } +/* Add a single directory entry. */ +static void +add_single_dir (struct dir_entry *entry, int verbose) +{ + struct dir_entry *ptr, *prev; + + ptr = dir_entries; + prev = ptr; + while (ptr != NULL) + { + /* Check for duplicates. */ + if (strcmp (ptr->path, entry->path) == 0) + { + if (opt_verbose && verbose) + error (0, 0, _("Path `%s' given more than once"), entry->path); + /* Use the newer information. */ + ptr->flag = entry->flag; + free (entry); + break; + } + prev = ptr; + ptr = ptr->next; + } + /* Is this the first entry? */ + if (ptr == NULL && dir_entries == NULL) + dir_entries = entry; + else if (ptr == NULL) + prev->next = entry; +} + /* Add one directory to the list of directories to process. */ static void add_dir (const char *line) { char *equal_sign; - struct dir_entry *entry, *ptr, *prev; + struct dir_entry *entry; unsigned int i; entry = xmalloc (sizeof (struct dir_entry)); @@ -299,28 +329,7 @@ --i; } - ptr = dir_entries; - prev = ptr; - while (ptr != NULL) - { - /* Check for duplicates. */ - if (strcmp (ptr->path, entry->path) == 0) - { - if (opt_verbose) - error (0, 0, _("Path `%s' given more than once"), entry->path); - /* Use the newer information. */ - ptr->flag = entry->flag; - free (entry); - break; - } - prev = ptr; - ptr = ptr->next; - } - /* Is this the first entry? */ - if (ptr == NULL && dir_entries == NULL) - dir_entries = entry; - else if (ptr == NULL) - prev->next = entry; + add_single_dir (entry, 1); } @@ -571,12 +580,15 @@ if (S_ISDIR (stat_buf.st_mode) && is_hwcap (direntry->d_name)) { - /* Handle subdirectory also, make a recursive call. */ - struct dir_entry new_entry; - new_entry.path = buf; - new_entry.flag = entry->flag; - new_entry.next = NULL; - search_dir (&new_entry); + /* Handle subdirectory later. */ + struct dir_entry *new_entry; + + new_entry = xmalloc (sizeof (struct dir_entry)); + + new_entry->path = buf; + new_entry->flag = entry->flag; + new_entry->next = NULL; + add_single_dir (new_entry, 0); continue; } else if (!S_ISREG (stat_buf.st_mode) && !S_ISLNK (stat_buf.st_mode)) -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From kukuk@suse.de Sun Sep 24 10:52:00 2000 From: kukuk@suse.de (Thorsten Kukuk) Date: Sun, 24 Sep 2000 10:52:00 -0000 Subject: Problem with ldconfig References: Message-ID: <20000924195203.A29212@suse.de> On Tue, Sep 19, Andreas Jaeger wrote: > Here's a patch that also changes cache_file_new. 64 bit experts, > please check that all alignments are proper in the two structs - or do > you like to see changes? > > Thorsten, please tell me whether this fixes the problems you noticed > on sparc. Seems to fix my problems on SPARC until yet. I found some more problems, but none which depend on ldconfig. Thorsten > > Andreas > > 2000-09-19 Andreas Jaeger > > * sysdeps/generic/dl-cache.h: Include stdint.h. > (struct file_entry_new): Use fixed sizes for interoperability > between 32bit and 64bit systems, add __unused to make alignment > explicit. > (CACHE_VERSION): Increment. > (struct cache_file_new): Use fixed sizes, add one more unused > entry to make alignment explicit. -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background. From hjl@lucon.org Sun Sep 24 11:06:00 2000 From: hjl@lucon.org (H . J . Lu) Date: Sun, 24 Sep 2000 11:06:00 -0000 Subject: glibc 2.1.94 bootstraping References: <20000924110415.B1970@suse.de> <20000924181129.A16839@suse.de> Message-ID: <20000924110633.A3906@lucon.org> On Sun, Sep 24, 2000 at 06:11:29PM +0200, Thorsten Kukuk wrote: > On Sun, Sep 24, Ulrich Drepper wrote: > > > Thorsten Kukuk writes: > > > > > With glibc 2.1.94 bootstraping without installed /usr/lib/crt*.o > > > files is not possible. The locale stuff needs them. > > > > This is not enough information. What happens? > > If you don't have /usr/lib/crt*.o files installed from an old glibc > version, make fails in iconvdata. It couldn't find the crt files > for creating the shared libraries. Seems it only fails in iconvdata, > the other shared libraries could be created. That is strange. My build doesn't use any /usr/lib/crt*.o. # gcc -pipe -mcpu=pentiumpro -march=pentiumpro -shared -o /work/build/gnu/bin/glibc/iconvdata/EUC-TW.so -Wl,-dynamic-linker=/lib/ld-linux.so.2 -B/work/build/gnu/bin/glibc/csu/ -Wl,-rpath,'$ORIGIN' -L/work/build/gnu/bin/glibc -L/work/build/gnu/bin/glibc/math -L/work/build/gnu/bin/glibc/elf -L/work/build/gnu/bin/glibc/dlfcn -L/work/build/gnu/bin/glibc/nss -L/work/build/gnu/bin/glibc/nis -L/work/build/gnu/bin/glibc/rt -L/work/build/gnu/bin/glibc/resolv -L/work/build/gnu/bin/glibc/crypt -L/work/build/gnu/bin/glibc/linuxthreads -Wl,-rpath-link=/work/build/gnu/bin/glibc:/work/build/gnu/bin/glibc/math:/work/build/gnu/bin/glibc/elf:/work/build/gnu/bin/glibc/dlfcn:/work/build/gnu/bin/glibc/nss:/work/build/gnu/bin/glibc/nis:/work/build/gnu/bin/glibc/rt:/work/build/gnu/bin/glibc/resolv:/work/build/gnu/bin/glibc/crypt:/work/build/gnu/bin/glibc/linuxthreads -Wl,--whole-archive /work/build/gnu/bin/glibc/iconvdata/euc-tw.os /work/build/gnu/bin/glibc/iconvdata/libCNS.so /work/build/gnu/bin/glibc/libc.so -Wl,--no-whole-archive -Wl,-v collect2 version 2.96 20000731 (Red Hat Linux 7.0) (i386 Linux/ELF) /usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../../i386-redhat-linux/bin/ld -m elf_i386 -shared -o /work/build/gnu/bin/glibc/iconvdata/EUC-TW.so /work/build/gnu/bin/glibc/csu/crti.o /usr/lib/gcc-lib/i386-redhat-linux/2.96/crtbeginS.o -L/work/build/gnu/bin/glibc -L/work/build/gnu/bin/glibc/math -L/work/build/gnu/bin/glibc/elf -L/work/build/gnu/bin/glibc/dlfcn -L/work/build/gnu/bin/glibc/nss -L/work/build/gnu/bin/glibc/nis -L/work/build/gnu/bin/glibc/rt -L/work/build/gnu/bin/glibc/resolv -L/work/build/gnu/bin/glibc/crypt -L/work/build/gnu/bin/glibc/linuxthreads -L/work/build/gnu/bin/glibc/csu -L/usr/lib/gcc-lib/i386-redhat-linux/2.96 -L/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../../../i386-redhat-linux/lib -L/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../.. -dynamic-linker=/lib/ld-linux.so.2 -rpath $ORIGIN -rpath-link=/work/build/gnu/bin/glibc:/work/build/gnu/bin/glibc/math:/work/build/gnu/bin/glibc/elf:/work/build/gnu/bin/glibc/dlfcn:/work/build/gnu/bin/glibc/nss:/work/build/gnu/bin/glibc/nis:/work/build/gnu/bin/glibc/rt:/work/build/gnu/bin/glibc/resolv:/work/build/gnu/bin/glibc/crypt:/work/build/gnu/bin/glibc/linuxthreads --whole-archive /work/build/gnu/bin/glibc/iconvdata/euc-tw.os /work/build/gnu/bin/glibc/iconvdata/libCNS.so /work/build/gnu/bin/glibc/libc.so --no-whole-archive -v -lgcc -lc -lgcc /usr/lib/gcc-lib/i386-redhat-linux/2.96/crtendS.o /work/build/gnu/bin/glibc/csu/crtn.o H.J. From drepper@redhat.com Sun Sep 24 11:24:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Sun, 24 Sep 2000 11:24:00 -0000 Subject: glibc 2.1.94 bootstraping References: <20000924110415.B1970@suse.de> <20000924181129.A16839@suse.de> Message-ID: Thorsten Kukuk writes: > If you don't have /usr/lib/crt*.o files installed from an old glibc > version, make fails in iconvdata. It couldn't find the crt files > for creating the shared libraries. Seems it only fails in iconvdata, > the other shared libraries could be created. The crt files are build in the first pass, the shared libs in iconvdata in the second. What do you do differently? -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Sun Sep 24 11:26:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Sun, 24 Sep 2000 11:26:00 -0000 Subject: ldconfig stuff References: Message-ID: Andreas Jaeger writes: > Here's a patch, I might look later into the other problem. > > Ok to commit? Yep. Thanks for the fast reaction. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From aj@suse.de Sun Sep 24 11:32:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Sun, 24 Sep 2000 11:32:00 -0000 Subject: Problem with ldconfig References: <20000924195203.A29212@suse.de> Message-ID: >>>>> Thorsten Kukuk writes: > On Tue, Sep 19, Andreas Jaeger wrote: >> Here's a patch that also changes cache_file_new. 64 bit experts, >> please check that all alignments are proper in the two structs - or do >> you like to see changes? >> >> Thorsten, please tell me whether this fixes the problems you noticed >> on sparc. > Seems to fix my problems on SPARC until yet. I found some more problems, > but none which depend on ldconfig. OK, I'll commit the patch now, Thanks, Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From drepper@redhat.com Sun Sep 24 12:00:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Sun, 24 Sep 2000 12:00:00 -0000 Subject: A patch for malloc typo References: <20000919115233.A10665@valinux.com> <20000919125509.A29516@valinux.com> Message-ID: "H . J . Lu" writes: > This patch should have no impact on generated binaries. It just makes > the code less confusing. How can this have no impact? All programs which use the memalign hook will break since the documented order in which size and alignment are passed is changed. Admittedly I don't expect many programs to use this feature but cleanup is no reason to break something. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From hjl@lucon.org Sun Sep 24 12:09:00 2000 From: hjl@lucon.org (H . J . Lu) Date: Sun, 24 Sep 2000 12:09:00 -0000 Subject: A patch for malloc typo References: <20000919115233.A10665@valinux.com> <20000919125509.A29516@valinux.com> Message-ID: <20000924120948.A14805@lucon.org> On Sun, Sep 24, 2000 at 12:00:55PM -0700, Ulrich Drepper wrote: > "H . J . Lu" writes: > > > This patch should have no impact on generated binaries. It just makes > > the code less confusing. > > How can this have no impact? All programs which use the memalign hook > will break since the documented order in which size and alignment are > passed is changed. Admittedly I don't expect many programs to use > this feature but cleanup is no reason to break something. > That is exactly what I meant by "less confusing". You are mislead by the prototype. Check out how __memalign_hook is used in malloc. Please remember user doesn't call __memalign_hook () directly. He/she only defines __memalign_hook (). mEMALIGn () in malloc.c does: if (__memalign_hook != NULL) { ... result = (*__memalign_hook)(alignment, bytes, ...); } It doesn't matter what the prototype says. H.J. From schwab@suse.de Mon Sep 25 01:20:00 2000 From: schwab@suse.de (Andreas Schwab) Date: Mon, 25 Sep 2000 01:20:00 -0000 Subject: elm 2.5.3 and glibc 2.1.93 References: <20000922173328.B11108@sunsite.ms.mff.cuni.cz> <20000922084713.A20885@lucon.org> <20000922093954.A27377@lucon.org> <39CBAA6F.CD942F5E@us.ibm.com> <20000922120351.A28723@lucon.org> <39CBC116.CBBAAF2D@us.ibm.com> <200009231319.e8NDJXq00529@delius.kettenis.local> <20000923084519.A4138@lucon.org> <200009231637.e8NGbIj00862@delius.kettenis.local> <20000923094406.A4690@lucon.org> Message-ID: <200009250820.e8P8Kcp23523@hawking.suse.de> "H . J . Lu" writes: |> On Sat, Sep 23, 2000 at 06:37:18PM +0200, Mark Kettenis wrote: |> > My copy of the manual says that: |> > |> > ... you should not use `errno' to determine _whether_ a call |> > failed. The proper way to do that is documented for each |> > function. _If_ the call the failed, you can examine `errno'. |> > |> |> Read my code again. It does just that. It only assumes errno is |> unchanged when bar () returns 0 since glibc manual says so. And this is what is _broken_, and always has been. Andreas. -- Andreas Schwab "And now for something SuSE Labs completely different." Andreas.Schwab@suse.de SuSE GmbH, Schanz????ckerstr. 10, D-90443 N????rnberg From schwab@suse.de Mon Sep 25 01:21:00 2000 From: schwab@suse.de (Andreas Schwab) Date: Mon, 25 Sep 2000 01:21:00 -0000 Subject: elm 2.5.3 and glibc 2.1.93 References: <20000922173328.B11108@sunsite.ms.mff.cuni.cz> <20000922084713.A20885@lucon.org> <20000922093954.A27377@lucon.org> <39CBAA6F.CD942F5E@us.ibm.com> <20000922120351.A28723@lucon.org> <39CBC116.CBBAAF2D@us.ibm.com> <200009231319.e8NDJXq00529@delius.kettenis.local> <20000923084519.A4138@lucon.org> <200009231637.e8NGbIj00862@delius.kettenis.local> <20000923094527.B4690@lucon.org> Message-ID: <200009250821.e8P8LLq23532@hawking.suse.de> "H . J . Lu" writes: |> Please remember many ISO C functions in glibc may call fcntl (). What |> do you want to do with them? Nothing. Andreas. -- Andreas Schwab "And now for something SuSE Labs completely different." Andreas.Schwab@suse.de SuSE GmbH, Schanz????ckerstr. 10, D-90443 N????rnberg From jes@linuxcare.com Mon Sep 25 08:06:00 2000 From: jes@linuxcare.com (Jes Sorensen) Date: Mon, 25 Sep 2000 08:06:00 -0000 Subject: [ia64-tools] Re: Re: ia64 fenv patch. References: <20000920190828.A11605@valinux.com> <200009210851.e8L8piF25186@hawking.suse.de> <20000921072447.A1382@valinux.com> <20000922073351.B20303@lucon.org> Message-ID: >>>>> "HJ" == H J Lu writes: HJ> On Fri, Sep 22, 2000 at 11:16:22AM +0200, Jes Sorensen wrote: >> You claim in your patch that the logic was wrong - could you try >> and explain what was actually wrong instead of just saying >> something was wrong? It's somewhat hard to judge a patch if you >> don't try and tell us what it is trying to solve. HJ> Have you tried to fix all those "make check" failures under ia64? Not recently, I normally run make tests - however my point was that when you post a bug report it would be much more productive if you wrote something like 'wrong bits masked resulting in bleh not being enabled' instead of just 'logic is wrong'. With the latter one can read you patch and actually see what you're trying to fix which is not always obvious the other way 'round. Jes From jakub@redhat.com Tue Sep 26 01:03:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Tue, 26 Sep 2000 01:03:00 -0000 Subject: 32/64bit glibc and header files References: <20000924110005.A1970@suse.de> Message-ID: <20000926100706.C11108@sunsite.ms.mff.cuni.cz> On Sun, Sep 24, 2000 at 07:49:15AM -0700, Ulrich Drepper wrote: > Thorsten Kukuk writes: > > > same on 32bit and 64bit systems (bits/endian.h [no real problem], > > bits/siginfo.h, bits/syscall.h, gnu/stubs.h and ieee754.h). > > > > Is there any solution ? Can gcc search in different subdirectories > > depending if I use -m32 or -m 64 ? > > All these headers should have appropriate #ifs to recognize the > current platform. This is already done in some/most/all? places. Thorsten is right with these, I'll work on a patch. It will be harder with bits/syscall.h and gnu/stubs.h (because they are generated) and ieee754.h (probably I'll just copy the ldbl-128 version to sysdeps/sparc/sparc32) though. Jakub From kukuk@suse.de Tue Sep 26 01:16:00 2000 From: kukuk@suse.de (Thorsten Kukuk) Date: Tue, 26 Sep 2000 01:16:00 -0000 Subject: nscd syslog fix Message-ID: <20000926101609.A11950@suse.de> Hi, nscd calls syslog without format string in the logging function. You cannot use it for an exploit, but a normal user can crash nscd if it runs with logging enabled. Here is the fix: 2000-09-26 Thorsten Kukuk * nscd/dbg_log.c(dbg_log): Add missing format string --- nscd/dbg_log.c 1998/10/18 15:02:56 1.3 +++ nscd/dbg_log.c 2000/09/26 08:01:25 @@ -61,7 +61,7 @@ else { snprintf (msg, sizeof (msg), "%d: %s", getpid (), msg2); - syslog (LOG_NOTICE, msg); + syslog (LOG_NOTICE, "%s", msg); } va_end (ap); } -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background. From drepper@redhat.com Tue Sep 26 02:35:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Tue, 26 Sep 2000 02:35:00 -0000 Subject: nscd syslog fix References: <20000926101609.A11950@suse.de> Message-ID: Thorsten Kukuk writes: > nscd calls syslog without format string in the logging function. > You cannot use it for an exploit, but a normal user can crash nscd > if it runs with logging enabled. Here is the fix: Thanks, I'm adding it now. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From jes@linuxcare.com Tue Sep 26 06:22:00 2000 From: jes@linuxcare.com (Jes Sorensen) Date: Tue, 26 Sep 2000 06:22:00 -0000 Subject: libm compiler warnings Message-ID: <200009261322.PAA30974@lxplus015.cern.ch> Hi When compiling libm under Linux/ia64 I get a bunch of warnings about implicit declarations of a bunch of math functions and a single warning about missing parantheses in ldbl-96/e_atan2l.c. It wasn't quite obvious if the prototypes for the missing functions should go in math.h or math_private.h so I stuck them in math_private.h but feel free to move them if I am wrong. Jes 2000-09-26 Jes Sorensen * sysdeps/ieee754/ldbl-96/e_atan2l.c (__ieee754_atan2l): Add parentheses around arithmetic used in | statement to kill compiler warning. * math/math_private.h: Add prototype for __finitel. __ilogbl: ditto. __isinfl: ditto. __isnanl: ditto. __atanl: ditto. __copysignl: ditto. __expm1l: ditto. __floorl: ditto. __frexpl: ditto. __ldexpl: ditto. __log1pl: ditto. __nanl: ditto. __rintl: ditto. __scalbnl: ditto. __sqrtl: ditto. fabsl: ditto. __sincosl: ditto. diff -urN --exclude=*.mo --exclude=manual --exclude=CVS --exclude=*~ --exclude=*.rej /home/jes/cygnus/libc-2.2/math/math_private.h libc-2.2/math/math_private.h --- /home/jes/cygnus/libc-2.2/math/math_private.h Sat Oct 9 23:21:01 1999 +++ libc-2.2/math/math_private.h Tue Sep 26 14:48:34 2000 @@ -267,4 +267,23 @@ extern int __kernel_rem_pio2l (long double*,long double*,int,int, int,const int*); +/* prototypes required to compile the ldbl-96 support without warnings */ +extern int __finitel (long double); +extern int __ilogbl(long double); +extern int __isinfl (long double); +extern int __isnanl(long double); +extern long double __atanl (long double); +extern long double __copysignl(long double, long double); +extern long double __expm1l (long double); +extern long double __floorl(long double); +extern long double __frexpl(long double, int *); +extern long double __ldexpl(long double, int); +extern long double __log1pl (long double); +extern long double __nanl (const char *); +extern long double __rintl(long double); +extern long double __scalbnl (long double, int); +extern long double __sqrtl(long double x); +extern long double fabsl(long double x); +extern void __sincosl (long double, long double *, long double *); + #endif /* _MATH_PRIVATE_H_ */ diff -urN --exclude=*.mo --exclude=manual --exclude=CVS --exclude=*~ --exclude=*.rej /home/jes/cygnus/libc-2.2/sysdeps/ieee754/ldbl-96/e_atan2l.c libc-2.2/sysdeps/ieee754/ldbl-96/e_atan2l.c --- /home/jes/cygnus/libc-2.2/sysdeps/ieee754/ldbl-96/e_atan2l.c Wed Jul 14 02:11:20 1999 +++ libc-2.2/sysdeps/ieee754/ldbl-96/e_atan2l.c Tue Sep 26 14:33:24 2000 @@ -80,7 +80,7 @@ if(((2*ix|((lx|-lx)>>31))>0xfffe)|| ((2*iy|((ly|-ly)>>31))>0xfffe)) /* x or y is NaN */ return x+y; - if((sx-0x3fff|lx)==0) return __atanl(y); /* x=1.0 */ + if(((sx-0x3fff)|lx)==0) return __atanl(y); /* x=1.0 */ m = ((sy>>15)&1)|((sx>>14)&2); /* 2*sign(x)+sign(y) */ /* when y = 0 */ From schwab@suse.de Tue Sep 26 06:24:00 2000 From: schwab@suse.de (Andreas Schwab) Date: Tue, 26 Sep 2000 06:24:00 -0000 Subject: collate_output: Assertion `idx[cnt] % 4 == 0' failed. Message-ID: <200009261324.e8QDOLi14465@hawking.suse.de> ld-collate.c requires an alignment of 4 when previous items where only aligned at __alignof__ (int32_t). The latter is 2 on m68k-linux, thus the assertion may fail. 2000-09-26 Andreas Schwab * locale/programs/ld-collate.c (collate_output): Only require alignment on __alignof__ (int32_t) instead of 4. * locale/loadlocale.c (_nl_load_locale): Likewise. * string/strcoll.c: Likewise. Index: locale/loadlocale.c =================================================================== RCS file: /cvs/glibc/libc/locale/loadlocale.c,v retrieving revision 1.37 diff -u -a -u -r1.37 locale/loadlocale.c --- locale/loadlocale.c 2000/09/01 02:23:48 1.37 +++ locale/loadlocale.c 2000/09/26 11:43:30 @@ -217,7 +217,7 @@ } if (__builtin_expect (_nl_value_types[category][cnt] == word, 0)) { - assert (idx % 4 == 0); + assert (idx % __alignof__ (u_int32_t) == 0); newdata->values[cnt].word = *((u_int32_t *) (newdata->filedata + idx)); } Index: locale/programs/ld-collate.c =================================================================== RCS file: /cvs/glibc/libc/locale/programs/ld-collate.c,v retrieving revision 1.86 diff -u -a -u -r1.86 locale/programs/ld-collate.c --- locale/programs/ld-collate.c 2000/09/11 20:32:13 1.86 +++ locale/programs/ld-collate.c 2000/09/26 11:43:46 @@ -2204,21 +2204,21 @@ iov[2 + cnt].iov_base = NULL; iov[2 + cnt].iov_len = 0; idx[1 + cnt] = idx[cnt] + iov[2 + cnt].iov_len; - assert (idx[cnt] % 4 == 0); + assert (idx[cnt] % __alignof__ (int32_t) == 0); ++cnt; assert (cnt == _NL_ITEM_INDEX (_NL_COLLATE_GAP2)); iov[2 + cnt].iov_base = NULL; iov[2 + cnt].iov_len = 0; idx[1 + cnt] = idx[cnt] + iov[2 + cnt].iov_len; - assert (idx[cnt] % 4 == 0); + assert (idx[cnt] % __alignof__ (int32_t) == 0); ++cnt; assert (cnt == _NL_ITEM_INDEX (_NL_COLLATE_GAP3)); iov[2 + cnt].iov_base = NULL; iov[2 + cnt].iov_len = 0; idx[1 + cnt] = idx[cnt] + iov[2 + cnt].iov_len; - assert (idx[cnt] % 4 == 0); + assert (idx[cnt] % __alignof__ (int32_t) == 0); ++cnt; /* Since we are using the sign of an integer to mark indirection the @@ -2368,7 +2368,7 @@ iov[2 + cnt].iov_len = tablewc.result_size; idx[1 + cnt] = idx[cnt] + iov[2 + cnt].iov_len; assert (iov[2 + cnt].iov_len % sizeof (int32_t) == 0); - assert (idx[cnt] % 4 == 0); + assert (idx[cnt] % __alignof__ (int32_t) == 0); ++cnt; assert (cnt == _NL_ITEM_INDEX (_NL_COLLATE_WEIGHTWC)); @@ -2376,7 +2376,7 @@ iov[2 + cnt].iov_base = obstack_finish (&weightpool); idx[1 + cnt] = idx[cnt] + iov[2 + cnt].iov_len; assert (iov[2 + cnt].iov_len % sizeof (int32_t) == 0); - assert (idx[cnt] % 4 == 0); + assert (idx[cnt] % __alignof__ (int32_t) == 0); ++cnt; assert (cnt == _NL_ITEM_INDEX (_NL_COLLATE_EXTRAWC)); @@ -2384,7 +2384,7 @@ iov[2 + cnt].iov_base = obstack_finish (&extrapool); idx[1 + cnt] = idx[cnt] + iov[2 + cnt].iov_len; assert (iov[2 + cnt].iov_len % sizeof (int32_t) == 0); - assert (idx[cnt] % 4 == 0); + assert (idx[cnt] % __alignof__ (int32_t) == 0); ++cnt; assert (cnt == _NL_ITEM_INDEX (_NL_COLLATE_INDIRECTWC)); @@ -2392,7 +2392,7 @@ iov[2 + cnt].iov_base = obstack_finish (&indirectpool); idx[1 + cnt] = idx[cnt] + iov[2 + cnt].iov_len; assert (iov[2 + cnt].iov_len % sizeof (int32_t) == 0); - assert (idx[cnt] % 4 == 0); + assert (idx[cnt] % __alignof__ (int32_t) == 0); ++cnt; @@ -2493,14 +2493,14 @@ iov[2 + cnt].iov_base = &elem_size; iov[2 + cnt].iov_len = sizeof (int32_t); idx[1 + cnt] = idx[cnt] + iov[2 + cnt].iov_len; - assert (idx[cnt] % 4 == 0); + assert (idx[cnt] % __alignof__ (int32_t) == 0); ++cnt; assert (cnt == _NL_ITEM_INDEX (_NL_COLLATE_SYMB_TABLEMB)); iov[2 + cnt].iov_base = elem_table; iov[2 + cnt].iov_len = elem_size * 2 * sizeof (int32_t); idx[1 + cnt] = idx[cnt] + iov[2 + cnt].iov_len; - assert (idx[cnt] % 4 == 0); + assert (idx[cnt] % __alignof__ (int32_t) == 0); ++cnt; assert (cnt == _NL_ITEM_INDEX (_NL_COLLATE_SYMB_EXTRAMB)); @@ -2518,7 +2518,7 @@ assert (cnt == _NL_ITEM_INDEX (_NL_COLLATE_COLLSEQWC)); iov[2 + cnt].iov_base = collate->wcseqorder.result; iov[2 + cnt].iov_len = collate->wcseqorder.result_size; - assert (idx[cnt] % 4 == 0); + assert (idx[cnt] % __alignof__ (int32_t) == 0); ++cnt; assert (cnt == _NL_ITEM_INDEX (_NL_NUM_LC_COLLATE)); Index: string/strcoll.c =================================================================== RCS file: /cvs/glibc/libc/string/strcoll.c,v retrieving revision 1.23 diff -u -a -u -r1.23 string/strcoll.c --- string/strcoll.c 2000/09/01 19:24:53 1.23 +++ string/strcoll.c 2000/09/26 13:15:46 @@ -127,10 +127,10 @@ #endif use_malloc = 0; - assert (((uintptr_t) table) % sizeof (table[0]) == 0); - assert (((uintptr_t) weights) % sizeof (weights[0]) == 0); - assert (((uintptr_t) extra) % sizeof (extra[0]) == 0); - assert (((uintptr_t) indirect) % sizeof (indirect[0]) == 0); + assert (((uintptr_t) table) % __alignof__ (table[0]) == 0); + assert (((uintptr_t) weights) % __alignof__ (weights[0]) == 0); + assert (((uintptr_t) extra) % __alignof__ (extra[0]) == 0); + assert (((uintptr_t) indirect) % __alignof__ (indirect[0]) == 0); /* We need this a few times. */ s1len = STRLEN (s1); -- Andreas Schwab "And now for something SuSE Labs completely different." Andreas.Schwab@suse.de SuSE GmbH, Schanz????ckerstr. 10, D-90443 N????rnberg From aj@suse.de Tue Sep 26 06:46:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Tue, 26 Sep 2000 06:46:00 -0000 Subject: libm compiler warnings References: <200009261322.PAA30974@lxplus015.cern.ch> Message-ID: >>>>> Jes Sorensen writes: > Hi > When compiling libm under Linux/ia64 I get a bunch of warnings about > implicit declarations of a bunch of math functions and a single warning > about missing parantheses in ldbl-96/e_atan2l.c. > It wasn't quite obvious if the prototypes for the missing functions > should go in math.h or math_private.h so I stuck them in math_private.h > but feel free to move them if I am wrong. Prototypes for such aliases normally go in a file in the include directory, see e.g. include/stdio.h. math_private.h might be an exception, but math/math.h would be wrong. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From jes@linuxcare.com Tue Sep 26 07:14:00 2000 From: jes@linuxcare.com (Jes Sorensen) Date: Tue, 26 Sep 2000 07:14:00 -0000 Subject: libm compiler warnings References: <200009261322.PAA30974@lxplus015.cern.ch> Message-ID: >>>>> "Andreas" == Andreas Jaeger writes: >>>>> Jes Sorensen writes: >> Hi When compiling libm under Linux/ia64 I get a bunch of warnings >> about implicit declarations of a bunch of math functions and a >> single warning about missing parantheses in ldbl-96/e_atan2l.c. >> It wasn't quite obvious if the prototypes for the missing functions >> should go in math.h or math_private.h so I stuck them in >> math_private.h but feel free to move them if I am wrong. Andreas> Prototypes for such aliases normally go in a file in the Andreas> include directory, see e.g. include/stdio.h. Andreas> math_private.h might be an exception, but math/math.h would Andreas> be wrong. Ok, there was already a bunch of prototypes in math_private.h and it wasn't obvious to me which prototypes should go where - Ulrich do you have an oppinion on the right place here? Cheers Jes From aj@suse.de Tue Sep 26 07:14:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Tue, 26 Sep 2000 07:14:00 -0000 Subject: ldconfig: remove chroot Message-ID: Hi Uli, please test the appended patch. Now ldconfig doesn't call chroot anymore. Ok to commit? Andreas 2000-09-26 Andreas Jaeger * elf/ldconfig.c (parse_opt): Remove trailing slashes from opt_chroot. (search_dir): Handle chroot. (setup_file): New function. (main): Use it to handle chroot. ============================================================ Index: elf/ldconfig.c --- elf/ldconfig.c 2000/09/24 18:35:02 1.7 +++ elf/ldconfig.c 2000/09/26 14:03:40 @@ -105,14 +105,16 @@ /* Path to root for chroot. */ static char *opt_chroot; +static int use_chroot; + /* Manually link given shared libraries. */ static int opt_manual_link = 0; /* Cache file to use. */ -static const char *cache_file; +static char *cache_file; /* Configuration file. */ -static const char *config_file; +static char *config_file; /* Name and version of program. */ static void print_version (FILE *stream, struct argp_state *state); @@ -221,7 +223,19 @@ opt_print_cache = 1; break; case 'r': - opt_chroot = arg; + { + size_t len = strlen (arg); + opt_chroot = arg; + use_chroot = 1; + + /* Make sure that opt_chroot ends without a slash. */ + len = strlen (opt_chroot); + while (len && opt_chroot [len - 1] == '/') + { + --len; + opt_chroot [len] = '\0'; + } + } break; case 'v': opt_verbose = 1; @@ -512,7 +526,7 @@ DIR *dir; struct dirent *direntry; char buf [PATH_MAX]; - char *soname; + char *soname, *buf_ptr; struct dlib_entry *dlibs; struct dlib_entry *dlib_ptr; int nchars; @@ -529,8 +543,26 @@ else printf ("%s:\n", entry->path); } + + if (use_chroot) + buf_ptr = stpncpy (buf, opt_chroot, sizeof (buf)); + else + buf_ptr = buf; + + buf_ptr = stpncpy (buf_ptr, entry->path, sizeof (buf) - (buf_ptr - buf)); + /* Check for overflow. */ + if ((buf_ptr - buf) >= sizeof (buf)) + { + if (use_chroot) + error (0, 0, _("Length of directory %s%s is too large -- directory is ignored\n"), + opt_chroot, entry->path); + else + error (0, 0, _("Length of directory %s is too large -- directory is ignored\n"), + entry->path); + return; + } - dir = opendir (entry->path); + dir = opendir (buf); if (dir == NULL) { if (opt_verbose) @@ -558,13 +590,21 @@ || strstr (direntry->d_name, ".so") == NULL) && !is_hwcap (direntry->d_name)) continue; - nchars = snprintf (buf, sizeof (buf), "%s/%s", entry->path, - direntry->d_name); + if (use_chroot) + nchars = snprintf (buf, sizeof (buf), "%s%s/%s", opt_chroot, entry->path, + direntry->d_name); + else + nchars = snprintf (buf, sizeof (buf), "%s/%s", entry->path, + direntry->d_name); /* Check for overflow. */ if (nchars >= (int) sizeof (buf)) { - error (0, 0, _("buffer for snprintf too small for %s/%s--file is ignored\n"), - entry->path, direntry->d_name); + if (use_chroot) + error (0, 0, _("Length of file %s%s/%s is too large -- file is ignored\n"), + opt_chroot, entry->path, direntry->d_name); + else + error (0, 0, _("Length of file %s/%s is too large -- file is ignored\n"), + entry->path, direntry->d_name); continue; } #ifdef _DIRENT_HAVE_D_TYPE @@ -582,10 +622,14 @@ { /* Handle subdirectory later. */ struct dir_entry *new_entry; + char tmp [PATH_MAX]; new_entry = xmalloc (sizeof (struct dir_entry)); + /* No need to check for overflow. */ + nchars = snprintf (tmp, sizeof (tmp), "%s/%s", entry->path, + direntry->d_name); - new_entry->path = buf; + new_entry->path = xstrdup (tmp); new_entry->flag = entry->flag; new_entry->next = NULL; add_single_dir (new_entry, 0); @@ -761,7 +805,34 @@ fclose (file); } +static char * +setup_file (const char *file, const char *default_name) +{ + char *res, *tmp; + int len_chroot = use_chroot ? strlen (opt_chroot) : 0; + if (file == NULL) + { + res = xmalloc (len_chroot + strlen (default_name) + 1); + tmp = res; + if (use_chroot) + tmp = stpcpy (tmp, opt_chroot); + stpcpy (tmp, default_name); + } + else + { + res = xmalloc (len_chroot + strlen (file) + 1); + + tmp = res; + if (use_chroot) + tmp = stpcpy (tmp, opt_chroot); + stpcpy (tmp, file); + } + + return res; +} + + int main (int argc, char **argv) { @@ -779,27 +850,13 @@ add_dir (argv [i]); } - if (cache_file == NULL) - cache_file = LD_SO_CACHE; + cache_file = setup_file (cache_file, LD_SO_CACHE); + config_file = setup_file (config_file, LD_SO_CONF); - if (config_file == NULL) - config_file = LD_SO_CONF; - - /* Chroot first. */ - if (opt_chroot) - { - if (chroot (opt_chroot)) - /* Report failure and exit program. */ - error (EXIT_FAILURE, errno, _("Can't chroot to %s"), opt_chroot); - /* chroot doesn't change the working directory, let's play safe. */ - if (chdir ("/")) - error (EXIT_FAILURE, errno, _("Can't chdir to /")); - } - if (opt_print_cache) { print_cache (cache_file); - exit (0); + goto cleanup; } if (opt_manual_link) @@ -810,10 +867,9 @@ for (i = remaining; i < argc; ++i) manual_link (argv [i]); - exit (0); + goto cleanup; } - if (opt_build_cache) init_cache (); @@ -831,6 +887,12 @@ if (opt_build_cache) save_cache (cache_file); + + /* Cleanup. */ + cleanup: + + free (cache_file); + free (config_file); return 0; } -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From jakub@redhat.com Tue Sep 26 08:09:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Tue, 26 Sep 2000 08:09:00 -0000 Subject: ldconfig: remove chroot References: Message-ID: <20000926171309.E11108@sunsite.ms.mff.cuni.cz> On Tue, Sep 26, 2000 at 04:04:08PM +0200, Andreas Jaeger wrote: > > Hi Uli, > > please test the appended patch. Now ldconfig doesn't call chroot > anymore. Haven't tried it, but it looks too simple to me. What about if in the chroot you have say /opt/lib -> /foo/lib symlink? Basically, if you want to avoid using chroot (a good thing), you should do pathname lookups yourself (like use everywhere chroot_namei routine which would give you a pathname for its argument you can then feed to system calls (when -r is not used, it would give you the argument, otherwise it would lstat one pathname entry after another and if encountering a symlink, it would canonicalize it, prepend opt_chroot if it starts with a slash and make sure you don't go out of the chroot with ../. Jakub From schwab@suse.de Tue Sep 26 08:36:00 2000 From: schwab@suse.de (Andreas Schwab) Date: Tue, 26 Sep 2000 08:36:00 -0000 Subject: ldconfig: remove chroot References: Message-ID: <200009261535.e8QFZxh32723@hawking.suse.de> Andreas Jaeger writes: |> + buf_ptr = stpncpy (buf_ptr, entry->path, sizeof (buf) - (buf_ptr - buf)); |> + /* Check for overflow. */ |> + if ((buf_ptr - buf) >= sizeof (buf)) |> + { |> + if (use_chroot) |> + error (0, 0, _("Length of directory %s%s is too large -- directory is ignored\n"), |> + opt_chroot, entry->path); |> + else |> + error (0, 0, _("Length of directory %s is too large -- directory is ignored\n"), |> + entry->path); |> + return; |> + } Arbitrary limits are bad. Could you please make buf dynamically allocated? Andreas. -- Andreas Schwab "And now for something SuSE Labs completely different." Andreas.Schwab@suse.de SuSE GmbH, Schanz????ckerstr. 10, D-90443 N????rnberg From jakub@redhat.com Tue Sep 26 09:17:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Tue, 26 Sep 2000 09:17:00 -0000 Subject: [PATCH] Sparc fixes Message-ID: <20000926181839.A968@sunsite.ms.mff.cuni.cz> Hi! sparc64 clone was broken in both glibc (patch below) and in the kernel (will commit soon), now all threading tests pass on sparc64 :). Besides this, this patch tries to unify the headers Thorsten complained about, with exception of bits/syscall.h (need to find out how sparc* can override that bits/syscall.h rule) and gnu/stubs.h (no idea so far how to do that actually). 2000-09-26 Jakub Jelinek * sysdeps/sparc/sparc32/bits/endian.h: Remove. * sysdeps/sparc/sparc32/ieee754.h: New. * sysdeps/sparc/sparc64/bits/endian.h: Move... * sysdeps/sparc/bits/endian.h: ...here. * sysdeps/unix/sysv/linux/sparc/sparc32/clone.S (__clone): Optimize. * sysdeps/unix/sysv/linux/sparc/sparc64/clone.S (__clone): Check %o1, not %o0 to see if we're parent or child. Optimize. --- libc/sysdeps/sparc/sparc32/bits/endian.h.jj Tue Jan 4 17:11:59 2000 +++ libc/sysdeps/sparc/sparc32/bits/endian.h Tue Sep 26 17:02:10 2000 @@ -1,7 +0,0 @@ -/* SPARC is big-endian. */ - -#ifndef _ENDIAN_H -# error "Never use directly; include instead." -#endif - -#define __BYTE_ORDER __BIG_ENDIAN --- libc/sysdeps/sparc/sparc32/ieee754.h.jj Tue Sep 26 17:20:54 2000 +++ libc/sysdeps/sparc/sparc32/ieee754.h Tue Jan 4 17:11:56 2000 @@ -0,0 +1,171 @@ +/* Copyright (C) 1992, 1995, 1996, 1999 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Library General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Library General Public License for more details. + + You should have received a copy of the GNU Library General Public + License along with the GNU C Library; see the file COPYING.LIB. If not, + write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, + Boston, MA 02111-1307, USA. */ + +#ifndef _IEEE754_H + +#define _IEEE754_H 1 +#include + +#include + +__BEGIN_DECLS + +union ieee754_float + { + float f; + + /* This is the IEEE 754 single-precision format. */ + struct + { +#if __BYTE_ORDER == __BIG_ENDIAN + unsigned int negative:1; + unsigned int exponent:8; + unsigned int mantissa:23; +#endif /* Big endian. */ +#if __BYTE_ORDER == __LITTLE_ENDIAN + unsigned int mantissa:23; + unsigned int exponent:8; + unsigned int negative:1; +#endif /* Little endian. */ + } ieee; + + /* This format makes it easier to see if a NaN is a signalling NaN. */ + struct + { +#if __BYTE_ORDER == __BIG_ENDIAN + unsigned int negative:1; + unsigned int exponent:8; + unsigned int quiet_nan:1; + unsigned int mantissa:22; +#endif /* Big endian. */ +#if __BYTE_ORDER == __LITTLE_ENDIAN + unsigned int mantissa:22; + unsigned int quiet_nan:1; + unsigned int exponent:8; + unsigned int negative:1; +#endif /* Little endian. */ + } ieee_nan; + }; + +#define IEEE754_FLOAT_BIAS 0x7f /* Added to exponent. */ + + +union ieee754_double + { + double d; + + /* This is the IEEE 754 double-precision format. */ + struct + { +#if __BYTE_ORDER == __BIG_ENDIAN + unsigned int negative:1; + unsigned int exponent:11; + /* Together these comprise the mantissa. */ + unsigned int mantissa0:20; + unsigned int mantissa1:32; +#endif /* Big endian. */ +#if __BYTE_ORDER == __LITTLE_ENDIAN + /* Together these comprise the mantissa. */ + unsigned int mantissa1:32; + unsigned int mantissa0:20; + unsigned int exponent:11; + unsigned int negative:1; +#endif /* Little endian. */ + } ieee; + + /* This format makes it easier to see if a NaN is a signalling NaN. */ + struct + { +#if __BYTE_ORDER == __BIG_ENDIAN + unsigned int negative:1; + unsigned int exponent:11; + unsigned int quiet_nan:1; + /* Together these comprise the mantissa. */ + unsigned int mantissa0:19; + unsigned int mantissa1:32; +#else + /* Together these comprise the mantissa. */ + unsigned int mantissa1:32; + unsigned int mantissa0:19; + unsigned int quiet_nan:1; + unsigned int exponent:11; + unsigned int negative:1; +#endif + } ieee_nan; + }; + +#define IEEE754_DOUBLE_BIAS 0x3ff /* Added to exponent. */ + + +union ieee854_long_double + { + long double d; + + /* This is the IEEE 854 quad-precision format. */ + struct + { +#if __BYTE_ORDER == __BIG_ENDIAN + unsigned int negative:1; + unsigned int exponent:15; + /* Together these comprise the mantissa. */ + unsigned int mantissa0:16; + unsigned int mantissa1:32; + unsigned int mantissa2:32; + unsigned int mantissa3:32; +#endif /* Big endian. */ +#if __BYTE_ORDER == __LITTLE_ENDIAN + /* Together these comprise the mantissa. */ + unsigned int mantissa3:32; + unsigned int mantissa2:32; + unsigned int mantissa1:32; + unsigned int mantissa0:16; + unsigned int exponent:15; + unsigned int negative:1; +#endif /* Little endian. */ + } ieee; + + /* This format makes it easier to see if a NaN is a signalling NaN. */ + struct + { +#if __BYTE_ORDER == __BIG_ENDIAN + unsigned int negative:1; + unsigned int exponent:15; + unsigned int quiet_nan:1; + /* Together these comprise the mantissa. */ + unsigned int mantissa0:15; + unsigned int mantissa1:32; + unsigned int mantissa2:32; + unsigned int mantissa3:32; +#else + /* Together these comprise the mantissa. */ + unsigned int mantissa3:32; + unsigned int mantissa2:32; + unsigned int mantissa1:32; + unsigned int mantissa0:15; + unsigned int quiet_nan:1; + unsigned int exponent:15; + unsigned int negative:1; +#endif + } ieee_nan; + }; + +#define IEEE854_LONG_DOUBLE_BIAS 0x3fff /* Added to exponent. */ + +__END_DECLS + +#endif /* ieee754.h */ --- libc/sysdeps/sparc/sparc64/bits/endian.h.jj Tue Jan 4 17:11:59 2000 +++ libc/sysdeps/sparc/sparc64/bits/endian.h Tue Sep 26 17:01:55 2000 @@ -1,12 +0,0 @@ -/* Sparc is big-endian, but v9 supports endian conversion on loads/stores - and GCC supports such a mode. Be prepared. */ - -#ifndef _ENDIAN_H -# error "Never use directly; include instead." -#endif - -#ifdef __LITTLE_ENDIAN__ -# define __BYTE_ORDER __LITTLE_ENDIAN -#else -# define __BYTE_ORDER __BIG_ENDIAN -#endif --- libc/sysdeps/sparc/bits/endian.h.jj Tue Sep 26 17:01:49 2000 +++ libc/sysdeps/sparc/bits/endian.h Tue Jan 4 17:11:59 2000 @@ -0,0 +1,12 @@ +/* Sparc is big-endian, but v9 supports endian conversion on loads/stores + and GCC supports such a mode. Be prepared. */ + +#ifndef _ENDIAN_H +# error "Never use directly; include instead." +#endif + +#ifdef __LITTLE_ENDIAN__ +# define __BYTE_ORDER __LITTLE_ENDIAN +#else +# define __BYTE_ORDER __BIG_ENDIAN +#endif --- libc/sysdeps/unix/sysv/linux/sparc/sparc32/clone.S.jj Tue Jan 4 17:12:06 2000 +++ libc/sysdeps/unix/sysv/linux/sparc/sparc32/clone.S Sat Sep 23 20:19:59 2000 @@ -1,4 +1,4 @@ -/* Copyright (C) 1996, 1997, 1998 Free Software Foundation, Inc. +/* Copyright (C) 1996, 1997, 1998, 2000 Free Software Foundation, Inc. Contributed by Richard Henderson (rth@tamu.edu). The GNU C Library is free software; you can redistribute it and/or @@ -35,30 +35,26 @@ __clone: /* sanity check arguments */ tst %i0 be .Lerror - tst %i1 + orcc %i1,%g0,%o1 be .Lerror - nop + mov %i2,%o0 /* Do the system call */ - mov %i1,%o1 - mov %i2,%o0 set __NR_clone,%g1 ta 0x10 bcs .Lerror tst %o1 bne __thread_start nop - mov %o0,%i0 ret - restore + restore %o0,%g0,%o0 .Lerror: call __errno_location or %g0,EINVAL,%i0 st %i0,[%o0] - mov -1,%i0 ret - restore + restore %g0,-1,%o0 .size __clone, .-__clone --- libc/sysdeps/unix/sysv/linux/sparc/sparc64/clone.S.jj Tue Jan 4 17:12:06 2000 +++ libc/sysdeps/unix/sysv/linux/sparc/sparc64/clone.S Tue Sep 26 15:24:59 2000 @@ -1,4 +1,4 @@ -/* Copyright (C) 1997 Free Software Foundation, Inc. +/* Copyright (C) 1997, 2000 Free Software Foundation, Inc. Contributed by Richard Henderson (rth@tamu.edu). The GNU C Library is free software; you can redistribute it and/or @@ -45,7 +45,7 @@ __clone: ta 0x6d bcs,pn %xcc, 99f nop - brnz,pn %o0, __thread_start + brnz,pn %o1, __thread_start mov %o0, %i0 ret restore @@ -70,9 +70,8 @@ __clone: nop st %i0, [%o0] #endif - mov -1,%i0 ret - restore + restore %g0,-1,%o0 .size __clone, .-__clone .type __thread_start,@function Jakub From aj@suse.de Tue Sep 26 09:52:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Tue, 26 Sep 2000 09:52:00 -0000 Subject: ldconfig: remove chroot References: <200009261535.e8QFZxh32723@hawking.suse.de> Message-ID: >>>>> Andreas Schwab writes: > Andreas Jaeger writes: > |> + buf_ptr = stpncpy (buf_ptr, entry->path, sizeof (buf) - (buf_ptr - buf)); > |> + /* Check for overflow. */ > |> + if ((buf_ptr - buf) >= sizeof (buf)) > |> + { > |> + if (use_chroot) > |> + error (0, 0, _("Length of directory %s%s is too large -- directory is ignored\n"), > |> + opt_chroot, entry->path); > |> + else > |> + error (0, 0, _("Length of directory %s is too large -- directory is ignored\n"), > |> + entry->path); > |> + return; > |> + } > Arbitrary limits are bad. Could you please make buf dynamically > allocated? I've removed all arbitrary limits. Is the following ok? Andreas 2000-09-26 Andreas Jaeger * elf/ldconfig.c (search_dir): Allow unlimited path length. (create_links): Likewise. (parse_opt): Remove trailing slashes from opt_chroot. (search_dir): Handle chroot. (setup_file): New function. (main): Use it to handle chroot. ============================================================ Index: elf/ldconfig.c --- elf/ldconfig.c 2000/09/24 18:35:02 1.7 +++ elf/ldconfig.c 2000/09/26 16:17:06 @@ -17,6 +17,7 @@ write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ +#include #include #include #include @@ -105,14 +106,16 @@ /* Path to root for chroot. */ static char *opt_chroot; +static int use_chroot; + /* Manually link given shared libraries. */ static int opt_manual_link = 0; /* Cache file to use. */ -static const char *cache_file; +static char *cache_file; /* Configuration file. */ -static const char *config_file; +static char *config_file; /* Name and version of program. */ static void print_version (FILE *stream, struct argp_state *state); @@ -221,7 +224,19 @@ opt_print_cache = 1; break; case 'r': - opt_chroot = arg; + { + size_t len = strlen (arg); + opt_chroot = arg; + use_chroot = 1; + + /* Make sure that opt_chroot ends without a slash. */ + len = strlen (opt_chroot); + while (len && opt_chroot [len - 1] == '/') + { + --len; + opt_chroot [len] = '\0'; + } + } break; case 'v': opt_verbose = 1; @@ -337,15 +352,17 @@ static void create_links (const char *path, const char *libname, const char *soname) { - char full_libname [PATH_MAX], full_soname [PATH_MAX]; + char *full_libname, *full_soname; struct stat stat_lib, stat_so, lstat_so; int do_link = 1; int do_remove = 1; /* XXX: The logics in this function should be simplified. */ /* Get complete path. */ - snprintf (full_libname, sizeof full_libname, "%s/%s", path, libname); - snprintf (full_soname, sizeof full_soname, "%s/%s", path, soname); + full_libname = alloca (strlen (path) + strlen (libname) + 2); + full_soname = alloca (strlen (path) + strlen (libname) + 2); + sprintf (full_libname, "%s/%s", path, libname); + sprintf (full_soname, "%s/%s", path, soname); /* Does soname already exist and point to the right library? */ if (stat (full_soname, &stat_so) == 0) @@ -511,15 +528,18 @@ { DIR *dir; struct dirent *direntry; - char buf [PATH_MAX]; - char *soname; + char *dir_name, *file_name; + int file_name_len, len; + char *soname, *tmp_ptr; struct dlib_entry *dlibs; struct dlib_entry *dlib_ptr; - int nchars; struct stat stat_buf; int is_link; unsigned long int hwcap = path_hwcap (entry->path); + file_name_len = PATH_MAX; + file_name = alloca (file_name_len); + dlibs = NULL; if (opt_verbose) @@ -529,8 +549,16 @@ else printf ("%s:\n", entry->path); } + + dir_name = alloca ((use_chroot ? strlen (opt_chroot) : 0) + strlen (entry->path)); + tmp_ptr = dir_name; + + if (use_chroot) + tmp_ptr = stpcpy (tmp_ptr, opt_chroot); + + tmp_ptr = stpcpy (tmp_ptr, entry->path); - dir = opendir (entry->path); + dir = opendir (dir_name); if (dir == NULL) { if (opt_verbose) @@ -558,23 +586,28 @@ || strstr (direntry->d_name, ".so") == NULL) && !is_hwcap (direntry->d_name)) continue; - nchars = snprintf (buf, sizeof (buf), "%s/%s", entry->path, - direntry->d_name); - /* Check for overflow. */ - if (nchars >= (int) sizeof (buf)) + len = (use_chroot ? strlen (opt_chroot) : 0) + strlen (entry->path) + + strlen (direntry->d_name); + if (len > file_name_len) { - error (0, 0, _("buffer for snprintf too small for %s/%s--file is ignored\n"), - entry->path, direntry->d_name); - continue; + file_name_len = len + 1; + file_name = alloca (file_name_len); } + + if (use_chroot) + sprintf (file_name, "%s%s/%s", opt_chroot, entry->path, + direntry->d_name); + else + sprintf (file_name , "%s/%s", entry->path, direntry->d_name); + #ifdef _DIRENT_HAVE_D_TYPE if (direntry->d_type != DT_UNKNOWN) stat_buf.st_mode = DTTOIF (direntry->d_type); else #endif - if (lstat (buf, &stat_buf)) + if (lstat (file_name, &stat_buf)) { - error (0, errno, _("Can't lstat %s"), buf); + error (0, errno, _("Can't lstat %s"), file_name); continue; } @@ -585,7 +618,9 @@ new_entry = xmalloc (sizeof (struct dir_entry)); - new_entry->path = buf; + len = strlen (entry->path) + strlen (direntry->d_name) + 2; + new_entry->path = xmalloc (len); + sprintf (new_entry->path, "%s/%s", entry->path, direntry->d_name); new_entry->flag = entry->flag; new_entry->next = NULL; add_single_dir (new_entry, 0); @@ -596,7 +631,7 @@ is_link = S_ISLNK (stat_buf.st_mode); - if (process_file (buf, direntry->d_name, &flag, &soname, is_link)) + if (process_file (file_name, direntry->d_name, &flag, &soname, is_link)) continue; /* Links will just point to itself. */ @@ -615,13 +650,13 @@ { if (flag == FLAG_ELF_LIBC5 && entry->flag != FLAG_ELF_LIBC5 && entry->flag != FLAG_ANY) - error (0, 0, _("libc5 library %s in wrong directory"), buf); + error (0, 0, _("libc5 library %s in wrong directory"), file_name); if (flag == FLAG_ELF_LIBC6 && entry->flag != FLAG_ELF_LIBC6 && entry->flag != FLAG_ANY) - error (0, 0, _("libc6 library %s in wrong directory"), buf); + error (0, 0, _("libc6 library %s in wrong directory"), file_name); if (flag == FLAG_LIBC4 && entry->flag != FLAG_LIBC4 && entry->flag != FLAG_ANY) - error (0, 0, _("libc4 library %s in wrong directory"), buf); + error (0, 0, _("libc4 library %s in wrong directory"), file_name); } /* Add library to list. */ @@ -761,6 +796,33 @@ fclose (file); } +static char * +setup_file (const char *file, const char *default_name) +{ + char *res, *tmp; + int len_chroot = use_chroot ? strlen (opt_chroot) : 0; + + if (file == NULL) + { + res = xmalloc (len_chroot + strlen (default_name) + 1); + tmp = res; + if (use_chroot) + tmp = stpcpy (tmp, opt_chroot); + stpcpy (tmp, default_name); + } + else + { + res = xmalloc (len_chroot + strlen (file) + 1); + + tmp = res; + if (use_chroot) + tmp = stpcpy (tmp, opt_chroot); + stpcpy (tmp, file); + } + + return res; +} + int main (int argc, char **argv) @@ -778,28 +840,14 @@ for (i = remaining; i < argc; ++i) add_dir (argv [i]); } - - if (cache_file == NULL) - cache_file = LD_SO_CACHE; - if (config_file == NULL) - config_file = LD_SO_CONF; + cache_file = setup_file (cache_file, LD_SO_CACHE); + config_file = setup_file (config_file, LD_SO_CONF); - /* Chroot first. */ - if (opt_chroot) - { - if (chroot (opt_chroot)) - /* Report failure and exit program. */ - error (EXIT_FAILURE, errno, _("Can't chroot to %s"), opt_chroot); - /* chroot doesn't change the working directory, let's play safe. */ - if (chdir ("/")) - error (EXIT_FAILURE, errno, _("Can't chdir to /")); - } - if (opt_print_cache) { print_cache (cache_file); - exit (0); + goto cleanup; } if (opt_manual_link) @@ -810,10 +858,9 @@ for (i = remaining; i < argc; ++i) manual_link (argv [i]); - exit (0); + goto cleanup; } - if (opt_build_cache) init_cache (); @@ -831,6 +878,11 @@ if (opt_build_cache) save_cache (cache_file); + + /* Cleanup. */ + cleanup: + free (cache_file); + free (config_file); return 0; } -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From drepper@redhat.com Tue Sep 26 09:56:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Tue, 26 Sep 2000 09:56:00 -0000 Subject: libm compiler warnings References: <200009261322.PAA30974@lxplus015.cern.ch> Message-ID: Jes Sorensen writes: > Ok, there was already a bunch of prototypes in math_private.h and it > wasn't obvious to me which prototypes should go where - Ulrich do you > have an oppinion on the right place here? Math_private.h is OK. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From hjl@lucon.org Tue Sep 26 10:12:00 2000 From: hjl@lucon.org (H . J . Lu) Date: Tue, 26 Sep 2000 10:12:00 -0000 Subject: libm compiler warnings References: <200009261322.PAA30974@lxplus015.cern.ch> Message-ID: <20000926101245.A16990@lucon.org> On Tue, Sep 26, 2000 at 09:56:37AM -0700, Ulrich Drepper wrote: > Jes Sorensen writes: > > > Ok, there was already a bunch of prototypes in math_private.h and it > > wasn't obvious to me which prototypes should go where - Ulrich do you > > have an oppinion on the right place here? > > Math_private.h is OK. > I believe it may be the wrong place. In my glibc tree, I have 2000-09-17 H.J. Lu * sysdeps/ia64/Makefile (long-double-fcts): New. Defined as yes. H.J. From schwab@suse.de Tue Sep 26 10:14:00 2000 From: schwab@suse.de (Andreas Schwab) Date: Tue, 26 Sep 2000 10:14:00 -0000 Subject: [PATCH] Sparc fixes References: <20000926181839.A968@sunsite.ms.mff.cuni.cz> Message-ID: <200009261714.e8QHESv11239@hawking.suse.de> Jakub Jelinek writes: |> Hi! |> |> sparc64 clone was broken in both glibc (patch below) and in the kernel (will |> commit soon), now all threading tests pass on sparc64 :). |> Besides this, this patch tries to unify the headers Thorsten complained |> about, with exception of bits/syscall.h (need to find out how sparc* can |> override that bits/syscall.h rule) I'd suggest to introduce a makefile variable inhibit-bits-syscall that conditionalizes the rule in linux/Makefile, and put the appropriate rule in linux/sparc/Makefile. Andreas. -- Andreas Schwab "And now for something SuSE Labs completely different." Andreas.Schwab@suse.de SuSE GmbH, Schanz????ckerstr. 10, D-90443 N????rnberg From drepper@redhat.com Tue Sep 26 10:15:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Tue, 26 Sep 2000 10:15:00 -0000 Subject: ldconfig: remove chroot References: <200009261535.e8QFZxh32723@hawking.suse.de> Message-ID: Andreas Jaeger writes: > I've removed all arbitrary limits. Is the following ok? Did you handle Jakub's problem? If you follow at some time a symlink (reading or writing) you should look at the real name and determine whether it actually is in the chroot environment. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From aj@suse.de Tue Sep 26 10:19:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Tue, 26 Sep 2000 10:19:00 -0000 Subject: ldconfig: remove chroot References: <200009261535.e8QFZxh32723@hawking.suse.de> Message-ID: >>>>> Ulrich Drepper writes: > Andreas Jaeger writes: >> I've removed all arbitrary limits. Is the following ok? > Did you handle Jakub's problem? If you follow at some time a symlink > (reading or writing) you should look at the real name and determine > whether it actually is in the chroot environment. No, not yet. I'll look tomorrow at this. Do you see any other problem with the patch? Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From drepper@redhat.com Tue Sep 26 10:33:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Tue, 26 Sep 2000 10:33:00 -0000 Subject: ldconfig: remove chroot References: <200009261535.e8QFZxh32723@hawking.suse.de> Message-ID: Andreas Jaeger writes: > No, not yet. I'll look tomorrow at this. Do you see any other > problem with the patch? No. At least not without testing. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Tue Sep 26 10:33:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Tue, 26 Sep 2000 10:33:00 -0000 Subject: [PATCH] Sparc fixes References: <20000926181839.A968@sunsite.ms.mff.cuni.cz> <200009261714.e8QHESv11239@hawking.suse.de> Message-ID: Andreas Schwab writes: > I'd suggest to introduce a makefile variable inhibit-bits-syscall that > conditionalizes the rule in linux/Makefile, and put the appropriate rule > in linux/sparc/Makefile. Sounds fine. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Tue Sep 26 11:43:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Tue, 26 Sep 2000 11:43:00 -0000 Subject: libm compiler warnings References: <200009261322.PAA30974@lxplus015.cern.ch> Message-ID: Jes Sorensen writes: > 2000-09-26 Jes Sorensen > > * sysdeps/ieee754/ldbl-96/e_atan2l.c (__ieee754_atan2l): Add > parentheses around arithmetic used in | statement to kill compiler > warning. > > * math/math_private.h: Add prototype for __finitel. I've applied this one now. Thanks, -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Tue Sep 26 11:48:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Tue, 26 Sep 2000 11:48:00 -0000 Subject: collate_output: Assertion `idx[cnt] % 4 == 0' failed. References: <200009261324.e8QDOLi14465@hawking.suse.de> Message-ID: Andreas Schwab writes: > ld-collate.c requires an alignment of 4 when previous items where only > aligned at __alignof__ (int32_t). The latter is 2 on m68k-linux, thus the > assertion may fail. I've applied the patch now and also added an appropriate patch to string/strxfrm.c. Thanks, -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Tue Sep 26 12:17:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Tue, 26 Sep 2000 12:17:00 -0000 Subject: [PATCH] Sparc fixes References: <20000926181839.A968@sunsite.ms.mff.cuni.cz> Message-ID: Jakub Jelinek writes: > sparc64 clone was broken in both glibc (patch below) and in the kernel (will > commit soon), now all threading tests pass on sparc64 :). > Besides this, this patch tries to unify the headers Thorsten complained > about, with exception of bits/syscall.h Thanks, I've applied the patch now. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Tue Sep 26 15:41:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Tue, 26 Sep 2000 15:41:00 -0000 Subject: reopening fprintf I18N issue References: <39C8E240.A9E39DD4@us.ibm.com> Message-ID: Sorrya for the late reply, I'm still catching up. > This is an incorrect interpretation. The printf() class of functions > is always _byte_based_; a char is a byte in ISO C. Note that there > is no "l" (ell) qualifier present (SUSv2), thus the argument to %s > is to be a pointer to an array of char (ISO C) -- this is because it > is going to be treated as bytes. Note the "if precision....that many > bytes are written" sentence. I believe you that this is what current implementations do because it is what one expects from a non-locale-aware implementation. > As to what is going on in the test results, let me add something: > > [FAIL] printf([%-6.1s],??????) > sys[[]] != exp[[]] > ^ > There should be an > undisplayable single byte > here if you look at the > actual output! There is none in the files I got and this is good so. The problem is that if this byte would be there the entire output is unusable. I just changed the code to implement it the way you suggest it and now I cannot even use iconv anymore. I cannot imagine that this is what people want to use. This leaves in my opinion only two ways out: - just like the test output I have, the byte is simply omitted. This has the big drawback that now the output precision is not honored in some case and string concatenation etc might fail because junk characters are included in the string. - do it the way I've implemented it. It always provides a usable output. I do not really know what to do. Writing out garbage bytes seems much worse than diverging from the behavior of other implementations. > > [FAIL] printf([%-6.3s],??????) > > sys[[?]] != exp[[?]] > ^ > a single byte here as well. Neither here is this byte present. I guess your Japanese guys are agreeing with me that this additional byte is bad. > Now, onward to the swprintf() issue. Gary thinks the spec here is horribly > muddled, and that both the test and glibc are doing the wrong thing. We are > going to submit an aardvark to Austin Group on this. For what it is worth, > glibc is closer the Gary's expected behavior. I've got meanwhile some comments from the original author of the amd1 specs. His intentions were a bit different from what I had implemented and this is I've changed now. I think my implementation is now in line what ISO C99 is intended to be. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Tue Sep 26 22:26:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Tue, 26 Sep 2000 22:26:00 -0000 Subject: thread-local data access Message-ID: We slowly have to think about the platforms which do not yet have thread-local data access through anything but the POSIX API. This will be a problem since there are at least two changes coming up which require fast access the thread-local data. The situation from my perspective is as follows: - x86: %gs register, fast enough - SPARC: dedicated thread register - IA-64: likewise - Alpha: PAL call, fast enough (according to rth) What about the other architectures? I guess m68k is not really that important anymore. More of a problem for me are Arm, MIPS, and PPC. Also, do the people who designed the ABI for PA, SH, and S390 thought about this? The consequences of not having fast TLD will become quite dramatic: those architecture will simply not support the upcoming multi-threaded APIs (and therefore will be incompatible to the other archs) or will be very slow (due to the hidden function calls to the POSIX API). It is not enough to have an libc-internal ABI, it must be used everywhere in the program. And it should become the default since otherwise you need multiple copies of the libc and other libs and must not mix them. What are people's takes on this? This will surely be a high-end MT API and if an arch like SH which is mainly used on small machines isn't using it this will not mean the end of the world. But it means that applications written with the extended ABI in mind will not be compilable on this architecture. In case you have to know what extensions are currently planned: - TLD support in programming languages (think OpenMP) - MT locale model (I'm writing the specs down these days) There will probably be more in future. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Tue Sep 26 23:35:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Tue, 26 Sep 2000 23:35:00 -0000 Subject: CLOCK_MONOTONIC Message-ID: Just to keap you informed. I had to pull CLOCK_MONOTONIC since if this option would be available the aio_* functions (and I think some others) must use this clock for timeout. We are not prepared for that yet. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From jakub@redhat.com Wed Sep 27 00:41:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Wed, 27 Sep 2000 00:41:00 -0000 Subject: thread-local data access References: Message-ID: <20000927094308.B968@sunsite.ms.mff.cuni.cz> On Tue, Sep 26, 2000 at 10:26:14PM -0700, Ulrich Drepper wrote: > We slowly have to think about the platforms which do not yet have > thread-local data access through anything but the POSIX API. This > will be a problem since there are at least two changes coming up which > require fast access the thread-local data. > > The situation from my perspective is as follows: > > - x86: %gs register, fast enough > - SPARC: dedicated thread register > - IA-64: likewise > - Alpha: PAL call, fast enough (according to rth) > > What about the other architectures? I guess m68k is not really that > important anymore. More of a problem for me are Arm, MIPS, and PPC. > Also, do the people who designed the ABI for PA, SH, and S390 thought > about this? Thinking about it, wouldn't be better to just make the other arches slower (e.g. by managing a global array of pointers to thread-local data indexed by say [STACK_POINTER >> 16] (provided that we make sure that no two thread stacks share the same 64K page))? I know two memory accesses (and perhaps some cache misses) plus some math will slow things down, on the other side I think it would be far worse if programs won't be portable accross the architectures. A threaded program could mmap (...PROT_NONE...) the 64K*sizeof(void *) array first and then as the various stacks are created/destroyed, they would be mmaped/munmaped as needed and filled with thread local pointers. Jakub From aj@suse.de Wed Sep 27 01:48:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Wed, 27 Sep 2000 01:48:00 -0000 Subject: ldconfig: remove chroot References: <200009261535.e8QFZxh32723@hawking.suse.de> Message-ID: >>>>> Ulrich Drepper writes: > Andreas Jaeger writes: >> I've removed all arbitrary limits. Is the following ok? > Did you handle Jakub's problem? If you follow at some time a symlink > (reading or writing) you should look at the real name and determine > whether it actually is in the chroot environment. Let's do the patching incrementally. Here's a patch for unlimited path length, it also corrects a bug in my last patch I've noticed. The removal of chroot needs some more thinking - and I'd like to get this patch as bugfix in. Andreas 2000-09-26 Andreas Jaeger * elf/ldconfig.c (search_dir): Allow unlimited path length. (create_links): Likewise. ============================================================ Index: elf/ldconfig.c --- elf/ldconfig.c 2000/09/24 18:35:02 1.7 +++ elf/ldconfig.c 2000/09/27 08:40:46 @@ -17,6 +17,7 @@ write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ +#include #include #include #include @@ -337,15 +338,17 @@ static void create_links (const char *path, const char *libname, const char *soname) { - char full_libname [PATH_MAX], full_soname [PATH_MAX]; + char *full_libname, *full_soname; struct stat stat_lib, stat_so, lstat_so; int do_link = 1; int do_remove = 1; /* XXX: The logics in this function should be simplified. */ /* Get complete path. */ - snprintf (full_libname, sizeof full_libname, "%s/%s", path, libname); - snprintf (full_soname, sizeof full_soname, "%s/%s", path, soname); + full_libname = alloca (strlen (path) + strlen (libname) + 2); + full_soname = alloca (strlen (path) + strlen (libname) + 2); + sprintf (full_libname, "%s/%s", path, libname); + sprintf (full_soname, "%s/%s", path, soname); /* Does soname already exist and point to the right library? */ if (stat (full_soname, &stat_so) == 0) @@ -511,15 +514,18 @@ { DIR *dir; struct dirent *direntry; - char buf [PATH_MAX]; + char *file_name; + int file_name_len, len; char *soname; struct dlib_entry *dlibs; struct dlib_entry *dlib_ptr; - int nchars; struct stat stat_buf; int is_link; unsigned long int hwcap = path_hwcap (entry->path); + file_name_len = PATH_MAX; + file_name = alloca (file_name_len); + dlibs = NULL; if (opt_verbose) @@ -558,23 +564,21 @@ || strstr (direntry->d_name, ".so") == NULL) && !is_hwcap (direntry->d_name)) continue; - nchars = snprintf (buf, sizeof (buf), "%s/%s", entry->path, - direntry->d_name); - /* Check for overflow. */ - if (nchars >= (int) sizeof (buf)) + len = strlen (entry->path) + strlen (direntry->d_name); + if (len > file_name_len) { - error (0, 0, _("buffer for snprintf too small for %s/%s--file is ignored\n"), - entry->path, direntry->d_name); - continue; + file_name_len = len + 1; + file_name = alloca (file_name_len); } + sprintf (file_name , "%s/%s", entry->path, direntry->d_name); #ifdef _DIRENT_HAVE_D_TYPE if (direntry->d_type != DT_UNKNOWN) stat_buf.st_mode = DTTOIF (direntry->d_type); else #endif - if (lstat (buf, &stat_buf)) + if (lstat (file_name, &stat_buf)) { - error (0, errno, _("Can't lstat %s"), buf); + error (0, errno, _("Can't lstat %s"), file_name); continue; } @@ -584,8 +588,7 @@ struct dir_entry *new_entry; new_entry = xmalloc (sizeof (struct dir_entry)); - - new_entry->path = buf; + new_entry->path = xstrdup (file_name); new_entry->flag = entry->flag; new_entry->next = NULL; add_single_dir (new_entry, 0); @@ -596,7 +599,7 @@ is_link = S_ISLNK (stat_buf.st_mode); - if (process_file (buf, direntry->d_name, &flag, &soname, is_link)) + if (process_file (file_name, direntry->d_name, &flag, &soname, is_link)) continue; /* Links will just point to itself. */ @@ -615,13 +618,13 @@ { if (flag == FLAG_ELF_LIBC5 && entry->flag != FLAG_ELF_LIBC5 && entry->flag != FLAG_ANY) - error (0, 0, _("libc5 library %s in wrong directory"), buf); + error (0, 0, _("libc5 library %s in wrong directory"), file_name); if (flag == FLAG_ELF_LIBC6 && entry->flag != FLAG_ELF_LIBC6 && entry->flag != FLAG_ANY) - error (0, 0, _("libc6 library %s in wrong directory"), buf); + error (0, 0, _("libc6 library %s in wrong directory"), file_name); if (flag == FLAG_LIBC4 && entry->flag != FLAG_LIBC4 && entry->flag != FLAG_ANY) - error (0, 0, _("libc4 library %s in wrong directory"), buf); + error (0, 0, _("libc4 library %s in wrong directory"), file_name); } /* Add library to list. */ -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From jakub@redhat.com Wed Sep 27 01:59:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Wed, 27 Sep 2000 01:59:00 -0000 Subject: [PATCH] Fix test-fenv Message-ID: <20000927110037.A14404@sunsite.ms.mff.cuni.cz> Hi! Even other parts of test-fenv already ignore inexact exceptions when raising overflow/underflow, so we should disable it in the feexcp_mask_test as well. Makes test-fenv pass all tests on sparc64... 2000-09-27 Jakub Jelinek * math/test-fenv.c (feexcp_mask_test): If enabling all exceptions and disabling underflow or overflow, disable inexact as well. --- libc/math/test-fenv.c.jj Sun Aug 20 18:53:25 2000 +++ libc/math/test-fenv.c Wed Sep 27 10:36:55 2000 @@ -399,7 +399,7 @@ feexcp_nomask_test (const char *flag_nam static void feexcp_mask_test (const char *flag_name, int fe_exc) { - int status; + int status, exception; pid_t pid; printf ("Test: after fedisable (%s) processes will not abort\n", flag_name); @@ -415,7 +415,20 @@ feexcp_mask_test (const char *flag_name, setrlimit (RLIMIT_CORE, &core_limit); #endif feenableexcept (FE_ALL_EXCEPT); - fedisableexcept (fe_exc); + exception = fe_exc; +#ifdef FE_INEXACT + /* The standard allows the inexact exception to be set together with the + underflow and overflow exceptions. So add FE_INEXACT to the set of + exceptions to be disabled if we will be raising underflow or + overflow. */ +# ifdef FE_OVERFLOW + if (fe_exc & FE_OVERFLOW) exception |= FE_INEXACT; +# endif +# ifdef FE_UNDERFLOW + if (fe_exc & FE_UNDERFLOW) exception |= FE_INEXACT; +# endif +#endif + fedisableexcept (exception); feraiseexcept (fe_exc); exit (2); } Jakub From drepper@redhat.com Wed Sep 27 07:45:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Wed, 27 Sep 2000 07:45:00 -0000 Subject: thread-local data access References: <20000927094308.B968@sunsite.ms.mff.cuni.cz> Message-ID: Jakub Jelinek writes: > Thinking about it, wouldn't be better to just make the other arches slower > (e.g. by managing a global array of pointers to thread-local data indexed by > say [STACK_POINTER >> 16] (provided that we make sure that no two thread > stacks share the same 64K page))? This is how finding thread local data (and also the thread descriptor) works in the moment. Inlining these computations is a problem since it would mean you cannot set the stack address (and size) yourself anymore. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Wed Sep 27 07:47:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Wed, 27 Sep 2000 07:47:00 -0000 Subject: ldconfig: remove chroot References: <200009261535.e8QFZxh32723@hawking.suse.de> Message-ID: Andreas Jaeger writes: > 2000-09-26 Andreas Jaeger > > * elf/ldconfig.c (search_dir): Allow unlimited path length. > (create_links): Likewise. OK, check it in. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From jakub@redhat.com Wed Sep 27 08:03:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Wed, 27 Sep 2000 08:03:00 -0000 Subject: thread-local data access References: <20000927094308.B968@sunsite.ms.mff.cuni.cz> Message-ID: <20000927170503.E17964@sunsite.ms.mff.cuni.cz> On Wed, Sep 27, 2000 at 07:45:13AM -0700, Ulrich Drepper wrote: > Jakub Jelinek writes: > > > Thinking about it, wouldn't be better to just make the other arches slower > > (e.g. by managing a global array of pointers to thread-local data indexed by > > say [STACK_POINTER >> 16] (provided that we make sure that no two thread > > stacks share the same 64K page))? > > This is how finding thread local data (and also the thread descriptor) > works in the moment. No, at the moment if you don't have a dedicated thread register, you either do __pthread_find_self which is a loop over threads or return (pthread_descr)(((unsigned long)sp | (STACK_SIZE-1))+1) - 1; With that you cannot obviously set the stack address and size yourself. > Inlining these computations is a problem since > it would mean you cannot set the stack address (and size) yourself > anymore. But I was suggesting something like: pthread_descr *__pthread_descr_array; static inline pthread_descr thread_self (void) { #ifdef THREAD_SELF return THREAD_SELF; #else char *sp = CURRENT_STACK_FRAME; return __pthread_descr_array[(unsigned long)sp >> 16]; #endif } where __pthread_descr_array would be created with (on 32bit arches): __pthread_descr_array = mmap(NULL, (1 << 16) * sizeof(pthread_descr), PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); and later on mmaped/munmaped over with MAP_FIXED as needed during pthread_initialize_manager, pthread_create and thread exits as well. Jakub From drepper@redhat.com Wed Sep 27 08:16:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Wed, 27 Sep 2000 08:16:00 -0000 Subject: thread-local data access References: <20000927094308.B968@sunsite.ms.mff.cuni.cz> <20000927170503.E17964@sunsite.ms.mff.cuni.cz> Message-ID: Jakub Jelinek writes: > static inline pthread_descr thread_self (void) > { > #ifdef THREAD_SELF > return THREAD_SELF; > #else > char *sp = CURRENT_STACK_FRAME; > return __pthread_descr_array[(unsigned long)sp >> 16]; > #endif > } You will need a 256k array for this. We had to make the decision for the thread library and decided not to do it that way. Also, some applications allocate really small stacks for the threads (if it's known they don't need much) like this: char stacks[N][4096]; pthread_attr_t attr[N]; for (n = ...) pthread_attr_setstack (&attr[n], stacks[n], 4096); You cannot safely assume that you have 64 for your own. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From schwidefsky@de.ibm.com Wed Sep 27 08:25:00 2000 From: schwidefsky@de.ibm.com (schwidefsky@de.ibm.com) Date: Wed, 27 Sep 2000 08:25:00 -0000 Subject: thread-local data access Message-ID: >What about the other architectures? S390 could make use of one of the access registers. We do not use access registers for user programs at the moment (and probably never will). Its normal use is for concurrent access to multiple address spaces. We only use these registers in the kernel to copy between user and kernel address space. Access register 0 is unused anywhere so we could just use this one. We can't address data directly with this register but we can load it to a normal register in one cycle. I will take a look at the pthread implementation and give it a try. blue skies, Martin Linux/390 Design & Development, IBM Deutschland Entwicklung GmbH Sch????naicherstr. 220, D-71032 B????blingen, Telefon: 49 - (0)7031 - 16-2247 E-Mail: schwidefsky@de.ibm.com From jakub@redhat.com Wed Sep 27 08:27:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Wed, 27 Sep 2000 08:27:00 -0000 Subject: thread-local data access References: <20000927094308.B968@sunsite.ms.mff.cuni.cz> <20000927170503.E17964@sunsite.ms.mff.cuni.cz> Message-ID: <20000927172929.F17964@sunsite.ms.mff.cuni.cz> On Wed, Sep 27, 2000 at 08:16:07AM -0700, Ulrich Drepper wrote: > Jakub Jelinek writes: > > > static inline pthread_descr thread_self (void) > > { > > #ifdef THREAD_SELF > > return THREAD_SELF; > > #else > > char *sp = CURRENT_STACK_FRAME; > > return __pthread_descr_array[(unsigned long)sp >> 16]; > > #endif > > } > > You will need a 256k array for this. We had to make the decision for > the thread library and decided not to do it that way. Yes, you need 256k array, but you don't need to populate it fully, usually stacks don't take all the process virtual memory, usually just a small fraction. > > > Also, some applications allocate really small stacks for the threads > (if it's known they don't need much) like this: > > char stacks[N][4096]; > pthread_attr_t attr[N]; > > for (n = ...) > pthread_attr_setstack (&attr[n], stacks[n], 4096); > > You cannot safely assume that you have 64 for your own. Ok, fine, but we could assume at least PTHREAD_STACK_MIN, provided that we require on those architectures stacks to be aligned to PTHREAD_STACK_MIN bytes. Jakub From schwab@suse.de Wed Sep 27 09:01:00 2000 From: schwab@suse.de (Andreas Schwab) Date: Wed, 27 Sep 2000 09:01:00 -0000 Subject: Fix for make dist Message-ID: <200009271601.e8RG1U326568@hawking.suse.de> When running `make dist' while configured for a target that does not support long double the long double tests sources are missing from the distribution. 2000-09-27 Andreas Schwab * math/Makefile (distribute): Explicitly add the long double test sources, to get them included even if long double is not supported. Index: math/Makefile =================================================================== RCS file: /cvs/glibc/libc/math/Makefile,v retrieving revision 1.99 diff -u -a -u -r1.99 math/Makefile --- math/Makefile 2000/09/01 06:58:22 1.99 +++ math/Makefile 2000/09/27 15:57:45 @@ -83,6 +83,7 @@ # We do the `long double' tests only if this data type is available and # distinct from `double'. test-longdouble-yes = test-ldouble test-ildoubl +distribute += $(test-longdouble-yes:=.c) ifneq (no,$(PERL)) libm-tests = test-float test-double $(test-longdouble-$(long-double-fcts)) \ -- Andreas Schwab "And now for something SuSE Labs completely different." Andreas.Schwab@suse.de SuSE GmbH, Schanz????ckerstr. 10, D-90443 N????rnberg From bmark@us.ibm.com Wed Sep 27 23:17:00 2000 From: bmark@us.ibm.com (Mark Brown) Date: Wed, 27 Sep 2000 23:17:00 -0000 Subject: reopening fprintf I18N issue References: <39C8E240.A9E39DD4@us.ibm.com> Message-ID: <39D2C38F.25C0DC74@us.ibm.com> U- Gary Miller and some ISO folks will be at the AG meeting in Austin. We can work this out there....I agree that I have not seen a 100% correct and clear interpretation of this text yet. Mark Ulrich Drepper wrote: > > Sorrya for the late reply, I'm still catching up. > > > This is an incorrect interpretation. The printf() class of functions > > is always _byte_based_; a char is a byte in ISO C. Note that there > > is no "l" (ell) qualifier present (SUSv2), thus the argument to %s > > is to be a pointer to an array of char (ISO C) -- this is because it > > is going to be treated as bytes. Note the "if precision....that many > > bytes are written" sentence. > > I believe you that this is what current implementations do because it > is what one expects from a non-locale-aware implementation. > > > As to what is going on in the test results, let me add something: > > > > [FAIL] printf([%-6.1s],??????) > > sys[[]] != exp[[]] > > ^ > > There should be an > > undisplayable single byte > > here if you look at the > > actual output! > > There is none in the files I got and this is good so. The problem is > that if this byte would be there the entire output is unusable. I > just changed the code to implement it the way you suggest it and now I > cannot even use iconv anymore. I cannot imagine that this is what > people want to use. > > This leaves in my opinion only two ways out: > > - just like the test output I have, the byte is simply omitted. This > has the big drawback that now the output precision is not honored in > some case and string concatenation etc might fail because junk > characters are included in the string. > > - do it the way I've implemented it. It always provides a usable output. > > I do not really know what to do. Writing out garbage bytes seems much > worse than diverging from the behavior of other implementations. > > > > [FAIL] printf([%-6.3s],??????) > > > sys[[?]] != exp[[?]] > > ^ > > a single byte here as well. > > Neither here is this byte present. I guess your Japanese guys are > agreeing with me that this additional byte is bad. > > > Now, onward to the swprintf() issue. Gary thinks the spec here is horribly > > muddled, and that both the test and glibc are doing the wrong thing. We are > > going to submit an aardvark to Austin Group on this. For what it is worth, > > glibc is closer the Gary's expected behavior. > > I've got meanwhile some comments from the original author of the amd1 > specs. His intentions were a bit different from what I had > implemented and this is I've changed now. I think my implementation > is now in line what ISO C99 is intended to be. > > -- > ---------------. ,-. 1325 Chesapeake Terrace > Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA > Red Hat `--' drepper at redhat.com `------------------------ -- Mark S. Brown bmark@us.ibm.com Senior Technical Staff Member 512.838.3926 T/L678.3926 IBM RS/6000 AIX System Architecture Mark Brown/Austin/IBM IBM Corporation, Austin, Texas From gniibe@chroot.org Thu Sep 28 01:38:00 2000 From: gniibe@chroot.org (NIIBE Yutaka) Date: Thu, 28 Sep 2000 01:38:00 -0000 Subject: thread-local data access References: Message-ID: Ulrich Drepper wrote: > The situation from my perspective is as follows: > > - x86: %gs register, fast enough > - SPARC: dedicated thread register > - IA-64: likewise > - Alpha: PAL call, fast enough (according to rth) > > What about the other architectures? For SH (SuperH), we could use GBR register for that. GCC implementation doesn't use GBR at all. It's called "Global Base Register", say, a kind of legacy heritage. :-) There's special addressing mode with GBR register, but the offset is limited (we only can use 256 entries). If I remember correctly, we can find such addressing mode in Motorola 6809, where it was designed to be useful for global variable access. Provided the space needed is small enough, it works well. Embedded people love such feature. But it's too restricted for general use, GCC doesn't use GBR and its addressing mode at all. Once, I tried to use GBR for PIC implementation, but we have changed to use generic register R12 instead, as we found it's not efficient (using addressing mode with GBR requires R0 register). The question is thread local data require large space or not. Thanks for the discussion, -- From bmark@us.ibm.com Thu Sep 28 08:21:00 2000 From: bmark@us.ibm.com (Mark Brown) Date: Thu, 28 Sep 2000 08:21:00 -0000 Subject: [Fwd: [Fwd: reopening fprintf I18N issue]] Message-ID: <39D361D2.3FDD8B11@us.ibm.com> This is from Gary Miller.... gwm@us.ibm.com wrote: > > Mark, > > The distinction between the fprintf family of functions and the fwprintf > family of functions is that the fprintf functions output is byte and the > fwprintf output is wide character (wchar_t). The fwprintf wide character > (wchar_t) data are printed as if having been processed by fputwc(), but the > fundamental difference between the two families of functions is that one is > "byte" oriented and the other is "wide character (wchar_t)" oriented. > > The metric for the output of the fprintf family of functions for > padding, precision, etc. should be bytes. > > The metric for the output (intermediate wide character sequence) of the > fwprintf family functions for padding, precision, etc. should be wide > characters (wchar_t). > > This may seem counter intuitive, but it is the only way to have a rational > distinction of the functions. One of the things that might seem strange is > that one can have a differing number of bytes of printed output for the > fwprintf functions after fputwc() has been applied depending on the > underlying multibyte codeset of the locale: consider the differences > between SJIS and EUC-JP. > > BTW, because of the differences among codesets (SJIS, EUC-JP, EUC-TW, > EUC-CN, 8859-x, UTF-8), I believe that it is a bad idea to attempt to apply > precision operations on character (byte) strings. Precision operations on > wide character strings should have "consistent" visual output -- the > underlying data buffers will have varying numbers of bytes due to the > differences in codesets after the data has been processed by fputwc(). > > Gary W. Miller Phone: ( 512) 838-8297 > IBM 2BCA/903 ZIP 9350 T/L: 678-8297 > 11400 Burnet Road FAX: (512) 838-0169 > Austin, Texas 78758 Internet: gwm@us.ibm.com > > Mark Brown/Austin/IBM@IBMUS on 09-27-2000 11:04:20 PM > > Please respond to Mark Brown/Austin/IBM@IBMUS > > To: Gary W Miller/Austin/IBM@IBMUS > cc: > Subject: [Fwd: reopening fprintf I18N issue] > > Gary > > FYI > > Mark > > Ulrich Drepper wrote: > > > > Sorrya for the late reply, I'm still catching up. > > > > > This is an incorrect interpretation. The printf() class of functions > > > is always _byte_based_; a char is a byte in ISO C. Note that there > > > is no "l" (ell) qualifier present (SUSv2), thus the argument to %s > > > is to be a pointer to an array of char (ISO C) -- this is because it > > > is going to be treated as bytes. Note the "if precision....that many > > > bytes are written" sentence. > > > > I believe you that this is what current implementations do because it > > is what one expects from a non-locale-aware implementation. > > > > > As to what is going on in the test results, let me add something: > > > > > > [FAIL] printf([%-6.1s],??????) > > > sys[[]] != exp > [[]] > > > ^ > > > There should be an > > > undisplayable single > byte > > > here if you look at > the > > > actual output! > > > > There is none in the files I got and this is good so. The problem is > > that if this byte would be there the entire output is unusable. I > > just changed the code to implement it the way you suggest it and now I > > cannot even use iconv anymore. I cannot imagine that this is what > > people want to use. > > > > This leaves in my opinion only two ways out: > > > > - just like the test output I have, the byte is simply omitted. This > > has the big drawback that now the output precision is not honored in > > some case and string concatenation etc might fail because junk > > characters are included in the string. > > > > - do it the way I've implemented it. It always provides a usable output. > > > > I do not really know what to do. Writing out garbage bytes seems much > > worse than diverging from the behavior of other implementations. > > > > > > [FAIL] printf([%-6.3s],??????) > > > > sys[[?]] != exp[[?]] > > > ^ > > > a single byte here as well. > > > > Neither here is this byte present. I guess your Japanese guys are > > agreeing with me that this additional byte is bad. > > > > > Now, onward to the swprintf() issue. Gary thinks the spec here is > horribly > > > muddled, and that both the test and glibc are doing the wrong thing. We > are > > > going to submit an aardvark to Austin Group on this. For what it is > worth, > > > glibc is closer the Gary's expected behavior. > > > > I've got meanwhile some comments from the original author of the amd1 > > specs. His intentions were a bit different from what I had > > implemented and this is I've changed now. I think my implementation > > is now in line what ISO C99 is intended to be. > > > > -- > > ---------------. ,-. 1325 Chesapeake Terrace > > Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA > > Red Hat `--' drepper at redhat.com `------------------------ > > -- > Mark S. Brown > bmark@us.ibm.com > Senior Technical Staff Member 512.838.3926 > T/L678.3926 > IBM RS/6000 AIX System Architecture Mark > Brown/Austin/IBM > IBM Corporation, Austin, Texas -- Mark S. Brown bmark@us.ibm.com Senior Technical Staff Member 512.838.3926 T/L678.3926 IBM RS/6000 AIX System Architecture Mark Brown/Austin/IBM IBM Corporation, Austin, Texas From drepper@redhat.com Thu Sep 28 11:05:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Thu, 28 Sep 2000 11:05:00 -0000 Subject: thread-local data access References: Message-ID: NIIBE Yutaka writes: > The question is thread local data require large space or not. Ideally there would be no size limit but it is no real problem. At offset zero there is a pointer to the internal thread descriptor which means that for offsets >256 we simply use indirect addressing. For the extended locale model we can arrange things so that there is no additional overhead involved. I'd say try to come up with appropriate patches. All you should have to do is to write THREAD_SETMEM etc macros for SH. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Thu Sep 28 15:53:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Thu, 28 Sep 2000 15:53:00 -0000 Subject: [PATCH] Fix test-fenv References: <20000927110037.A14404@sunsite.ms.mff.cuni.cz> Message-ID: Jakub Jelinek writes: > Even other parts of test-fenv already ignore inexact exceptions when raising > overflow/underflow, so we should disable it in the feexcp_mask_test as well. > Makes test-fenv pass all tests on sparc64... Thanks, I've applied the patch now. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Thu Sep 28 16:08:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Thu, 28 Sep 2000 16:08:00 -0000 Subject: Fix for make dist References: <200009271601.e8RG1U326568@hawking.suse.de> Message-ID: Andreas Schwab writes: > When running `make dist' while configured for a target that does not > support long double the long double tests sources are missing from the > distribution. Thanks, I've applied the patch now. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Fri Sep 29 00:01:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Fri, 29 Sep 2000 00:01:00 -0000 Subject: next test release (5th) Message-ID: I've handled now all the mails which came in for the last versions and which actually can be handled. If you know about anything else let me know. This means it's a good time to make a new test release since some bugs are fixed and deserve testing. Given how few bugs turned up since the last test release I really hope we reached the point when we can make the 2.2 release. I'm not counting changes in ports. No port beside the stable ones should be considered when making a release (x86, m68, Alpha, PPC, SPARC, Arm). And those stable ports seem to have no more problems. I hope to find the time to make the .95 test release over the weekend. Depending on how many reports we get this could very well be a release candidate and the following release could be final. And no, I don't want to wait for Linus to get his acts together especially since releasing the 2.4 kernel does not mean that no new features get introduced for 2.4.1. We'll have to make adjustments anyway. If you have any pending changes (like Andreas with ldconfig) try to get them to me ASAP. Any other issues should be raised now as well. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From aj@suse.de Fri Sep 29 00:27:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Fri, 29 Sep 2000 00:27:00 -0000 Subject: next test release (5th) References: Message-ID: >>>>> Ulrich Drepper writes: > I've handled now all the mails which came in for the last versions and > which actually can be handled. If you know about anything else let me > know. > This means it's a good time to make a new test release since some bugs > are fixed and deserve testing. > Given how few bugs turned up since the last test release I really hope > we reached the point when we can make the 2.2 release. I'm not > counting changes in ports. No port beside the stable ones should be > considered when making a release (x86, m68, Alpha, PPC, SPARC, Arm). > And those stable ports seem to have no more problems. > I hope to find the time to make the .95 test release over the weekend. > Depending on how many reports we get this could very well be a release > candidate and the following release could be final. > And no, I don't want to wait for Linus to get his acts together > especially since releasing the 2.4 kernel does not mean that no new > features get introduced for 2.4.1. We'll have to make adjustments > anyway. > If you have any pending changes (like Andreas with ldconfig) try to > get them to me ASAP. Any other issues should be raised now as well. I'm not sure the ldconfig changes make it. I'm moving across the country next week and have two weeks holiday. I'll try to look at it again today but if you don't get anything, I won't make it in time for the release :-(. What about my Patches with Subject: "leases/locks in 2.4.0-test9-pre7 - sync glibc and kernel" ? Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From kukuk@suse.de Fri Sep 29 00:30:00 2000 From: kukuk@suse.de (Thorsten Kukuk) Date: Fri, 29 Sep 2000 00:30:00 -0000 Subject: next test release (5th) References: Message-ID: <20000929093016.A3784@suse.de> Hi, I have only one bigger problem: H.J. Lu's patch for sunrpc/udp (IP_PKTINFO) patch does not seem to work on big endian platforms. The server sends the data to the network, but the client never becomes the answer. I will try to look at it, but I don't know anything about IP_PKTINFO. The other problem I found is the nscd interface. It seems it is incompatible between 32bit and 64bit platforms. This will be a problem with all the upcoming platforms which support 32 and 64bit binaries. But I don't think that we need to solve it now. I even don't know where the problem is. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background. From aj@suse.de Fri Sep 29 00:42:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Fri, 29 Sep 2000 00:42:00 -0000 Subject: next test release (5th) References: <20000929093016.A3784@suse.de> Message-ID: >>>>> Thorsten Kukuk writes: > Hi, > I have only one bigger problem: H.J. Lu's patch for sunrpc/udp > (IP_PKTINFO) patch does not seem to work on big endian platforms. > The server sends the data to the network, but the client never > becomes the answer. I will try to look at it, but I don't know > anything about IP_PKTINFO. > The other problem I found is the nscd interface. It seems it is > incompatible between 32bit and 64bit platforms. This will be a > problem with all the upcoming platforms which support 32 and 64bit > binaries. But I don't think that we need to solve it now. I even > don't know where the problem is. nscd_client.h has: typedef struct { int version; /* Version number of the daemon interface. */ request_type type; /* Service requested. */ ssize_t key_len; /* Key length. */ } request_header; ssize_t is different on 32 and 64-bit platforms - also request_type might be different (I'm not sure about this one). Best is to use some lines of code like the following to check this (but this might not show all problems): printf ("sizof file_entry: %Zd\n", sizeof (request_header)); printf ("offsetof key_len: %Zd\n", offsetof (request_header, key_len)); Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From jakub@redhat.com Fri Sep 29 00:57:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Fri, 29 Sep 2000 00:57:00 -0000 Subject: next test release (5th) References: <20000929093016.A3784@suse.de> Message-ID: <20000929095938.B16891@sunsite.ms.mff.cuni.cz> On Fri, Sep 29, 2000 at 09:30:16AM +0200, Thorsten Kukuk wrote: > > Hi, > > I have only one bigger problem: H.J. Lu's patch for sunrpc/udp > (IP_PKTINFO) patch does not seem to work on big endian platforms. > > The server sends the data to the network, but the client never > becomes the answer. I will try to look at it, but I don't know > anything about IP_PKTINFO. > > The other problem I found is the nscd interface. It seems it is > incompatible between 32bit and 64bit platforms. This will be a > problem with all the upcoming platforms which support 32 and 64bit > binaries. But I don't think that we need to solve it now. I even > don't know where the problem is. I'll look at it as well today. Jakub From jakub@redhat.com Fri Sep 29 00:58:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Fri, 29 Sep 2000 00:58:00 -0000 Subject: next test release (5th) References: Message-ID: <20000929100101.C16891@sunsite.ms.mff.cuni.cz> On Fri, Sep 29, 2000 at 09:26:58AM +0200, Andreas Jaeger wrote: > >>>>> Ulrich Drepper writes: > > > I've handled now all the mails which came in for the last versions and > > which actually can be handled. If you know about anything else let me > > know. > > > This means it's a good time to make a new test release since some bugs > > are fixed and deserve testing. > > > Given how few bugs turned up since the last test release I really hope > > we reached the point when we can make the 2.2 release. I'm not > > counting changes in ports. No port beside the stable ones should be > > considered when making a release (x86, m68, Alpha, PPC, SPARC, Arm). > > And those stable ports seem to have no more problems. > > > I hope to find the time to make the .95 test release over the weekend. > > Depending on how many reports we get this could very well be a release > > candidate and the following release could be final. > > > And no, I don't want to wait for Linus to get his acts together > > especially since releasing the 2.4 kernel does not mean that no new > > features get introduced for 2.4.1. We'll have to make adjustments > > anyway. > > > > If you have any pending changes (like Andreas with ldconfig) try to > > get them to me ASAP. Any other issues should be raised now as well. > > I'm not sure the ldconfig changes make it. I'm moving across the > country next week and have two weeks holiday. I'll try to look at it > again today but if you don't get anything, I won't make it in time for > the release :-(. If it is the -r and chroot thing, I can write a patch (but let me know if you're working on it or not, so that we don't write it twice). Jakub From aj@suse.de Fri Sep 29 02:36:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Fri, 29 Sep 2000 02:36:00 -0000 Subject: next test release (5th) References: <20000929100101.C16891@sunsite.ms.mff.cuni.cz> Message-ID: >>>>> Jakub Jelinek writes: Jakub> On Fri, Sep 29, 2000 at 09:26:58AM +0200, Andreas Jaeger wrote: [...] >> >> I'm not sure the ldconfig changes make it. I'm moving across the >> country next week and have two weeks holiday. I'll try to look at it >> again today but if you don't get anything, I won't make it in time for >> the release :-(. Jakub> If it is the -r and chroot thing, I can write a patch (but let me know if Jakub> you're working on it or not, so that we don't write it twice). That's what I mean. I would appreciate if you would work on it, you can take my first patch as basis. Thanks, Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From jakub@redhat.com Fri Sep 29 03:02:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Fri, 29 Sep 2000 03:02:00 -0000 Subject: next test release (5th) References: <20000929093016.A3784@suse.de> Message-ID: <20000929120507.A9588@sunsite.ms.mff.cuni.cz> On Fri, Sep 29, 2000 at 09:30:16AM +0200, Thorsten Kukuk wrote: > The other problem I found is the nscd interface. It seems it is > incompatible between 32bit and 64bit platforms. This will be a > problem with all the upcoming platforms which support 32 and 64bit > binaries. But I don't think that we need to solve it now. I even > don't know where the problem is. Ok, this is untested, I just wonder if it is the right way to go. The issue is that nscd and its client send a lot of size_t and ssize_t data over the socket, but those types differ between 32bit and 64bit. >From quick look at what sizes and counts those entries represents it looks to me like they'll always fit into 32 bits, I really cannot imagine system with usernames 5GB long, or group names, hostnames, home directory pathnames and the like. As we need to maintain nscd binary compatibility at least on alpha, I have introduced new header which all architectures which will have dual wordsize libraries natively should override. 2000-09-29 Jakub Jelinek * nscd/nscd-client.h: Include nscd-types.h. Use nscd_ssize_t where appropriate. * sysdeps/generic/nscd-types.h: New file. * sysdeps/sparc/nscd-types.h: New file. * nscd/nscd_gethst_r.c (nscd_gethst_r): Use nscd_size_t where appropriate. * nscd/nscd_getgr_r.c (nscd_getgr_r): Likewise. * nscd/hstcache.c (cache_addhst): Likewise. * nscd/grpcache.c (cache_addgr): Likewise. --- libc/nscd/nscd_gethst_r.c.jj Wed May 3 10:19:59 2000 +++ libc/nscd/nscd_gethst_r.c Fri Sep 29 11:30:57 2000 @@ -165,7 +165,7 @@ nscd_gethst_r (const char *key, size_t k if (hst_resp.found == 1) { struct iovec vec[4]; - size_t *aliases_len; + nscd_size_t *aliases_len; char *cp = buffer; uintptr_t align1; uintptr_t align2; @@ -206,12 +206,12 @@ nscd_gethst_r (const char *key, size_t k vec[0].iov_base = resultbuf->h_name; vec[0].iov_len = hst_resp.h_name_len; - aliases_len = alloca (hst_resp.h_aliases_cnt * sizeof (size_t)); + aliases_len = alloca (hst_resp.h_aliases_cnt * sizeof (nscd_size_t)); vec[1].iov_base = aliases_len; - vec[1].iov_len = hst_resp.h_aliases_cnt * sizeof (size_t); + vec[1].iov_len = hst_resp.h_aliases_cnt * sizeof (nscd_size_t); total_len = (hst_resp.h_name_len - + hst_resp.h_aliases_cnt * sizeof (size_t)); + + hst_resp.h_aliases_cnt * sizeof (nscd_size_t)); n = 2; if (type == GETHOSTBYADDR || type == GETHOSTBYNAME) --- libc/nscd/hstcache.c.jj Tue Mar 21 11:58:16 2000 +++ libc/nscd/hstcache.c Fri Sep 29 11:32:13 2000 @@ -125,7 +125,7 @@ cache_addhst (struct database *db, int f struct hostdata *data; size_t h_name_len = strlen (hst->h_name) + 1; size_t h_aliases_cnt; - size_t *h_aliases_len; + nscd_size_t *h_aliases_len; size_t h_addr_list_cnt; int addr_list_type; char *addresses; @@ -139,7 +139,7 @@ cache_addhst (struct database *db, int f for (cnt = 0; hst->h_aliases[cnt] != NULL; ++cnt) ++h_aliases_cnt; /* Determine the length of all aliases. */ - h_aliases_len = alloca (h_aliases_cnt * sizeof (size_t)); + h_aliases_len = alloca (h_aliases_cnt * sizeof (nscd_size_t)); total = 0; for (cnt = 0; cnt < h_aliases_cnt; ++cnt) { @@ -156,7 +156,7 @@ cache_addhst (struct database *db, int f the response header and the dataset itself. */ total += (sizeof (struct hostdata) + h_name_len - + h_aliases_cnt * sizeof (size_t) + + h_aliases_cnt * sizeof (nscd_size_t) + h_addr_list_cnt * hst->h_length); data = (struct hostdata *) malloc (total + req->key_len); @@ -175,7 +175,7 @@ cache_addhst (struct database *db, int f cp = data->strdata; cp = mempcpy (cp, hst->h_name, h_name_len); - cp = mempcpy (cp, h_aliases_len, h_aliases_cnt * sizeof (size_t)); + cp = mempcpy (cp, h_aliases_len, h_aliases_cnt * sizeof (nscd_size_t)); /* The normal addresses first. */ addresses = cp; --- libc/nscd/grpcache.c.jj Wed May 3 10:19:59 2000 +++ libc/nscd/grpcache.c Fri Sep 29 11:28:50 2000 @@ -117,7 +117,7 @@ cache_addgr (struct database *db, int fd size_t gr_name_len = strlen (grp->gr_name) + 1; size_t gr_passwd_len = strlen (grp->gr_passwd) + 1; size_t gr_mem_cnt = 0; - size_t *gr_mem_len; + nscd_size_t *gr_mem_len; size_t gr_mem_len_total = 0; char *gr_name; char *cp; @@ -131,7 +131,7 @@ cache_addgr (struct database *db, int fd /* Determine the length of all members. */ while (grp->gr_mem[gr_mem_cnt]) ++gr_mem_cnt; - gr_mem_len = (size_t *) alloca (gr_mem_cnt * sizeof (size_t)); + gr_mem_len = (nscd_size_t *) alloca (gr_mem_cnt * sizeof (nscd_size_t)); for (gr_mem_cnt = 0; grp->gr_mem[gr_mem_cnt]; ++gr_mem_cnt) { gr_mem_len[gr_mem_cnt] = strlen (grp->gr_mem[gr_mem_cnt]) + 1; @@ -141,7 +141,7 @@ cache_addgr (struct database *db, int fd /* We allocate all data in one memory block: the iov vector, the response header and the dataset itself. */ total = (sizeof (struct groupdata) - + gr_mem_cnt * sizeof (size_t) + + gr_mem_cnt * sizeof (nscd_size_t) + gr_name_len + gr_passwd_len + gr_mem_len_total); data = (struct groupdata *) malloc (total + n); if (data == NULL) @@ -157,7 +157,7 @@ cache_addgr (struct database *db, int fd cp = data->strdata; /* This is the member string length array. */ - cp = mempcpy (cp, gr_mem_len, gr_mem_cnt * sizeof (size_t)); + cp = mempcpy (cp, gr_mem_len, gr_mem_cnt * sizeof (nscd_size_t)); gr_name = cp; cp = mempcpy (cp, grp->gr_name, gr_name_len); cp = mempcpy (cp, grp->gr_passwd, gr_passwd_len); --- libc/nscd/nscd-client.h.jj Mon Sep 27 02:20:13 1999 +++ libc/nscd/nscd-client.h Fri Sep 29 11:51:46 2000 @@ -1,4 +1,4 @@ -/* Copyright (c) 1998, 1999 Free Software Foundation, Inc. +/* Copyright (c) 1998, 1999, 2000 Free Software Foundation, Inc. This file is part of the GNU C Library. Contributed by Thorsten Kukuk , 1998. @@ -23,6 +23,8 @@ #ifndef _NSCD_CLIENT_H #define _NSCD_CLIENT_H 1 +#include + /* Version number of the daemon interface */ #define NSCD_VERSION 2 @@ -60,7 +62,7 @@ typedef struct { int version; /* Version number of the daemon interface. */ request_type type; /* Service requested. */ - ssize_t key_len; /* Key length. */ + nscd_ssize_t key_len; /* Key length. */ } request_header; @@ -70,13 +72,13 @@ typedef struct { int version; int found; - ssize_t pw_name_len; - ssize_t pw_passwd_len; + nscd_ssize_t pw_name_len; + nscd_ssize_t pw_passwd_len; uid_t pw_uid; gid_t pw_gid; - ssize_t pw_gecos_len; - ssize_t pw_dir_len; - ssize_t pw_shell_len; + nscd_ssize_t pw_gecos_len; + nscd_ssize_t pw_dir_len; + nscd_ssize_t pw_shell_len; } pw_response_header; @@ -86,10 +88,10 @@ typedef struct { int version; int found; - ssize_t gr_name_len; - ssize_t gr_passwd_len; + nscd_ssize_t gr_name_len; + nscd_ssize_t gr_passwd_len; gid_t gr_gid; - ssize_t gr_mem_cnt; + nscd_ssize_t gr_mem_cnt; } gr_response_header; @@ -99,11 +101,11 @@ typedef struct { int version; int found; - ssize_t h_name_len; - ssize_t h_aliases_cnt; + nscd_ssize_t h_name_len; + nscd_ssize_t h_aliases_cnt; int h_addrtype; int h_length; - ssize_t h_addr_list_cnt; + nscd_ssize_t h_addr_list_cnt; int error; } hst_response_header; --- libc/nscd/nscd_getgr_r.c.jj Mon Sep 6 01:33:26 1999 +++ libc/nscd/nscd_getgr_r.c Fri Sep 29 11:33:20 2000 @@ -1,4 +1,4 @@ -/* Copyright (C) 1998, 1999 Free Software Foundation, Inc. +/* Copyright (C) 1998, 1999, 2000 Free Software Foundation, Inc. This file is part of the GNU C Library. Contributed by Thorsten Kukuk , 1998. @@ -137,7 +137,7 @@ nscd_getgr_r (const char *key, size_t ke if (gr_resp.found == 1) { - size_t *len; + nscd_size_t *len; char *p = buffer; size_t total_len; uintptr_t align; @@ -172,9 +172,9 @@ nscd_getgr_r (const char *key, size_t ke resultbuf->gr_gid = gr_resp.gr_gid; /* Allocate array to store lengths. */ - len = alloca (gr_resp.gr_mem_cnt * sizeof (size_t)); + len = alloca (gr_resp.gr_mem_cnt * sizeof (nscd_size_t)); - total_len = gr_resp.gr_mem_cnt * sizeof (size_t); + total_len = gr_resp.gr_mem_cnt * sizeof (nscd_size_t); vec[0].iov_base = len; vec[0].iov_len = total_len; vec[1].iov_base = resultbuf->gr_name; --- libc/sysdeps/generic/nscd-types.h.jj Fri Sep 29 11:36:00 2000 +++ libc/sysdeps/generic/nscd-types.h Fri Sep 29 11:35:54 2000 @@ -0,0 +1,22 @@ +/* Copyright (C) 2000 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Library General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Library General Public License for more details. + + You should have received a copy of the GNU Library General Public + License along with the GNU C Library; see the file COPYING.LIB. If not, + write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, + Boston, MA 02111-1307, USA. */ + +#include + +typedef size_t nscd_size_t; +typedef ssize_t nscd_ssize_t; --- libc/sysdeps/sparc/nscd-types.h.jj Fri Sep 29 11:36:00 2000 +++ libc/sysdeps/sparc/nscd-types.h Fri Sep 29 11:45:16 2000 @@ -0,0 +1,24 @@ +/* Copyright (C) 2000 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Library General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Library General Public License for more details. + + You should have received a copy of the GNU Library General Public + License along with the GNU C Library; see the file COPYING.LIB. If not, + write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, + Boston, MA 02111-1307, USA. */ + +#include + +/* So that 32bit glibc can talk to 64bit nscd and vice versa, we need to + be binary compatible. */ +typedef u_int32_t nscd_size_t; +typedef int32_t nscd_ssize_t; Jakub From drepper@redhat.com Fri Sep 29 07:54:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Fri, 29 Sep 2000 07:54:00 -0000 Subject: next test release (5th) References: Message-ID: Andreas Jaeger writes: > I'm not sure the ldconfig changes make it. OK, that's fine. > What about my Patches with Subject: "leases/locks in 2.4.0-test9-pre7 > - sync glibc and kernel" ? Haven't seen it yet. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Fri Sep 29 07:58:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Fri, 29 Sep 2000 07:58:00 -0000 Subject: next test release (5th) References: <20000929093016.A3784@suse.de> <20000929120507.A9588@sunsite.ms.mff.cuni.cz> Message-ID: Jakub Jelinek writes: > --- libc/nscd/nscd_gethst_r.c.jj Wed May 3 10:19:59 2000 > +++ libc/nscd/nscd_gethst_r.c Fri Sep 29 11:30:57 2000 > @@ -165,7 +165,7 @@ nscd_gethst_r (const char *key, size_t k > if (hst_resp.found == 1) > { > struct iovec vec[4]; > - size_t *aliases_len; > + nscd_size_t *aliases_len; > char *cp = buffer; > uintptr_t align1; > uintptr_t align2; This is perfectly fine. There is no real need for using size_t. I would perhaps just using uint32_t and int32_t instead of introducing another type. I'll probably make this change in your patch. Otherwise people will ask why such a named type is necessry. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From kukuk@suse.de Fri Sep 29 08:00:00 2000 From: kukuk@suse.de (Thorsten Kukuk) Date: Fri, 29 Sep 2000 08:00:00 -0000 Subject: next test release (5th) References: <20000929093016.A3784@suse.de> <20000929120507.A9588@sunsite.ms.mff.cuni.cz> Message-ID: <20000929170018.A4988@suse.de> On Fri, Sep 29, Ulrich Drepper wrote: > Jakub Jelinek writes: > > > --- libc/nscd/nscd_gethst_r.c.jj Wed May 3 10:19:59 2000 > > +++ libc/nscd/nscd_gethst_r.c Fri Sep 29 11:30:57 2000 > > @@ -165,7 +165,7 @@ nscd_gethst_r (const char *key, size_t k > > if (hst_resp.found == 1) > > { > > struct iovec vec[4]; > > - size_t *aliases_len; > > + nscd_size_t *aliases_len; > > char *cp = buffer; > > uintptr_t align1; > > uintptr_t align2; > > This is perfectly fine. There is no real need for using size_t. I > would perhaps just using uint32_t and int32_t instead of introducing > another type. I'll probably make this change in your patch. > Otherwise people will ask why such a named type is necessry. It is necessary to be binary compatible on Alpha. Or we need to bump the nscd version number. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background. From jakub@redhat.com Fri Sep 29 08:03:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Fri, 29 Sep 2000 08:03:00 -0000 Subject: next test release (5th) References: <20000929093016.A3784@suse.de> <20000929120507.A9588@sunsite.ms.mff.cuni.cz> <20000929170018.A4988@suse.de> Message-ID: <20000929170610.B9588@sunsite.ms.mff.cuni.cz> On Fri, Sep 29, 2000 at 05:00:18PM +0200, Thorsten Kukuk wrote: > On Fri, Sep 29, Ulrich Drepper wrote: > > > Jakub Jelinek writes: > > > > > --- libc/nscd/nscd_gethst_r.c.jj Wed May 3 10:19:59 2000 > > > +++ libc/nscd/nscd_gethst_r.c Fri Sep 29 11:30:57 2000 > > > @@ -165,7 +165,7 @@ nscd_gethst_r (const char *key, size_t k > > > if (hst_resp.found == 1) > > > { > > > struct iovec vec[4]; > > > - size_t *aliases_len; > > > + nscd_size_t *aliases_len; > > > char *cp = buffer; > > > uintptr_t align1; > > > uintptr_t align2; > > > > This is perfectly fine. There is no real need for using size_t. I > > would perhaps just using uint32_t and int32_t instead of introducing > > another type. I'll probably make this change in your patch. > > Otherwise people will ask why such a named type is necessry. > > It is necessary to be binary compatible on Alpha. Or we need to > bump the nscd version number. I think we should bump and use *int32_t then... Jakub From jakub@redhat.com Fri Sep 29 08:13:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Fri, 29 Sep 2000 08:13:00 -0000 Subject: next test release (5th) References: <20000929093016.A3784@suse.de> <20000929120507.A9588@sunsite.ms.mff.cuni.cz> <20000929170018.A4988@suse.de> Message-ID: <20000929171605.C9588@sunsite.ms.mff.cuni.cz> On Fri, Sep 29, 2000 at 05:00:18PM +0200, Thorsten Kukuk wrote: > > This is perfectly fine. There is no real need for using size_t. I > > would perhaps just using uint32_t and int32_t instead of introducing > > another type. I'll probably make this change in your patch. > > Otherwise people will ask why such a named type is necessry. > > It is necessary to be binary compatible on Alpha. Or we need to > bump the nscd version number. Here is an updated patch: 2000-09-29 Jakub Jelinek * nscd/nscd-client.h (NSCD_VERSION): Bump to 3. Use int32_t where appropriate. * nscd/nscd_gethst_r.c (nscd_gethst_r): Use u_int32_t where appropriate. * nscd/nscd_getgr_r.c (nscd_getgr_r): Likewise. * nscd/hstcache.c (cache_addhst): Likewise. * nscd/grpcache.c (cache_addgr): Likewise. --- libc/nscd/nscd_gethst_r.c.jj Wed May 3 10:19:59 2000 +++ libc/nscd/nscd_gethst_r.c Fri Sep 29 17:10:36 2000 @@ -165,7 +165,7 @@ nscd_gethst_r (const char *key, size_t k if (hst_resp.found == 1) { struct iovec vec[4]; - size_t *aliases_len; + u_int32_t *aliases_len; char *cp = buffer; uintptr_t align1; uintptr_t align2; @@ -206,12 +206,12 @@ nscd_gethst_r (const char *key, size_t k vec[0].iov_base = resultbuf->h_name; vec[0].iov_len = hst_resp.h_name_len; - aliases_len = alloca (hst_resp.h_aliases_cnt * sizeof (size_t)); + aliases_len = alloca (hst_resp.h_aliases_cnt * sizeof (u_int32_t)); vec[1].iov_base = aliases_len; - vec[1].iov_len = hst_resp.h_aliases_cnt * sizeof (size_t); + vec[1].iov_len = hst_resp.h_aliases_cnt * sizeof (u_int32_t); total_len = (hst_resp.h_name_len - + hst_resp.h_aliases_cnt * sizeof (size_t)); + + hst_resp.h_aliases_cnt * sizeof (u_int32_t)); n = 2; if (type == GETHOSTBYADDR || type == GETHOSTBYNAME) --- libc/nscd/hstcache.c.jj Tue Mar 21 11:58:16 2000 +++ libc/nscd/hstcache.c Fri Sep 29 17:10:36 2000 @@ -125,7 +125,7 @@ cache_addhst (struct database *db, int f struct hostdata *data; size_t h_name_len = strlen (hst->h_name) + 1; size_t h_aliases_cnt; - size_t *h_aliases_len; + u_int32_t *h_aliases_len; size_t h_addr_list_cnt; int addr_list_type; char *addresses; @@ -139,7 +139,7 @@ cache_addhst (struct database *db, int f for (cnt = 0; hst->h_aliases[cnt] != NULL; ++cnt) ++h_aliases_cnt; /* Determine the length of all aliases. */ - h_aliases_len = alloca (h_aliases_cnt * sizeof (size_t)); + h_aliases_len = alloca (h_aliases_cnt * sizeof (u_int32_t)); total = 0; for (cnt = 0; cnt < h_aliases_cnt; ++cnt) { @@ -156,7 +156,7 @@ cache_addhst (struct database *db, int f the response header and the dataset itself. */ total += (sizeof (struct hostdata) + h_name_len - + h_aliases_cnt * sizeof (size_t) + + h_aliases_cnt * sizeof (u_int32_t) + h_addr_list_cnt * hst->h_length); data = (struct hostdata *) malloc (total + req->key_len); @@ -175,7 +175,7 @@ cache_addhst (struct database *db, int f cp = data->strdata; cp = mempcpy (cp, hst->h_name, h_name_len); - cp = mempcpy (cp, h_aliases_len, h_aliases_cnt * sizeof (size_t)); + cp = mempcpy (cp, h_aliases_len, h_aliases_cnt * sizeof (u_int32_t)); /* The normal addresses first. */ addresses = cp; --- libc/nscd/grpcache.c.jj Wed May 3 10:19:59 2000 +++ libc/nscd/grpcache.c Fri Sep 29 17:10:36 2000 @@ -117,7 +117,7 @@ cache_addgr (struct database *db, int fd size_t gr_name_len = strlen (grp->gr_name) + 1; size_t gr_passwd_len = strlen (grp->gr_passwd) + 1; size_t gr_mem_cnt = 0; - size_t *gr_mem_len; + u_int32_t *gr_mem_len; size_t gr_mem_len_total = 0; char *gr_name; char *cp; @@ -131,7 +131,7 @@ cache_addgr (struct database *db, int fd /* Determine the length of all members. */ while (grp->gr_mem[gr_mem_cnt]) ++gr_mem_cnt; - gr_mem_len = (size_t *) alloca (gr_mem_cnt * sizeof (size_t)); + gr_mem_len = (u_int32_t *) alloca (gr_mem_cnt * sizeof (nscd_size_t)); for (gr_mem_cnt = 0; grp->gr_mem[gr_mem_cnt]; ++gr_mem_cnt) { gr_mem_len[gr_mem_cnt] = strlen (grp->gr_mem[gr_mem_cnt]) + 1; @@ -141,7 +141,7 @@ cache_addgr (struct database *db, int fd /* We allocate all data in one memory block: the iov vector, the response header and the dataset itself. */ total = (sizeof (struct groupdata) - + gr_mem_cnt * sizeof (size_t) + + gr_mem_cnt * sizeof (u_int32_t) + gr_name_len + gr_passwd_len + gr_mem_len_total); data = (struct groupdata *) malloc (total + n); if (data == NULL) @@ -157,7 +157,7 @@ cache_addgr (struct database *db, int fd cp = data->strdata; /* This is the member string length array. */ - cp = mempcpy (cp, gr_mem_len, gr_mem_cnt * sizeof (size_t)); + cp = mempcpy (cp, gr_mem_len, gr_mem_cnt * sizeof (u_int32_t)); gr_name = cp; cp = mempcpy (cp, grp->gr_name, gr_name_len); cp = mempcpy (cp, grp->gr_passwd, gr_passwd_len); --- libc/nscd/nscd-client.h.jj Mon Sep 27 02:20:13 1999 +++ libc/nscd/nscd-client.h Fri Sep 29 17:11:43 2000 @@ -1,4 +1,4 @@ -/* Copyright (c) 1998, 1999 Free Software Foundation, Inc. +/* Copyright (c) 1998, 1999, 2000 Free Software Foundation, Inc. This file is part of the GNU C Library. Contributed by Thorsten Kukuk , 1998. @@ -24,7 +24,7 @@ #define _NSCD_CLIENT_H 1 /* Version number of the daemon interface */ -#define NSCD_VERSION 2 +#define NSCD_VERSION 3 /* Path of the file where the PID of the running system is stored. */ #define _PATH_NSCDPID "/var/run/nscd.pid" @@ -60,7 +60,7 @@ typedef struct { int version; /* Version number of the daemon interface. */ request_type type; /* Service requested. */ - ssize_t key_len; /* Key length. */ + int32_t key_len; /* Key length. */ } request_header; @@ -68,15 +68,15 @@ typedef struct sent also if the service is disabled or there is no record found. */ typedef struct { - int version; - int found; - ssize_t pw_name_len; - ssize_t pw_passwd_len; + int32_t version; + int32_t found; + int32_t pw_name_len; + int32_t pw_passwd_len; uid_t pw_uid; gid_t pw_gid; - ssize_t pw_gecos_len; - ssize_t pw_dir_len; - ssize_t pw_shell_len; + int32_t pw_gecos_len; + int32_t pw_dir_len; + int32_t pw_shell_len; } pw_response_header; @@ -84,12 +84,12 @@ typedef struct sent also if the service is disabled or there is no record found. */ typedef struct { - int version; - int found; - ssize_t gr_name_len; - ssize_t gr_passwd_len; + int32_t version; + int32_t found; + int32_t gr_name_len; + int32_t gr_passwd_len; gid_t gr_gid; - ssize_t gr_mem_cnt; + int32_t gr_mem_cnt; } gr_response_header; @@ -97,14 +97,14 @@ typedef struct sent also if the service is disabled or there is no record found. */ typedef struct { - int version; - int found; - ssize_t h_name_len; - ssize_t h_aliases_cnt; - int h_addrtype; - int h_length; - ssize_t h_addr_list_cnt; - int error; + int32_t version; + int32_t found; + int32_t h_name_len; + int32_t h_aliases_cnt; + int32_t h_addrtype; + int32_t h_length; + int32_t h_addr_list_cnt; + int32_t error; } hst_response_header; --- libc/nscd/nscd_getgr_r.c.jj Mon Sep 6 01:33:26 1999 +++ libc/nscd/nscd_getgr_r.c Fri Sep 29 17:10:36 2000 @@ -1,4 +1,4 @@ -/* Copyright (C) 1998, 1999 Free Software Foundation, Inc. +/* Copyright (C) 1998, 1999, 2000 Free Software Foundation, Inc. This file is part of the GNU C Library. Contributed by Thorsten Kukuk , 1998. @@ -137,7 +137,7 @@ nscd_getgr_r (const char *key, size_t ke if (gr_resp.found == 1) { - size_t *len; + u_int32_t *len; char *p = buffer; size_t total_len; uintptr_t align; @@ -172,9 +172,9 @@ nscd_getgr_r (const char *key, size_t ke resultbuf->gr_gid = gr_resp.gr_gid; /* Allocate array to store lengths. */ - len = alloca (gr_resp.gr_mem_cnt * sizeof (size_t)); + len = alloca (gr_resp.gr_mem_cnt * sizeof (u_int32_t)); - total_len = gr_resp.gr_mem_cnt * sizeof (size_t); + total_len = gr_resp.gr_mem_cnt * sizeof (u_int32_t); vec[0].iov_base = len; vec[0].iov_len = total_len; vec[1].iov_base = resultbuf->gr_name; Jakub From jakub@redhat.com Fri Sep 29 09:35:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Fri, 29 Sep 2000 09:35:00 -0000 Subject: First ldconfig -r without chroot attempt Message-ID: <20000929183825.D9588@sunsite.ms.mff.cuni.cz> Hi! Below is my first chroot -r without chroot() attempt. I haven't tested it thouroughly, just ran it a few times (with the chroot() call commented out in main) to see if it created the same ld.so.cache as old ldconfig and did not mess any symlinks and it looked fine, but it needs both a proof reading and more testing. Basically, I hacked canonicalize.c, so that it prepends a chroot prefix to the path and whenever some symlink is absolute or there are too many ../ path items, it limits the path into that "chroot". This is slightly slower than using chroot(), that's why I try in main to use chroot and only if it fails use this canonicalization. Also, so that the user is not too surprised, I try to print in all messages the user given paths and not the canonicalized ones (e.g. if in /mnt chroot there is a /usr/lib -> /foo/bar/lib symlink, I don't print /mnt/foo/bar/lib or /foo/bar/lib paths, but /usr/lib). The user given paths are needed in some cases anyway (e.g. those paths are stored into the cache). Also, I think ldconfig should be consistent in what paths it prints, and as 95% of ldconfig with -r /mnt prints the paths without the leading /mnt prefix, I have removed the only place where Ulrich added it. As those paths should be e.g. present in the ldconfig -p printout, it would be e.g. weird if normal ldconfig output uses paths without prefix and stderr with prefix. Comments/testing welcome :) 2000-09-29 Jakub Jelinek * elf/chroot_canon.c: New file. * elf/ldconfig.h (process_file): Add real_file_name argument. (chroot_canon): Add prototype. * elf/ldconfig.c (cache_file): Remove const. (chroot_stat): New. (create_links): Add real_path argument. If opt_chroot, maintain both real and given filenames. (manual_link): Likewise. (search_dir): Likewise. (parse_conf): If opt_chroot, use chroot_canon to find the real config file. (main): For -r, try to use chroot, if it fails, leave opt_chroot set and use chroot_canon where appropriate to do the same as if chroot succeeded. * elf/readlib.c (process_file): Add real_file_name argument, pass it to fopen. --- libc/elf/chroot_canon.c.jj Fri Sep 29 13:51:00 2000 +++ libc/elf/chroot_canon.c Fri Sep 29 14:40:18 2000 @@ -0,0 +1,164 @@ +/* Return the canonical absolute name of a given file inside chroot. + Copyright (C) 1996, 1997, 1998, 1999, 2000 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Library General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Library General Public License for more details. + + You should have received a copy of the GNU Library General Public + License along with the GNU C Library; see the file COPYING.LIB. If not, + write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, + Boston, MA 02111-1307, USA. */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include "ldconfig.h" + +#ifndef PATH_MAX +#define PATH_MAX 1024 +#endif + +/* Return the canonical absolute name of file NAME as if chroot(CHROOT) was + done first. A canonical name does not contain any `.', `..' components + nor any repeated path separators ('/') or symlinks. All path components + must exist and NAME must be absolute filename. The result is malloc'd. + The returned name includes the CHROOT prefix. */ + +char * +chroot_canon (const char *chroot, const char *name) +{ + char *rpath, *dest, *extra_buf = NULL, *rpath_root; + const char *start, *end, *rpath_limit; + int num_links = 0; + size_t chroot_len = strlen(chroot); + + if (chroot_len < 1) + { + __set_errno (EINVAL); + return NULL; + } + + rpath = malloc (chroot_len + PATH_MAX); + rpath_limit = rpath + chroot_len + PATH_MAX; + + strcpy (rpath, chroot); + rpath_root = rpath + chroot_len - 1; + if (*rpath_root != '/') + *++rpath_root = '/'; + dest = rpath_root + 1; + + for (start = end = name; *start; start = end) + { + struct stat64 st; + int n; + + /* Skip sequence of multiple path-separators. */ + while (*start == '/') + ++start; + + /* Find end of path component. */ + for (end = start; *end && *end != '/'; ++end) + /* Nothing. */; + + if (end - start == 0) + break; + else if (end - start == 1 && start[0] == '.') + /* nothing */; + else if (end - start == 2 && start[0] == '.' && start[1] == '.') + { + /* Back up to previous component, ignore if at root already. */ + if (dest > rpath_root + 1) + while ((--dest)[-1] != '/'); + } + else + { + size_t new_size; + + if (dest[-1] != '/') + *dest++ = '/'; + + if (dest + (end - start) >= rpath_limit) + { + ptrdiff_t dest_offset = dest - rpath; + + new_size = rpath_limit - rpath; + if (end - start + 1 > PATH_MAX) + new_size += end - start + 1; + else + new_size += PATH_MAX; + rpath = realloc (rpath, new_size); + rpath_limit = rpath + new_size; + if (rpath == NULL) + return NULL; + + dest = rpath + dest_offset; + } + + dest = mempcpy (dest, start, end - start); + *dest = '\0'; + + if (lstat64 (rpath, &st) < 0) + goto error; + + if (S_ISLNK (st.st_mode)) + { + char *buf = alloca (PATH_MAX); + size_t len; + + if (++num_links > MAXSYMLINKS) + { + __set_errno (ELOOP); + goto error; + } + + n = readlink (rpath, buf, PATH_MAX); + if (n < 0) + goto error; + buf[n] = '\0'; + + if (!extra_buf) + extra_buf = alloca (PATH_MAX); + + len = strlen (end); + if ((long int) (n + len) >= PATH_MAX) + { + __set_errno (ENAMETOOLONG); + goto error; + } + + /* Careful here, end may be a pointer into extra_buf... */ + memmove (&extra_buf[n], end, len + 1); + name = end = memcpy (extra_buf, buf, n); + + if (buf[0] == '/') + dest = rpath_root + 1; /* It's an absolute symlink */ + else + /* Back up to previous component, ignore if at root already: */ + if (dest > rpath_root + 1) + while ((--dest)[-1] != '/'); + } + } + } + if (dest > rpath_root + 1 && dest[-1] == '/') + --dest; + *dest = '\0'; + + return rpath; + +error: + free (rpath); + return NULL; +} --- libc/elf/ldconfig.h.jj Wed May 31 23:02:38 2000 +++ libc/elf/ldconfig.h Fri Sep 29 17:39:52 2000 @@ -41,14 +41,17 @@ extern void add_to_cache (const char *pa unsigned long int hwcap); /* Declared in readlib.c. */ -extern int process_file (const char *file_name, const char *lib, int *flag, - char **soname, int is_link); +extern int process_file (const char *real_file_name, const char *file_name, + const char *lib, int *flag, char **soname, + int is_link); /* Declared in readelflib.c. */ extern int process_elf_file (const char *file_name, const char *lib, int *flag, char **soname, void *file_contents, size_t file_length); +/* Declared in chroot_canon.c. */ +extern char *chroot_canon (const char *chroot, const char *name); /* Declared in ldconfig.c. */ extern int opt_verbose; --- libc/elf/ldconfig.c.jj Fri Sep 29 12:56:56 2000 +++ libc/elf/ldconfig.c Fri Sep 29 18:09:55 2000 @@ -110,7 +110,7 @@ static char *opt_chroot; static int opt_manual_link = 0; /* Cache file to use. */ -static const char *cache_file; +static char *cache_file; /* Configuration file. */ static const char *config_file; @@ -334,11 +334,35 @@ add_dir (const char *line) } +static int +chroot_stat (const char *real_path, const char *path, struct stat *st) +{ + int ret; + char *canon_path; + + if (!opt_chroot) + return stat (real_path, st); + + ret = lstat (real_path, st); + if (ret || !S_ISLNK (st->st_mode)) + return ret; + + canon_path = chroot_canon (opt_chroot, path); + if (canon_path == NULL) + return -1; + + ret = stat (canon_path, st); + free (canon_path); + return ret; +} + /* Create a symbolic link from soname to libname in directory path. */ static void -create_links (const char *path, const char *libname, const char *soname) +create_links (const char *real_path, const char *path, const char *libname, + const char *soname) { char *full_libname, *full_soname; + char *real_full_libname, *real_full_soname; struct stat stat_lib, stat_so, lstat_so; int do_link = 1; int do_remove = 1; @@ -349,11 +373,23 @@ create_links (const char *path, const ch full_soname = alloca (strlen (path) + strlen (libname) + 2); sprintf (full_libname, "%s/%s", path, libname); sprintf (full_soname, "%s/%s", path, soname); + if (opt_chroot) + { + real_full_libname = alloca (strlen (real_path) + strlen (libname) + 2); + real_full_soname = alloca (strlen (real_path) + strlen (libname) + 2); + sprintf (real_full_libname, "%s/%s", real_path, libname); + sprintf (real_full_soname, "%s/%s", real_path, soname); + } + else + { + real_full_libname = full_libname; + real_full_soname = full_soname; + } /* Does soname already exist and point to the right library? */ - if (stat (full_soname, &stat_so) == 0) + if (chroot_stat (real_full_soname, full_soname, &stat_so) == 0) { - if (stat (full_libname, &stat_lib)) + if (chroot_stat (real_full_libname, full_libname, &stat_lib)) { error (0, 0, _("Can't stat %s\n"), full_libname); return; @@ -370,7 +406,7 @@ create_links (const char *path, const ch do_remove = 0; } } - else if (lstat (full_soname, &lstat_so) != 0 + else if (lstat (real_full_soname, &lstat_so) != 0 || !S_ISLNK (lstat_so.st_mode)) /* Unless it is a stale symlink, there is no need to remove. */ do_remove = 0; @@ -382,13 +418,13 @@ create_links (const char *path, const ch { /* Remove old link. */ if (do_remove) - if (unlink (full_soname)) + if (unlink (real_full_soname)) { error (0, 0, _("Can't unlink %s"), full_soname); do_link = 0; } /* Create symbolic link. */ - if (do_link && symlink (libname, full_soname)) + if (do_link && symlink (libname, real_full_soname)) { error (0, 0, _("Can't link %s to %s"), full_soname, libname); do_link = 0; @@ -410,6 +446,8 @@ static void manual_link (char *library) { char *path; + char *real_path; + char *real_library; char *libname; char *soname; struct stat stat_buf; @@ -445,8 +483,26 @@ manual_link (char *library) strcpy (path, "."); } + if (opt_chroot) + { + real_path = chroot_canon (opt_chroot, path); + if (real_path == NULL) + { + error (0, errno, _("Can't find %s"), path); + free (path); + return; + } + real_library = alloca (strlen (real_path) + strlen (libname) + 2); + sprintf (real_library, "%s/%s", real_path, libname); + } + else + { + real_path = path; + real_library = library; + } + /* Do some sanity checks first. */ - if (lstat (library, &stat_buf)) + if (lstat (real_library, &stat_buf)) { error (0, errno, _("Can't lstat %s"), library); free (path); @@ -460,15 +516,14 @@ manual_link (char *library) free (path); return; } - libname = basename (library); - if (process_file (library, libname, &flag, &soname, 0)) + if (process_file (real_library, library, libname, &flag, &soname, 0)) { error (0, 0, _("No link created since soname could not be found for %s"), library); free (path); return; } - create_links (path, libname, soname); + create_links (real_path, path, libname, soname); free (soname); free (path); } @@ -514,8 +569,8 @@ search_dir (const struct dir_entry *entr { DIR *dir; struct dirent *direntry; - char *file_name; - int file_name_len, len; + char *file_name, *dir_name, *real_file_name, *real_name; + int file_name_len, real_file_name_len, len; char *soname; struct dlib_entry *dlibs; struct dlib_entry *dlib_ptr; @@ -536,15 +591,28 @@ search_dir (const struct dir_entry *entr printf ("%s:\n", entry->path); } - dir = opendir (entry->path); - if (dir == NULL) + if (opt_chroot) + { + dir_name = chroot_canon (opt_chroot, entry->path); + real_file_name_len = PATH_MAX; + real_file_name = alloca (real_file_name_len); + } + else + { + dir_name = entry->path; + real_file_name_len = 0; + real_file_name = file_name; + } + + if (dir_name == NULL || (dir = opendir (dir_name)) == NULL) { if (opt_verbose) error (0, errno, _("Can't open directory %s"), entry->path); + if (opt_chroot && dir_name) + free (dir_name); return; } - while ((direntry = readdir (dir)) != NULL) { int flag; @@ -569,14 +637,26 @@ search_dir (const struct dir_entry *entr { file_name_len = len + 1; file_name = alloca (file_name_len); + if (!opt_chroot) + real_file_name = file_name; + } + sprintf (file_name, "%s/%s", entry->path, direntry->d_name); + if (opt_chroot) + { + len = strlen (dir_name) + strlen (direntry->d_name); + if (len > real_file_name_len) + { + real_file_name_len = len + 1; + real_file_name = alloca (real_file_name_len); + } + sprintf (real_file_name, "%s/%s", dir_name, direntry->d_name); } - sprintf (file_name , "%s/%s", entry->path, direntry->d_name); #ifdef _DIRENT_HAVE_D_TYPE if (direntry->d_type != DT_UNKNOWN) stat_buf.st_mode = DTTOIF (direntry->d_type); else #endif - if (lstat (file_name, &stat_buf)) + if (lstat (real_file_name, &stat_buf)) { error (0, errno, _("Can't lstat %s"), file_name); continue; @@ -598,9 +678,29 @@ search_dir (const struct dir_entry *entr continue; is_link = S_ISLNK (stat_buf.st_mode); + if (opt_chroot && is_link) + { + real_name = chroot_canon (opt_chroot, file_name); + if (real_name == NULL) + { + if (strstr (file_name, ".so") == NULL) + error (0, 0, _("Input file %s not found.\n"), file_name); + continue; + } + } + else + real_name = real_file_name; - if (process_file (file_name, direntry->d_name, &flag, &soname, is_link)) - continue; + if (process_file (real_name, file_name, direntry->d_name, &flag, + &soname, is_link)) + { + if (real_name != real_file_name) + free (real_name); + continue; + } + + if (real_name != real_file_name) + free (real_name); /* Links will just point to itself. */ if (is_link) @@ -686,7 +786,8 @@ search_dir (const struct dir_entry *entr { /* Don't create links to links. */ if (dlib_ptr->is_link == 0) - create_links (entry->path, dlib_ptr->name, dlib_ptr->soname); + create_links (dir_name, entry->path, dlib_ptr->name, + dlib_ptr->soname); if (opt_build_cache) add_to_cache (entry->path, dlib_ptr->soname, dlib_ptr->flag, hwcap); } @@ -700,6 +801,9 @@ search_dir (const struct dir_entry *entr dlibs = dlibs->next; free (dlib_ptr); } + + if (opt_chroot && dir_name) + free (dir_name); } /* Search through all libraries. */ @@ -726,16 +830,26 @@ search_dirs (void) static void parse_conf (const char *filename) { - FILE *file; + FILE *file = NULL; char *line = NULL; + char *canon; size_t len = 0; - file = fopen (filename, "r"); + if (opt_chroot) + { + canon = chroot_canon (opt_chroot, filename); + if (canon) + { + file = fopen (canon, "r"); + free (canon); + } + } + else + file = fopen (filename, "r"); if (file == NULL) { - error (0, errno, _("Can't open configuration file %s%s%s"), - opt_chroot ?: "", opt_chroot ? "/" : "", filename); + error (0, errno, _("Can't open configuration file %s"), filename); return; } @@ -783,33 +897,76 @@ main (int argc, char **argv) add_dir (argv [i]); } - if (cache_file == NULL) - cache_file = LD_SO_CACHE; - - if (config_file == NULL) - config_file = LD_SO_CONF; - - /* Chroot first. */ if (opt_chroot) { /* Normalize the path a bit, we might need it for printing later. */ char *endp = strchr (opt_chroot, '\0'); - while (endp > opt_chroot + 1 && endp[-1] == '/') + while (endp > opt_chroot && endp[-1] == '/') --endp; *endp = '\0'; + if (endp == opt_chroot) + opt_chroot = NULL; + + if (opt_chroot) + { + /* It is faster to use chroot if we can. */ + if (!chroot (opt_chroot)) + { + if (chdir ("/")) + error (EXIT_FAILURE, errno, _("Can't chdir to /")); + opt_chroot = NULL; + } + } + } - if (chroot (opt_chroot)) - /* Report failure and exit program. */ - error (EXIT_FAILURE, errno, _("Can't chroot to %s"), opt_chroot); - /* chroot doesn't change the working directory, let's play safe. */ - if (chdir ("/")) - error (EXIT_FAILURE, errno, _("Can't chdir to /")); + if (cache_file == NULL) + { + cache_file = alloca (strlen (LD_SO_CACHE) + 1); + strcpy (cache_file, LD_SO_CACHE); } + if (config_file == NULL) + config_file = LD_SO_CONF; + if (opt_print_cache) { + if (opt_chroot) + { + char *p = chroot_canon (opt_chroot, cache_file); + if (p == NULL) + error (EXIT_FAILURE, errno, _("Can't open cache file %s\n"), + cache_file); + cache_file = p; + } print_cache (cache_file); + if (opt_chroot) + free (cache_file); exit (0); + } + + if (opt_chroot) + { + /* Canonicalize the directory name of cache_file, not cache_file, + because we'll rename a temporary cache file to it. */ + char *p = strrchr (cache_file, '/'); + char *canon = chroot_canon (opt_chroot, + p ? (*p = '\0', cache_file) : "/"); + + if (canon == NULL) + { + error (EXIT_FAILURE, errno, + _("Can't open cache file directory %s\n"), + p ? cache_file : "/"); + } + + if (p) + ++p; + else + p = cache_file; + + cache_file = alloca (strlen (canon) + strlen (p) + 2); + sprintf (cache_file, "%s/%s", canon, p); + free (canon); } if (opt_manual_link) --- libc/elf/readlib.c.jj Tue Sep 26 09:22:27 2000 +++ libc/elf/readlib.c Fri Sep 29 17:37:00 2000 @@ -68,8 +68,8 @@ static struct known_names known_libs [] /* Returns 0 if everything is ok, != 0 in case of error. */ int -process_file (const char *file_name, const char *lib, int *flag, - char **soname, int is_link) +process_file (const char *real_file_name, const char *file_name, + const char *lib, int *flag, char **soname, int is_link) { FILE *file; struct stat statbuf; @@ -83,7 +83,7 @@ process_file (const char *file_name, con *flag = FLAG_ANY; *soname = NULL; - file = fopen (file_name, "rb"); + file = fopen (real_file_name, "rb"); if (file == NULL) { /* No error for stale symlink. */ Jakub From jakub@redhat.com Fri Sep 29 09:41:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Fri, 29 Sep 2000 09:41:00 -0000 Subject: ldconfig on ia64 Message-ID: <20000929184337.E9588@sunsite.ms.mff.cuni.cz> Hi! While playing with ldconfig, I noticed ia64 does not use its own readelflib.c nor is FLAG_IA64_LIB64 used anywhere. Is it just that some patches are not merged yet or does it mean ia64 purposedly does not want to share ld.so.cache between 64bit and 32bit libraries? Jakub From hjl@valinux.com Fri Sep 29 10:01:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Fri, 29 Sep 2000 10:01:00 -0000 Subject: ldconfig on ia64 References: <20000929184337.E9588@sunsite.ms.mff.cuni.cz> Message-ID: <20000929100115.A23479@valinux.com> On Fri, Sep 29, 2000 at 06:43:37PM +0200, Jakub Jelinek wrote: > Hi! > > While playing with ldconfig, I noticed ia64 does not use its own > readelflib.c nor is FLAG_IA64_LIB64 used anywhere. > Is it just that some patches are not merged yet or does it mean ia64 > purposedly does not want to share ld.so.cache between 64bit and 32bit > libraries? > I haven't got chances to work on that. Jes and Ulrich have fixed most of ia64 bugs now. The remaining ones are: 1. ldconfig 2. long double Jes, do you want me to work on them? I guess I know more about ldconfig than long double which may need kernel changes. I got ld-linux-ia64.s(21219): floating-point assist fault at ip 4000000000000b41 ld-linux-ia64.s(21219): floating-point assist fault at ip 4000000000000b41 when I did "make check" on long double. -- H.J. Lu (hjl@gnu.org) From hjl@valinux.com Fri Sep 29 10:35:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Fri, 29 Sep 2000 10:35:00 -0000 Subject: ldconfig patch for ia64 References: <200009281452.KAA01697@plonk.linuxcare.com> <20000928214645.C25671@devserv.devel.redhat.com> <200009291525.IAA20294@napali.hpl.hp.com> <14804.48750.374694.860233@napali.hpl.hp.com> <200009291638.e8TGcHu17510@hawking.suse.de> Message-ID: <20000929103453.A9734@valinux.com> On Fri, Sep 29, 2000 at 06:38:17PM +0200, Andreas Schwab wrote: > David Mosberger writes: > > |> >>>>> On 29 Sep 2000 17:37:36 +0200, Jes Sorensen said: > |> > |> Jes> Ahhh thanks, I must have missed this one. I am forwarding this > |> Jes> one to Uli (without the change of year of copyright back to > |> Jes> 1999 ;-). > |> > |> I ran a diff across the entire ia64 directory and found some other > |> differences: > > Here is another one, so that ldconfig can distinguish between 32bit and > 64bit objects. > > Andreas. > > 2000-09-29 Andreas Schwab > > * sysdeps/unix/sysv/linux/ia64/readelflib.c: New file. > > * elf/cache.c (print_entry): Check for FLAG_IA64_LIB64. > > Index: elf/cache.c > =================================================================== > RCS file: /cvs/glibc/libc/elf/cache.c,v > retrieving revision 1.5 > diff -u -a -u -r1.5 elf/cache.c > --- elf/cache.c 2000/05/17 11:04:02 1.5 > +++ elf/cache.c 2000/08/18 09:45:45 > @@ -72,6 +72,10 @@ > case FLAG_SPARC_LIB64: > fputs (",64bit", stdout); > #endif > +#if defined __ia64__ || defined __i386__ > + case FLAG_IA64_LIB64: > + fputs (",64bit", stdout); > +#endif > case 0: > break; > default: > Index: sysdeps/unix/sysv/linux/ia64/readelflib.c > =================================================================== > RCS file: readelflib.c > diff -N sysdeps/unix/sysv/linux/ia64/readelflib.c > --- /dev/null Tue May 5 13:32:27 1998 > +++ sysdeps/unix/sysv/linux/ia64/readelflib.c Fri Aug 18 02:45:49 2000 > @@ -0,0 +1,57 @@ > +/* Copyright (C) 2000 Free Software Foundation, Inc. > + This file is part of the GNU C Library. > + > + The GNU C Library is free software; you can redistribute it and/or > + modify it under the terms of the GNU Library General Public License as > + published by the Free Software Foundation; either version 2 of the > + License, or (at your option) any later version. > + > + The GNU C Library is distributed in the hope that it will be useful, > + but WITHOUT ANY WARRANTY; without even the implied warranty of > + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + Library General Public License for more details. > + > + You should have received a copy of the GNU Library General Public > + License along with the GNU C Library; see the file COPYING.LIB. If not, > + write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, > + Boston, MA 02111-1307, USA. */ > + > + > +int process_elf32_file (const char *file_name, const char *lib, int *flag, > + char **soname, void *file_contents, size_t file_length); > +int process_elf64_file (const char *file_name, const char *lib, int *flag, > + char **soname, void *file_contents, size_t file_length); > + > +/* Returns 0 if everything is ok, != 0 in case of error. */ > +int > +process_elf_file (const char *file_name, const char *lib, int *flag, > + char **soname, void *file_contents, size_t file_length) > +{ > + ElfW(Ehdr) *elf_header = (ElfW(Ehdr) *) file_contents; > + int ret; > + > + if (elf_header->e_ident [EI_CLASS] == ELFCLASS32) > + return process_elf32_file (file_name, lib, flag, soname, file_contents, > + file_length); > + else > + { > + ret = process_elf64_file (file_name, lib, flag, soname, file_contents, > + file_length); > + /* Intel 64bit libraries are always libc.so.6+. */ > + if (!ret) > + *flag = FLAG_IA64_LIB64|FLAG_ELF_LIBC6; > + return ret; > + } > +} > + > +#undef __ELF_NATIVE_CLASS > +#undef process_elf_file > +#define process_elf_file process_elf32_file > +#define __ELF_NATIVE_CLASS 32 > +#include "sysdeps/generic/readelflib.c" > + > +#undef __ELF_NATIVE_CLASS > +#undef process_elf_file > +#define process_elf_file process_elf64_file > +#define __ELF_NATIVE_CLASS 64 > +#include "sysdeps/generic/readelflib.c" > I don't like fputs (",64bit", stdout); since ia64 may not be the only 64bit library together with ia32 library. Also I am not sure if #if defined __ia64__ || defined __i386__ is really necessary. BTW, I think we need sysdeps/unix/sysv/linux/ia64/dl-cache.h Here is my patch. -- H.J. Lu (hjl@gnu.org) ---- 2000-09-29 H.J. Lu * sysdeps/unix/sysv/linux/ia64/dl-cache.h: New. * sysdeps/unix/sysv/linux/ia64/readelflib.c: Likewise. * elf/cache.c (print_entry): Handle FLAG_IA64_LIB64 for ia64. Index: elf/cache.c =================================================================== RCS file: /work/cvs/gnu/glibc/elf/cache.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 cache.c --- elf/cache.c 2000/05/21 21:10:57 1.1.1.1 +++ elf/cache.c 2000/09/29 17:11:03 @@ -72,6 +72,10 @@ print_entry (const char *lib, int flag, case FLAG_SPARC_LIB64: fputs (",64bit", stdout); #endif +#ifdef __ia64__ + case FLAG_IA64_LIB64: + fputs (",IA-64", stdout); +#endif case 0: break; default: --- /dev/null Thu Aug 24 02:00:32 2000 +++ sysdeps/unix/sysv/linux/ia64/dl-cache.h Fri Sep 29 10:06:21 2000 @@ -0,0 +1,25 @@ +/* Support for reading /etc/ld.so.cache files written by Linux ldconfig. + Copyright (C) 2000 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Library General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Library General Public License for more details. + + You should have received a copy of the GNU Library General Public + License along with the GNU C Library; see the file COPYING.LIB. If not, + write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, + Boston, MA 02111-1307, USA. */ + +#define _DL_CACHE_DEFAULT_ID 0x203 + +#define _dl_cache_check_flags(flags) \ + ((flags) == _DL_CACHE_DEFAULT_ID) + +#include_next --- /dev/null Thu Aug 24 02:00:32 2000 +++ sysdeps/unix/sysv/linux/ia64/readelflib.c Fri Sep 29 10:33:05 2000 @@ -0,0 +1,62 @@ +/* Copyright (C) 2000 Free Software Foundation, Inc. + This file is part of the GNU C Library. + Contributed by Andreas Jaeger , 1999 and + Jakub Jelinek , 1999 and + H.J. Lu , 2000 + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Library General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Library General Public License for more details. + + You should have received a copy of the GNU Library General Public + License along with the GNU C Library; see the file COPYING.LIB. If not, + write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, + Boston, MA 02111-1307, USA. */ + + +int process_elf32_file (const char *file_name, const char *lib, int *flag, + char **soname, void *file_contents, + size_t file_length); +int process_elf64_file (const char *file_name, const char *lib, int *flag, + char **soname, void *file_contents, + size_t file_length); + +/* Returns 0 if everything is ok, != 0 in case of error. */ +int +process_elf_file (const char *file_name, const char *lib, int *flag, + char **soname, void *file_contents, size_t file_length) +{ + ElfW(Ehdr) *elf_header = (ElfW(Ehdr) *) file_contents; + int ret; + + if (elf_header->e_ident [EI_CLASS] == ELFCLASS32) + return process_elf32_file (file_name, lib, flag, soname, file_contents, + file_length); + else + { + ret = process_elf64_file (file_name, lib, flag, soname, file_contents, + file_length); + /* IA64 libraries are always libc.so.6+. */ + if (!ret) + *flag = FLAG_IA64_LIB64|FLAG_ELF_LIBC6; + return ret; + } +} + +#undef __ELF_NATIVE_CLASS +#undef process_elf_file +#define process_elf_file process_elf32_file +#define __ELF_NATIVE_CLASS 32 +#include "sysdeps/generic/readelflib.c" + +#undef __ELF_NATIVE_CLASS +#undef process_elf_file +#define process_elf_file process_elf64_file +#define __ELF_NATIVE_CLASS 64 +#include "sysdeps/generic/readelflib.c" From hjl@lucon.org Fri Sep 29 11:31:00 2000 From: hjl@lucon.org (H . J . Lu) Date: Fri, 29 Sep 2000 11:31:00 -0000 Subject: next test release (5th) References: <20000929093016.A3784@suse.de> <20000929120507.A9588@sunsite.ms.mff.cuni.cz> <20000929170018.A4988@suse.de> <20000929171605.C9588@sunsite.ms.mff.cuni.cz> Message-ID: <20000929113132.A14498@lucon.org> On Fri, Sep 29, 2000 at 05:16:05PM +0200, Jakub Jelinek wrote: > On Fri, Sep 29, 2000 at 05:00:18PM +0200, Thorsten Kukuk wrote: > > > This is perfectly fine. There is no real need for using size_t. I > > > would perhaps just using uint32_t and int32_t instead of introducing > > > another type. I'll probably make this change in your patch. > > > Otherwise people will ask why such a named type is necessry. > > > > It is necessary to be binary compatible on Alpha. Or we need to > > bump the nscd version number. > > Here is an updated patch: > > 2000-09-29 Jakub Jelinek > > * nscd/nscd-client.h (NSCD_VERSION): Bump to 3. > Use int32_t where appropriate. > * nscd/nscd_gethst_r.c (nscd_gethst_r): Use u_int32_t where > appropriate. > * nscd/nscd_getgr_r.c (nscd_getgr_r): Likewise. > * nscd/hstcache.c (cache_addhst): Likewise. > * nscd/grpcache.c (cache_addgr): Likewise. > There is a problem with this patch. When I did # make check on ia64 with the old nscd running, I got socket(PF_UNIX, SOCK_STREAM, 0) = 3 connect(3, {sin_family=AF_UNIX, path=" /var/run/.nscd_socket"}, 110) = 0 write(3, "\3\0\0\0\1\0\0\0\4\0\0\0", 12) = 12 write(3, "561\0", 4) = -1 EPIPE (Broken pipe) --- SIGPIPE (Broken pipe) --- +++ killed by SIGPIPE +++ I think the client should check the version before sending request. H.J. From hjl@lucon.org Fri Sep 29 11:35:00 2000 From: hjl@lucon.org (H . J . Lu) Date: Fri, 29 Sep 2000 11:35:00 -0000 Subject: next test release (5th) References: <20000929093016.A3784@suse.de> <20000929120507.A9588@sunsite.ms.mff.cuni.cz> <20000929170018.A4988@suse.de> <20000929171605.C9588@sunsite.ms.mff.cuni.cz> <20000929113132.A14498@lucon.org> Message-ID: <20000929113518.A14568@lucon.org> On Fri, Sep 29, 2000 at 11:31:32AM -0700, H . J . Lu wrote: > > # make check > > on ia64 with the old nscd running, I got > > socket(PF_UNIX, SOCK_STREAM, 0) = 3 > connect(3, {sin_family=AF_UNIX, path=" /var/run/.nscd_socket"}, 110) = 0 > write(3, "\3\0\0\0\1\0\0\0\4\0\0\0", 12) = 12 > write(3, "561\0", 4) = -1 EPIPE (Broken pipe) > --- SIGPIPE (Broken pipe) --- > +++ killed by SIGPIPE +++ > > I think the client should check the version before sending request. Or we can encode the version in the nscd socket patch like /var/run/.nscd_v3_socket H.J. From drepper@redhat.com Fri Sep 29 11:51:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Fri, 29 Sep 2000 11:51:00 -0000 Subject: next test release (5th) References: <20000929093016.A3784@suse.de> <20000929120507.A9588@sunsite.ms.mff.cuni.cz> <20000929170018.A4988@suse.de> <20000929171605.C9588@sunsite.ms.mff.cuni.cz> <20000929113132.A14498@lucon.org> <20000929113518.A14568@lucon.org> Message-ID: "H . J . Lu" writes: > > I think the client should check the version before sending request. > > Or we can encode the version in the nscd socket patch like > > /var/run/.nscd_v3_socket I don't like this. And I don't care about IA-64, there is no user base to worry about. But I care about Alpha. I'll probably just make the new types configurable. so that the protocol does not change for Alpha. For IA-64: kill nscd. For SPARC64 and MIPS64 likewise: there are no users to worry about. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From roland@frob.com Fri Sep 29 11:56:00 2000 From: roland@frob.com (Roland McGrath) Date: Fri, 29 Sep 2000 11:56:00 -0000 Subject: next test release (5th) References: Message-ID: <200009291856.e8TIuJG28904@neuralgia.linnaean.org> > > Or we can encode the version in the nscd socket patch like > > > > /var/run/.nscd_v3_socket > > I don't like this. Why not? This seems like a good enough approach to me. It deals easily with the general issue of version incompatibility for the protocol used on that socket. (BTW, it seems pointless to have a dealing dot on that file name. /var/run is a directory that exists for this kind of thing, there is no reason to hide the file.) From drepper@redhat.com Fri Sep 29 12:08:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Fri, 29 Sep 2000 12:08:00 -0000 Subject: next test release (5th) References: <200009291856.e8TIuJG28904@neuralgia.linnaean.org> Message-ID: Roland McGrath writes: > Why not? Because people then want to run the old and the new version at the same time and complain then about inconsistencies or other problems. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From roland@frob.com Fri Sep 29 12:24:00 2000 From: roland@frob.com (Roland McGrath) Date: Fri, 29 Sep 2000 12:24:00 -0000 Subject: next test release (5th) References: Message-ID: <200009291924.e8TJOBj29400@neuralgia.linnaean.org> > Because people then want to run the old and the new version at the > same time and complain then about inconsistencies or other problems. I would expect more hassles from the current situation. The client code has to be very careful to recognize talking to an old nscd and punt it or whatever. If that code is not quite careful enough, people will have confusing failures. If it is perfectly careful, people will wind up having no nscd caching being used when they think it should be. Anyone with statically linked programs, or a need to keep glibc-2.1 around, will need to find a way to run the old nscd as well unless the new one is backward compatbile for old clients. Noone will want to run two nscd versions unless they want to run two libc versions, and in that case they already have a lot of subtle issues to be aware of and can't expect much help from us. From drepper@redhat.com Fri Sep 29 12:36:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Fri, 29 Sep 2000 12:36:00 -0000 Subject: next test release (5th) References: <200009291924.e8TJOBj29400@neuralgia.linnaean.org> Message-ID: Roland McGrath writes: > I would expect more hassles from the current situation. The client code > has to be very careful to recognize talking to an old nscd and punt it or > whatever. I mentioned that I want to change it. Alpha should go back to the old format and IA-64, SPARC64, and MIPS64 have no users and therefore no troubles. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From jakub@redhat.com Fri Sep 29 12:48:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Fri, 29 Sep 2000 12:48:00 -0000 Subject: Recent fcntl.h changes Message-ID: <20000929215053.F9588@sunsite.ms.mff.cuni.cz> Hi! Don't the new DN_* values pollute namespace? Shouldn't they be at least surrounded by __USE_GNU or prefixed with __? Jakub From aj@suse.de Fri Sep 29 12:53:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Fri, 29 Sep 2000 12:53:00 -0000 Subject: Recent fcntl.h changes References: <20000929215053.F9588@sunsite.ms.mff.cuni.cz> Message-ID: >>>>> Jakub Jelinek writes: > Hi! > Don't the new DN_* values pollute namespace? You're right :-( > Shouldn't they be at least surrounded by __USE_GNU or prefixed with __? __USE_GNU should be ok. Uli, shall I commit the patch? Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From roland@frob.com Fri Sep 29 12:56:00 2000 From: roland@frob.com (Roland McGrath) Date: Fri, 29 Sep 2000 12:56:00 -0000 Subject: next test release (5th) References: Message-ID: <200009291956.e8TJu6U00234@neuralgia.linnaean.org> > Roland McGrath writes: > > > I would expect more hassles from the current situation. The client code > > has to be very careful to recognize talking to an old nscd and punt it or > > whatever. > > I mentioned that I want to change it. But this is categorically less robust than letting the old version talk to the old version and leaving it at that. Even if you could be sure that your compatibility code would be perfect, it doesn't seem worth the effort and complexity to have the client worry about the server's version. From drepper@redhat.com Fri Sep 29 13:01:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Fri, 29 Sep 2000 13:01:00 -0000 Subject: Recent fcntl.h changes References: <20000929215053.F9588@sunsite.ms.mff.cuni.cz> Message-ID: Andreas Jaeger writes: > __USE_GNU should be ok. Uli, shall I commit the patch? Yes. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Fri Sep 29 13:15:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Fri, 29 Sep 2000 13:15:00 -0000 Subject: next test release (5th) References: <200009291956.e8TJu6U00234@neuralgia.linnaean.org> Message-ID: Roland McGrath writes: > But this is categorically less robust than letting the old version talk to > the old version and leaving it at that. Even if you could be sure that > your compatibility code would be perfect, it doesn't seem worth the effort > and complexity to have the client worry about the server's version. No, there is no compatibility code, that's the point. We just use exactly the same types we had before the change. Nothing changes. For Alpha and 32bit platforms. The problem Thorsten and Jakub saw are for SPARC64 when on a machine with SPARC32 binaries and vice versa. This is handled by breaking compatibility with SPARC64 since there are no users. Leave alone MIPS64 which is probably not even building. What HJ saw is the same problem as for SPARC (here compatibility with x86 is wanted). Again, there are no users. HJ is most probably the only one who's building glibc himself. Everybody else is using a glibc 2.1 variant and will soon have to replace it with a completely new installation since there is no compatibility between the old and new installation. If you change the socket name etc you unnecessarily break the use for 32bit platforms and Alpha. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Fri Sep 29 16:04:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Fri, 29 Sep 2000 16:04:00 -0000 Subject: ldconfig patch for ia64 References: <200009281452.KAA01697@plonk.linuxcare.com> <20000928214645.C25671@devserv.devel.redhat.com> <200009291525.IAA20294@napali.hpl.hp.com> <14804.48750.374694.860233@napali.hpl.hp.com> <200009291638.e8TGcHu17510@hawking.suse.de> <20000929103453.A9734@valinux.com> Message-ID: "H . J . Lu" writes: > I don't like > > fputs (",64bit", stdout); I agree, it's misleading. Especially with the AMD thing coming up. > #if defined __ia64__ || defined __i386__ Here I don't agree. Sometimes it might be desirable to configure for x86 and a IA-64 machine. Some day when IA-64 machines are faster than x86. I've checked in a merge between the two patches. Thanks, -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From hjl@valinux.com Fri Sep 29 17:35:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Fri, 29 Sep 2000 17:35:00 -0000 Subject: Patch: huge_val.h for ia64. Message-ID: <20000929173508.A16348@valinux.com> Here is a patch for the missing sysdeps/ia64/bits/huge_val.h. H.J. --- 2000-09-29 H.J. Lu * sysdeps/ia64/bits/huge_val.h: New. --- /dev/null Thu Aug 24 02:00:32 2000 +++ sysdeps/ia64/bits/huge_val.h Fri Sep 29 17:26:35 2000 @@ -0,0 +1,81 @@ +/* `HUGE_VAL' constants for ia64 (where it is infinity). + Used by and functions for overflow. + Copyright (C) 2000 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Library General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Library General Public License for more details. + + You should have received a copy of the GNU Library General Public + License along with the GNU C Library; see the file COPYING.LIB. If not, + write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, + Boston, MA 02111-1307, USA. */ + +#ifndef _MATH_H +# error "Never use directly; include instead." +#endif + +#include + +/* IEEE positive infinity (-HUGE_VAL is negative infinity). */ + +#if __GNUC_PREREQ(2,96) +# define HUGE_VAL (__extension__ 0x1.0p2047) +#else +# define __HUGE_VAL_bytes { 0, 0, 0, 0, 0, 0, 0xf0, 0x7f } + +# define __huge_val_t union { unsigned char __c[8]; double __d; } +# ifdef __GNUC__ +# define HUGE_VAL (__extension__ \ + ((__huge_val_t) { __c: __HUGE_VAL_bytes }).__d) +# else /* Not GCC. */ +static __huge_val_t __huge_val = { __HUGE_VAL_bytes }; +# define HUGE_VAL (__huge_val.__d) +# endif /* GCC. */ +#endif /* GCC 2.95 */ + + +/* ISO C99 extensions: (float) HUGE_VALF and (long double) HUGE_VALL. */ + +#ifdef __USE_ISOC99 + +# if __GNUC_PREREQ(2,96) + +# define HUGE_VALF (__extension__ 0x1.0p255f) +# define HUGE_VALL (__extension__ 0x1.0p32767L) + +# else + +# define __HUGE_VALF_bytes { 0, 0, 0x80, 0x7f } + +# define __huge_valf_t union { unsigned char __c[4]; float __f; } +# ifdef __GNUC__ +# define HUGE_VALF (__extension__ \ + ((__huge_valf_t) { __c: __HUGE_VALF_bytes }).__f) +# else /* Not GCC. */ +static __huge_valf_t __huge_valf = { __HUGE_VALF_bytes }; +# define HUGE_VALF (__huge_valf.__f) +# endif /* GCC. */ + + +# define __HUGE_VALL_bytes { 0, 0, 0, 0, 0, 0, 0, 0x80, 0xff, 0x7f, 0, 0, 0, 0, 0 ,0} + +# define __huge_vall_t union { unsigned char __c[16]; long double __ld; } +# ifdef __GNUC__ +# define HUGE_VALL (__extension__ \ + ((__huge_vall_t) { __c: __HUGE_VALL_bytes }).__ld) +# else /* Not GCC. */ +static __huge_vall_t __huge_vall = { __HUGE_VALL_bytes }; +# define HUGE_VALL (__huge_vall.__ld) +# endif /* GCC. */ + +# endif /* GCC 2.95 */ + +#endif /* __USE_ISOC99. */ From hjl@valinux.com Fri Sep 29 17:47:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Fri, 29 Sep 2000 17:47:00 -0000 Subject: Patch: update sysdeps/ia64/fpu/libm-test-ulps Message-ID: <20000929174653.A16770@valinux.com> Here is an update for sysdeps/ia64/fpu/libm-test-ulps. H.J. --- 2000-09-29 H.J. Lu * sysdeps/ia64/fpu/libm-test-ulps: Updated for long double. Index: sysdeps/ia64/fpu/libm-test-ulps =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/ia64/fpu/libm-test-ulps,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 libm-test-ulps --- sysdeps/ia64/fpu/libm-test-ulps 2000/09/26 20:24:21 1.1.1.1 +++ sysdeps/ia64/fpu/libm-test-ulps 2000/09/29 22:53:03 @@ -216,13 +216,13 @@ ldouble: 447 # cbrt Test "cbrt (-0.001) == -0.1": -ildouble: 716 -ldouble: 716 +ildouble: 717 +ldouble: 717 Test "cbrt (-27.0) == -3.0": double: 1 idouble: 1 -ildouble: 1 -ldouble: 1 +ildouble: 948 +ldouble: 948 Test "cbrt (0.7) == 0.8879040017426007084": double: 1 idouble: 1 @@ -233,6 +233,9 @@ double: 1 idouble: 1 ildouble: 306 ldouble: 306 +Test "cbrt (8) == 2": +ildouble: 191 +ldouble: 191 # ccos Test "Real part of: ccos (-2 - 3 i) == -4.1896256909688072301 - 9.1092278937553365979 i": @@ -1302,8 +1305,8 @@ ldouble: 447 Function: "cbrt": double: 1 idouble: 1 -ildouble: 716 -ldouble: 716 +ildouble: 948 +ldouble: 948 Function: Real part of "ccos": double: 1 From rth@twiddle.net Fri Sep 29 18:12:00 2000 From: rth@twiddle.net (Richard Henderson) Date: Fri, 29 Sep 2000 18:12:00 -0000 Subject: thread-local data access References: Message-ID: <20000929181207.A14387@twiddle.net> On Wed, Sep 27, 2000 at 05:25:21PM +0200, schwidefsky@de.ibm.com wrote: > Access register 0 is unused anywhere so we could just use this one. > We can't address data directly with this register but we can load it to a > normal register in one cycle. I will take a look at the pthread > implementation and give it a try. This is very similar to Alpha's situation (though it takes more like 5-10 cycles to get into PALmode and back out again with the value. Certainly it's faster than playing stack games (which wouldn't even work with the stuff we're now discussing)). To be sure, ideally you'd teach gcc about this register, and how to move data to and from. You'd mark it fixed, since you're reserving it for the thread ABI. Then you can implement pthreads with register struct _pthread_descr_struct *__thread_self __asm__("acc0"); #define THREAD_SELF __thread_self Now gcc can properly schedule the code, which would not be true with inline assembly. r~ From drepper@redhat.com Fri Sep 29 19:53:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Fri, 29 Sep 2000 19:53:00 -0000 Subject: First ldconfig -r without chroot attempt References: <20000929183825.D9588@sunsite.ms.mff.cuni.cz> Message-ID: Jakub Jelinek writes: > Below is my first chroot -r without chroot() attempt. I think it looked good. I checked it in. And then made a few more changes. Seems to work just fine for me. The files are actually a bit different even though ldconfig -p creates the same output. I'll try to look into the differences. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Fri Sep 29 20:07:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Fri, 29 Sep 2000 20:07:00 -0000 Subject: Patch: update sysdeps/ia64/fpu/libm-test-ulps References: <20000929174653.A16770@valinux.com> Message-ID: "H . J . Lu" writes: > Here is an update for sysdeps/ia64/fpu/libm-test-ulps. Thanks, I've applied the two patches. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Fri Sep 29 20:19:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Fri, 29 Sep 2000 20:19:00 -0000 Subject: First ldconfig -r without chroot attempt References: <20000929183825.D9588@sunsite.ms.mff.cuni.cz> Message-ID: I found the reason for the difference in the generated cache files: the __unused field wasn't initialized. I changed this now and the produced cache files are identical. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From hjl@valinux.com Fri Sep 29 21:59:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Fri, 29 Sep 2000 21:59:00 -0000 Subject: [ia64-tools] Re: Patch: update sysdeps/ia64/fpu/libm-test-ulps References: <20000929174653.A16770@valinux.com> Message-ID: <20000929214432.A24252@valinux.com> On Fri, Sep 29, 2000 at 07:57:15PM -0700, Ulrich Drepper wrote: > "H . J . Lu" writes: > > > Here is an update for sysdeps/ia64/fpu/libm-test-ulps. > > Thanks, I've applied the two patches. > Thanks. BTW, I have more patches for math and ia64. I will submit them after some cleanup. It seems that some IEEE 754 long double functions are never tested until ia64 :-). -- H.J. Lu (hjl@gnu.org) From drepper@redhat.com Fri Sep 29 22:18:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Fri, 29 Sep 2000 22:18:00 -0000 Subject: [ia64-tools] Re: Patch: update sysdeps/ia64/fpu/libm-test-ulps References: <20000929174653.A16770@valinux.com> <20000929214432.A24252@valinux.com> Message-ID: "H . J . Lu" writes: > Thanks. BTW, I have more patches for math and ia64. I will submit them > after some cleanup. It seems that some IEEE 754 long double functions > are never tested until ia64 :-). If they are not obvious send them to Jes. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From jakub@redhat.com Fri Sep 29 23:19:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Fri, 29 Sep 2000 23:19:00 -0000 Subject: ldconfig patch for ia64 References: <200009281452.KAA01697@plonk.linuxcare.com> <20000928214645.C25671@devserv.devel.redhat.com> <200009291525.IAA20294@napali.hpl.hp.com> <14804.48750.374694.860233@napali.hpl.hp.com> <200009291638.e8TGcHu17510@hawking.suse.de> <20000929103453.A9734@valinux.com> Message-ID: <20000930082201.G9588@sunsite.ms.mff.cuni.cz> On Fri, Sep 29, 2000 at 03:53:57PM -0700, Ulrich Drepper wrote: > "H . J . Lu" writes: > > > I don't like > > > > fputs (",64bit", stdout); > > I agree, it's misleading. Especially with the AMD thing coming up. > > > #if defined __ia64__ || defined __i386__ > > Here I don't agree. Sometimes it might be desirable to configure for > x86 and a IA-64 machine. Some day when IA-64 machines are faster than > x86. I think ia32 ldconfig should do the same job as its ia64 counterpart, ie. be able to put both 32 and 64bit libraries into the cache (because you should be able to run 32bit ldconfig binary on ia64 (and amd x86-64)). On ia32 it is harder because there can be either ia64 or k8 binaries present, so we have to deal with it. 2000-09-30 Jakub Jelinek * elf/ldconfig.h (FLAG_X8664_LIB64): Define. * sysdeps/unix/sysv/linux/i386/readelflib.c: New file. --- libc/elf/ldconfig.h.jj Sat Sep 30 08:02:59 2000 +++ libc/elf/ldconfig.h Sat Sep 30 08:03:40 2000 @@ -29,6 +29,7 @@ #define FLAG_REQUIRED_MASK 0xff00 #define FLAG_SPARC_LIB64 0x0100 #define FLAG_IA64_LIB64 0x0200 +#define FLAG_X8664_LIB64 0x0300 /* Declared in cache.c. */ extern void print_cache (const char *cache_name); --- libc/sysdeps/unix/sysv/linux/i386/readelflib.c.jj Sat Sep 30 07:54:24 2000 +++ libc/sysdeps/unix/sysv/linux/i386/readelflib.c Sat Sep 30 08:01:15 2000 @@ -0,0 +1,81 @@ +/* Copyright (C) 1999, 2000 Free Software Foundation, Inc. + This file is part of the GNU C Library. + Contributed by Andreas Jaeger , 1999 and + Jakub Jelinek , 2000. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Library General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Library General Public License for more details. + + You should have received a copy of the GNU Library General Public + License along with the GNU C Library; see the file COPYING.LIB. If not, + write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, + Boston, MA 02111-1307, USA. */ + + +int process_elf32_file (const char *file_name, const char *lib, int *flag, + char **soname, void *file_contents, + size_t file_length); +int process_elf64_file (const char *file_name, const char *lib, int *flag, + char **soname, void *file_contents, + size_t file_length); + +/* Returns 0 if everything is ok, != 0 in case of error. */ +int +process_elf_file (const char *file_name, const char *lib, int *flag, + char **soname, void *file_contents, size_t file_length) +{ + ElfW(Ehdr) *elf_header = (ElfW(Ehdr) *) file_contents; + int ret; + + if (elf_header->e_ident [EI_CLASS] == ELFCLASS32) + return process_elf32_file (file_name, lib, flag, soname, file_contents, + file_length); + else + { + switch (elf_header->e_machine) + { + case EM_IA_64: + case EM_X8664: + break; + default: + error (0, 0, _("%s is for unknown machine %d.\n"), + file_name, elf_header->e_machine); + return 1; + } + + ret = process_elf64_file (file_name, lib, flag, soname, file_contents, + file_length); + /* IA64/X86-64 64bit libraries are always libc.so.6+. */ + if (!ret) + switch (elf_header->e_machine) + { + case EM_IA_64: + *flag = FLAG_IA64_LIB64|FLAG_ELF_LIBC6; + break; + case EM_X8664: + *flag = FLAG_X8664_LIB64|FLAG_ELF_LIBC6; + break; + } + + return ret; + } +} + +#undef __ELF_NATIVE_CLASS +#undef process_elf_file +#define process_elf_file process_elf32_file +#define __ELF_NATIVE_CLASS 32 +#include "sysdeps/generic/readelflib.c" + +#undef __ELF_NATIVE_CLASS +#undef process_elf_file +#define process_elf_file process_elf64_file +#define __ELF_NATIVE_CLASS 64 +#include "sysdeps/generic/readelflib.c" Jakub From hjl@valinux.com Sat Sep 30 00:34:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Sat, 30 Sep 2000 00:34:00 -0000 Subject: sysdeps/ia64/ieee754.h and sysdeps/ia64/fpu/math_ldbl.h for ia64 Message-ID: <20000930003406.A29511@valinux.com> On Fri, Sep 29, 2000 at 10:07:56PM -0700, Ulrich Drepper wrote: > "H . J . Lu" writes: > > > Thanks. BTW, I have more patches for math and ia64. I will submit them > > after some cleanup. It seems that some IEEE 754 long double functions > > are never tested until ia64 :-). > > If they are not obvious send them to Jes. > It is to deal with 16byte long double. I am not if the big endia order for long double is correct. H.J. ---- 2000-09-29 H.J. Lu * sysdeps/ia64/ieee754.h: New. * sysdeps/ia64/fpu/math_ldbl.h: New. --- /dev/null Thu Aug 24 02:00:32 2000 +++ sysdeps/ia64/ieee754.h Fri Sep 29 19:13:02 2000 @@ -0,0 +1,205 @@ +/* Copyright (C) 2000 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Library General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Library General Public License for more details. + + You should have received a copy of the GNU Library General Public + License along with the GNU C Library; see the file COPYING.LIB. If not, + write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, + Boston, MA 02111-1307, USA. */ + +#ifndef _IEEE754_H + +#define _IEEE754_H 1 +#include + +#include + +__BEGIN_DECLS + +union ieee754_float + { + float f; + + /* This is the IEEE 754 single-precision format. */ + struct + { +#if __BYTE_ORDER == __BIG_ENDIAN + unsigned int negative:1; + unsigned int exponent:8; + unsigned int mantissa:23; +#endif /* Big endian. */ +#if __BYTE_ORDER == __LITTLE_ENDIAN + unsigned int mantissa:23; + unsigned int exponent:8; + unsigned int negative:1; +#endif /* Little endian. */ + } ieee; + + /* This format makes it easier to see if a NaN is a signalling NaN. */ + struct + { +#if __BYTE_ORDER == __BIG_ENDIAN + unsigned int negative:1; + unsigned int exponent:8; + unsigned int quiet_nan:1; + unsigned int mantissa:22; +#endif /* Big endian. */ +#if __BYTE_ORDER == __LITTLE_ENDIAN + unsigned int mantissa:22; + unsigned int quiet_nan:1; + unsigned int exponent:8; + unsigned int negative:1; +#endif /* Little endian. */ + } ieee_nan; + }; + +#define IEEE754_FLOAT_BIAS 0x7f /* Added to exponent. */ + + +union ieee754_double + { + double d; + + /* This is the IEEE 754 double-precision format. */ + struct + { +#if __BYTE_ORDER == __BIG_ENDIAN + unsigned int negative:1; + unsigned int exponent:11; + /* Together these comprise the mantissa. */ + unsigned int mantissa0:20; + unsigned int mantissa1:32; +#endif /* Big endian. */ +#if __BYTE_ORDER == __LITTLE_ENDIAN +# if __FLOAT_WORD_ORDER == BIG_ENDIAN + unsigned int mantissa0:20; + unsigned int exponent:11; + unsigned int negative:1; + unsigned int mantissa1:32; +# else + /* Together these comprise the mantissa. */ + unsigned int mantissa1:32; + unsigned int mantissa0:20; + unsigned int exponent:11; + unsigned int negative:1; +# endif +#endif /* Little endian. */ + } ieee; + + /* This format makes it easier to see if a NaN is a signalling NaN. */ + struct + { +#if __BYTE_ORDER == __BIG_ENDIAN + unsigned int negative:1; + unsigned int exponent:11; + unsigned int quiet_nan:1; + /* Together these comprise the mantissa. */ + unsigned int mantissa0:19; + unsigned int mantissa1:32; +#else +# if __FLOAT_WORD_ORDER == BIG_ENDIAN + unsigned int mantissa0:19; + unsigned int quiet_nan:1; + unsigned int exponent:11; + unsigned int negative:1; + unsigned int mantissa1:32; +# else + /* Together these comprise the mantissa. */ + unsigned int mantissa1:32; + unsigned int mantissa0:19; + unsigned int quiet_nan:1; + unsigned int exponent:11; + unsigned int negative:1; +# endif +#endif + } ieee_nan; + }; + +#define IEEE754_DOUBLE_BIAS 0x3ff /* Added to exponent. */ + + +union ieee854_long_double + { + long double d; + + /* This is the IEEE 854 double-extended-precision format. */ + struct + { +#if __BYTE_ORDER == __BIG_ENDIAN + unsigned int empty0:32; + unsigned int negative:1; + unsigned int exponent:15; + unsigned int empty1:16; + unsigned int mantissa0:32; + unsigned int mantissa1:32; +#endif +#if __BYTE_ORDER == __LITTLE_ENDIAN +# if __FLOAT_WORD_ORDER == BIG_ENDIAN + unsigned int empty0:32; + unsigned int exponent:15; + unsigned int negative:1; + unsigned int empty1:16; + unsigned int mantissa0:32; + unsigned int mantissa1:32; +# else + unsigned int mantissa1:32; + unsigned int mantissa0:32; + unsigned int exponent:15; + unsigned int negative:1; + unsigned int empty1:16; + unsigned int empty0:32; +# endif +#endif + } ieee; + + /* This is for NaNs in the IEEE 854 double-extended-precision format. */ + struct + { +#if __BYTE_ORDER == __BIG_ENDIAN + unsigned int empty0:32; + unsigned int negative:1; + unsigned int exponent:15; + unsigned int empty1:16; + unsigned int one:1; + unsigned int quiet_nan:1; + unsigned int mantissa0:30; + unsigned int mantissa1:32; +#endif +#if __BYTE_ORDER == __LITTLE_ENDIAN +# if __FLOAT_WORD_ORDER == BIG_ENDIAN + unsigned int empty0:32; + unsigned int exponent:15; + unsigned int negative:1; + unsigned int empty1:16; + unsigned int mantissa0:30; + unsigned int quiet_nan:1; + unsigned int one:1; + unsigned int mantissa1:32; +# else + unsigned int mantissa1:32; + unsigned int mantissa0:30; + unsigned int quiet_nan:1; + unsigned int one:1; + unsigned int exponent:15; + unsigned int negative:1; + unsigned int empty1:16; + unsigned int empty0:32; +# endif +#endif + } ieee_nan; + }; + +#define IEEE854_LONG_DOUBLE_BIAS 0x3fff + +__END_DECLS + +#endif /* ieee754.h */ --- /dev/null Thu Aug 24 02:00:32 2000 +++ sysdeps/ia64/fpu/math_ldbl.h Fri Sep 29 19:16:12 2000 @@ -0,0 +1,100 @@ +#ifndef _MATH_PRIVATE_H_ +#error "Never use directly; include instead." +#endif + +/* A union which permits us to convert between a long double and + three 32 bit ints. */ + +#if __FLOAT_WORD_ORDER == BIG_ENDIAN + +typedef union +{ + long double value; + struct + { + unsigned int empty0:32; + unsigned int sign_exponent:16; + unsigned int empty1:16; + u_int32_t msw; + u_int32_t lsw; + } parts; +} ieee_long_double_shape_type; + +#endif + +#if __FLOAT_WORD_ORDER == LITTLE_ENDIAN + +typedef union +{ + long double value; + struct + { + u_int32_t lsw; + u_int32_t msw; + unsigned int sign_exponent:16; + unsigned int empty1:16; + unsigned int empty0:32; + } parts; +} ieee_long_double_shape_type; + +#endif + +/* Get three 32 bit ints from a double. */ + +#define GET_LDOUBLE_WORDS(exp,ix0,ix1,d) \ +do { \ + ieee_long_double_shape_type ew_u; \ + ew_u.value = (d); \ + (exp) = ew_u.parts.sign_exponent; \ + (ix0) = ew_u.parts.msw; \ + (ix1) = ew_u.parts.lsw; \ +} while (0) + +/* Set a double from two 32 bit ints. */ + +#define SET_LDOUBLE_WORDS(d,exp,ix0,ix1) \ +do { \ + ieee_long_double_shape_type iw_u; \ + iw_u.parts.sign_exponent = (exp); \ + iw_u.parts.msw = (ix0); \ + iw_u.parts.lsw = (ix1); \ + (d) = iw_u.value; \ +} while (0) + +/* Get the more significant 32 bits of a long double mantissa. */ + +#define GET_LDOUBLE_MSW(v,d) \ +do { \ + ieee_long_double_shape_type sh_u; \ + sh_u.value = (d); \ + (v) = sh_u.parts.msw; \ +} while (0) + +/* Set the more significant 32 bits of a long double mantissa from an int. */ + +#define SET_LDOUBLE_MSW(d,v) \ +do { \ + ieee_long_double_shape_type sh_u; \ + sh_u.value = (d); \ + sh_u.parts.msw = (v); \ + (d) = sh_u.value; \ +} while (0) + +/* Get int from the exponent of a long double. */ + +#define GET_LDOUBLE_EXP(exp,d) \ +do { \ + ieee_long_double_shape_type ge_u; \ + ge_u.value = (d); \ + (exp) = ge_u.parts.sign_exponent; \ +} while (0) + +/* Set exponent of a long double from an int. */ + +#define SET_LDOUBLE_EXP(d,exp) \ +do { \ + ieee_long_double_shape_type se_u; \ + se_u.value = (d); \ + se_u.parts.sign_exponent = (exp); \ + (d) = se_u.value; \ +} while (0) From hjl@valinux.com Sat Sep 30 00:50:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Sat, 30 Sep 2000 00:50:00 -0000 Subject: Patch for math/libm-test.inc and sysdeps/ieee754/ldbl-96 Message-ID: <20000930005031.B29511@valinux.com> Since testing for existence of function may cause exceptions, I clear all exceptions in init_max_error. Or we can modify all those functions to set and check errno for ENOSYS before continue. Together with my previous ia64 patch for long double header files, "make check" passes on ia64 now. H.J. ---- 2000-09-30 H.J. Lu * sysdeps/ieee754/ldbl-96/s_ceill.c (__ceill): Handle overflow. * sysdeps/ieee754/ldbl-96/s_floorl.c (__floorl): Likewise. 2000-09-29 H.J. Lu * math/libm-test.inc (init_max_error): Clear all exceptions before starting test. (acosh_test): Test for existence of function. (asinh_test): Likewise. (atan2_test): Likewise. (cabs_test): Likewise. (cacos_test): Likewise. (cacosh_test): Likewise. (casin_test): Likewise. (casinh_test): Likewise. (catan_test): Likewise. (catanh_test): Likewise. (ccos_test): Likewise. (ccosh_test): Likewise. (cexp_test): Likewise. (clog_test): Likewise. (clog10_test): Likewise. (cosh_test): Likewise. (cpow_test): Likewise. (csin_test): Likewise. (csinh_test): Likewise. (csqrt_test): Likewise. (ctan_test): Likewise. (ctanh_test): Likewise. (fmod_test): Likewise. (hypot_test): Likewise. (remainder_test): Likewise. (remquo_test): Likewise. (sincos_test): Likewise. (sinh_test): Likewise. (tanh_test): Likewise. Index: sysdeps/ieee754/ldbl-96/s_ceill.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/ieee754/ldbl-96/s_ceill.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 s_ceill.c --- sysdeps/ieee754/ldbl-96/s_ceill.c 2000/05/21 21:11:36 1.1.1.1 +++ sysdeps/ieee754/ldbl-96/s_ceill.c 2000/09/30 07:11:14 @@ -59,8 +59,13 @@ static long double huge = 1.0e4930; if(((i0&i)|i1)==0) return x; /* x is integral */ if(huge+x>0.0) { /* raise inexact flag */ if(sx==0) { - if (j0>0) i0 += (0x80000000)>>j0; - else ++se; + if (j0>0 && (i0+(0x80000000>>j0))>i0) + i0+=0x80000000>>j0; + else + { + i = 0x7fffffff; + ++se; + } } i0 &= (~i); i1=0; } Index: sysdeps/ieee754/ldbl-96/s_floorl.c =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/ieee754/ldbl-96/s_floorl.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 s_floorl.c --- sysdeps/ieee754/ldbl-96/s_floorl.c 2000/05/21 21:11:36 1.1.1.1 +++ sysdeps/ieee754/ldbl-96/s_floorl.c 2000/09/30 07:11:59 @@ -60,8 +60,13 @@ static long double huge = 1.0e4930; if(((i0&i)|i1)==0) return x; /* x is integral */ if(huge+x>0.0) { /* raise inexact flag */ if(sx) { - if (j0>0) i0 += (0x80000000)>>j0; - else ++se; + if (j0>0 && (i0+(0x80000000>>j0))>i0) + i0 += (0x80000000)>>j0; + else + { + i = 0x7fffffff; + ++se; + } } i0 &= (~i); i1=0; } Index: math/libm-test.inc =================================================================== RCS file: /work/cvs/gnu/glibc/math/libm-test.inc,v retrieving revision 1.1.1.3 diff -u -p -r1.1.1.3 libm-test.inc --- math/libm-test.inc 2000/09/26 00:29:07 1.1.1.3 +++ math/libm-test.inc 2000/09/30 01:18:21 @@ -189,6 +189,7 @@ init_max_error (void) max_error = 0; real_max_error = 0; imag_max_error = 0; + feclearexcept (FE_ALL_EXCEPT); } static void @@ -723,6 +724,12 @@ acos_test (void) static void acosh_test (void) { + errno = 0; + FUNC(acosh) (7); + if (errno == ENOSYS) + /* Function not implemented. */ + return; + START (acosh); TEST_f_f (acosh, plus_infty, plus_infty); @@ -770,6 +777,12 @@ asin_test (void) static void asinh_test (void) { + errno = 0; + FUNC(asinh) (0.7); + if (errno == ENOSYS) + /* Function not implemented. */ + return; + START (asinh); TEST_f_f (asinh, 0, 0); @@ -815,6 +828,11 @@ atan_test (void) static void atanh_test (void) { + errno = 0; + FUNC(atanh) (0.7); + if (errno == ENOSYS) + /* Function not implemented. */ + return; START (atanh); @@ -838,6 +856,12 @@ atanh_test (void) static void atan2_test (void) { + errno = 0; + FUNC(atan2) (-0, 1); + if (errno == ENOSYS) + /* Function not implemented. */ + return; + START (atan2); /* atan2 (0,x) == 0 for x > 0. */ @@ -904,6 +928,12 @@ atan2_test (void) static void cabs_test (void) { + errno = 0; + FUNC(cabs) (BUILD_COMPLEX (0.7, 12.4)); + if (errno == ENOSYS) + /* Function not implemented. */ + return; + START (cabs); /* cabs (x + iy) is specified as hypot (x,y) */ @@ -944,6 +974,12 @@ cabs_test (void) static void cacos_test (void) { + errno = 0; + FUNC(cacos) (BUILD_COMPLEX (0.7, 1.2)); + if (errno == ENOSYS) + /* Function not implemented. */ + return; + START (cacos); @@ -1002,6 +1038,12 @@ cacos_test (void) static void cacosh_test (void) { + errno = 0; + FUNC(cacosh) (BUILD_COMPLEX (0.7, 1.2)); + if (errno == ENOSYS) + /* Function not implemented. */ + return; + START (cacosh); @@ -1125,6 +1167,12 @@ carg_test (void) static void casin_test (void) { + errno = 0; + FUNC(casin) (BUILD_COMPLEX (0.7, 1.2)); + if (errno == ENOSYS) + /* Function not implemented. */ + return; + START (casin); TEST_c_c (casin, 0, 0, 0.0, 0.0); @@ -1183,6 +1231,12 @@ casin_test (void) static void casinh_test (void) { + errno = 0; + FUNC(casinh) (BUILD_COMPLEX (0.7, 1.2)); + if (errno == ENOSYS) + /* Function not implemented. */ + return; + START (casinh); TEST_c_c (casinh, 0, 0, 0.0, 0.0); @@ -1241,6 +1295,12 @@ casinh_test (void) static void catan_test (void) { + errno = 0; + FUNC(catan) (BUILD_COMPLEX (0.7, 1.2)); + if (errno == ENOSYS) + /* Function not implemented. */ + return; + START (catan); TEST_c_c (catan, 0, 0, 0, 0); @@ -1303,6 +1363,12 @@ catan_test (void) static void catanh_test (void) { + errno = 0; + FUNC(catanh) (BUILD_COMPLEX (0.7, 1.2)); + if (errno == ENOSYS) + /* Function not implemented. */ + return; + START (catanh); TEST_c_c (catanh, 0, 0, 0.0, 0.0); @@ -1384,6 +1450,11 @@ cbrt_test (void) static void ccos_test (void) { + errno = 0; + FUNC(ccos) (BUILD_COMPLEX (0, 0)); + if (errno == ENOSYS) + /* Function not implemented. */ + return; START (ccos); @@ -1448,6 +1519,11 @@ ccos_test (void) static void ccosh_test (void) { + errno = 0; + FUNC(ccosh) (BUILD_COMPLEX (0.7, 1.2)); + if (errno == ENOSYS) + /* Function not implemented. */ + return; START (ccosh); @@ -1530,6 +1606,12 @@ ceil_test (void) static void cexp_test (void) { + errno = 0; + FUNC(cexp) (BUILD_COMPLEX (0, 0)); + if (errno == ENOSYS) + /* Function not implemented. */ + return; + START (cexp); TEST_c_c (cexp, plus_zero, plus_zero, 1, 0.0); @@ -1602,6 +1684,12 @@ cimag_test (void) static void clog_test (void) { + errno = 0; + FUNC(clog) (BUILD_COMPLEX (-2, -3)); + if (errno == ENOSYS) + /* Function not implemented. */ + return; + START (clog); TEST_c_c (clog, minus_zero, 0, minus_infty, M_PIl, DIVIDE_BY_ZERO_EXCEPTION); @@ -1661,6 +1749,12 @@ clog_test (void) static void clog10_test (void) { + errno = 0; + FUNC(clog10) (BUILD_COMPLEX (0.7, 1.2)); + if (errno == ENOSYS) + /* Function not implemented. */ + return; + START (clog10); TEST_c_c (clog10, minus_zero, 0, minus_infty, M_PIl, DIVIDE_BY_ZERO_EXCEPTION); @@ -1791,6 +1885,12 @@ cos_test (void) static void cosh_test (void) { + errno = 0; + FUNC(cosh) (0.7); + if (errno == ENOSYS) + /* Function not implemented. */ + return; + START (cosh); TEST_f_f (cosh, 0, 1); TEST_f_f (cosh, minus_zero, 1); @@ -1809,6 +1909,12 @@ cosh_test (void) static void cpow_test (void) { + errno = 0; + FUNC(cpow) (BUILD_COMPLEX (1, 0), BUILD_COMPLEX (0, 0)); + if (errno == ENOSYS) + /* Function not implemented. */ + return; + START (cpow); TEST_cc_c (cpow, 1, 0, 0, 0, 1.0, 0.0); @@ -1862,6 +1968,11 @@ creal_test (void) static void csin_test (void) { + errno = 0; + FUNC(csin) (BUILD_COMPLEX (0.7, 1.2)); + if (errno == ENOSYS) + /* Function not implemented. */ + return; START (csin); @@ -1926,6 +2037,11 @@ csin_test (void) static void csinh_test (void) { + errno = 0; + FUNC(csinh) (BUILD_COMPLEX (0.7, 1.2)); + if (errno == ENOSYS) + /* Function not implemented. */ + return; START (csinh); @@ -1988,6 +2104,12 @@ csinh_test (void) static void csqrt_test (void) { + errno = 0; + FUNC(csqrt) (BUILD_COMPLEX (-1, 0)); + if (errno == ENOSYS) + /* Function not implemented. */ + return; + START (csqrt); TEST_c_c (csqrt, 0, 0, 0.0, 0.0); @@ -2048,6 +2170,12 @@ csqrt_test (void) static void ctan_test (void) { + errno = 0; + FUNC(ctan) (BUILD_COMPLEX (0.7, 1.2)); + if (errno == ENOSYS) + /* Function not implemented. */ + return; + START (ctan); TEST_c_c (ctan, 0, 0, 0.0, 0.0); @@ -2100,6 +2228,12 @@ ctan_test (void) static void ctanh_test (void) { + errno = 0; + FUNC(ctanh) (BUILD_COMPLEX (0, 0)); + if (errno == ENOSYS) + /* Function not implemented. */ + return; + START (ctanh); TEST_c_c (ctanh, 0, 0, 0.0, 0.0); @@ -2485,6 +2619,12 @@ fmin_test (void) static void fmod_test (void) { + errno = 0; + FUNC(fmod) (6.5, 2.3); + if (errno == ENOSYS) + /* Function not implemented. */ + return; + START (fmod); /* fmod (+0, y) == +0 for y != 0. */ @@ -2585,6 +2725,12 @@ gamma_test (void) static void hypot_test (void) { + errno = 0; + FUNC(hypot) (0.7, 12.4); + if (errno == ENOSYS) + /* Function not implemented. */ + return; + START (hypot); TEST_ff_f (hypot, plus_infty, 1, plus_infty, IGNORE_ZERO_INF_SIGN); @@ -3399,6 +3545,11 @@ pow_test (void) static void remainder_test (void) { + errno = 0; + FUNC(remainder) (1.625, 1.0); + if (errno == ENOSYS) + /* Function not implemented. */ + return; START (remainder); @@ -3424,6 +3575,12 @@ remquo_test (void) /* x is needed. */ int x; + errno = 0; + FUNC(remquo) (1.625, 1.0, &x); + if (errno == ENOSYS) + /* Function not implemented. */ + return; + START (remquo); TEST_ffI_f1 (remquo, 1, 0, nan_value, IGNORE, INVALID_EXCEPTION); @@ -3637,6 +3794,12 @@ sincos_test (void) { FLOAT sin_res, cos_res; + errno = 0; + FUNC(sincos) (0, &sin_res, &cos_res); + if (errno == ENOSYS) + /* Function not implemented. */ + return; + START (sincos); /* sincos is treated differently because it returns void. */ @@ -3658,6 +3821,12 @@ sincos_test (void) static void sinh_test (void) { + errno = 0; + FUNC(sinh) (0.7); + if (errno == ENOSYS) + /* Function not implemented. */ + return; + START (sinh); TEST_f_f (sinh, 0, 0); TEST_f_f (sinh, minus_zero, minus_zero); @@ -3732,6 +3901,12 @@ tan_test (void) static void tanh_test (void) { + errno = 0; + FUNC(tanh) (0.7); + if (errno == ENOSYS) + /* Function not implemented. */ + return; + START (tanh); TEST_f_f (tanh, 0, 0); From kettenis@wins.uva.nl Sat Sep 30 02:59:00 2000 From: kettenis@wins.uva.nl (Mark Kettenis) Date: Sat, 30 Sep 2000 02:59:00 -0000 Subject: next test release (5th) References: Message-ID: <200009300959.e8U9xdT00593@delius.kettenis.local> From: Ulrich Drepper Date: 29 Sep 2000 00:01:31 -0700 I hope to find the time to make the .95 test release over the weekend. Depending on how many reports we get this could very well be a release candidate and the following release could be final. The Hurd seems to be OK right now. Configuring with --enable-libio is probably broken (I didn't test it for a while), but that's experimental anyway. I'd appreciate it if before the final release you could give me a few days to check whether things still work though. Mark From jakub@redhat.com Sat Sep 30 10:43:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Sat, 30 Sep 2000 10:43:00 -0000 Subject: next test release (5th) References: <20000929093016.A3784@suse.de> Message-ID: <20000930194652.I9588@sunsite.ms.mff.cuni.cz> On Fri, Sep 29, 2000 at 09:30:16AM +0200, Thorsten Kukuk wrote: > > Hi, > > I have only one bigger problem: H.J. Lu's patch for sunrpc/udp > (IP_PKTINFO) patch does not seem to work on big endian platforms. > > The server sends the data to the network, but the client never > becomes the answer. I will try to look at it, but I don't know > anything about IP_PKTINFO. I think this is related to the portmap hang on boot. Older kernels used to even crash when glibc 2.1.9x portmap was started, then DaveM fixed a bug in the kernel and said something needs to be fixed in userland as well, but I did not get to it yet and cannot find the mail right now (vger is not accessible now and DaveM is until monday? on holidays). So I guess 2.1.95 can be released with this known issue and I'll work with DaveM on fixing sunrpc/udp on SPARC soon afterwards. Jakub From drepper@redhat.com Sat Sep 30 14:47:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Sat, 30 Sep 2000 14:47:00 -0000 Subject: ldconfig patch for ia64 References: <200009281452.KAA01697@plonk.linuxcare.com> <20000928214645.C25671@devserv.devel.redhat.com> <200009291525.IAA20294@napali.hpl.hp.com> <14804.48750.374694.860233@napali.hpl.hp.com> <200009291638.e8TGcHu17510@hawking.suse.de> <20000929103453.A9734@valinux.com> <20000930082201.G9588@sunsite.ms.mff.cuni.cz> Message-ID: Jakub Jelinek writes: > I think ia32 ldconfig should do the same job as its ia64 counterpart, ie. be > able to put both 32 and 64bit libraries into the cache (because you should > be able to run 32bit ldconfig binary on ia64 (and amd x86-64)). The patch looked OK, I've applied it. Thanks, -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Sat Sep 30 15:04:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Sat, 30 Sep 2000 15:04:00 -0000 Subject: sysdeps/ia64/ieee754.h and sysdeps/ia64/fpu/math_ldbl.h for ia64 References: <20000930003406.A29511@valinux.com> Message-ID: "H . J . Lu" writes: > It is to deal with 16byte long double. I am not if the big endia order > for long double is correct. This patch is OK, I've applied it. Thanks, -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Sat Sep 30 15:06:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Sat, 30 Sep 2000 15:06:00 -0000 Subject: Patch for math/libm-test.inc and sysdeps/ieee754/ldbl-96 References: <20000930005031.B29511@valinux.com> Message-ID: "H . J . Lu" writes: > Since testing for existence of function may cause exceptions, I clear > all exceptions in init_max_error. Or we can modify all those functions > to set and check errno for ENOSYS before continue. I've added this patch as well. Thanks, -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From hjl@valinux.com Sat Sep 30 17:33:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Sat, 30 Sep 2000 17:33:00 -0000 Subject: [ia64-tools] Re: Patch for math/libm-test.inc and sysdeps/ieee754/ldbl-96 References: <20000930005031.B29511@valinux.com> Message-ID: <20000930172259.A6125@valinux.com> On Sat, Sep 30, 2000 at 03:02:16PM -0700, Ulrich Drepper wrote: > "H . J . Lu" writes: > > > Since testing for existence of function may cause exceptions, I clear > > all exceptions in init_max_error. Or we can modify all those functions > > to set and check errno for ENOSYS before continue. > > I've added this patch as well. Thanks, > Thanks. Now "make check" passes on ia64. The only remaining issuses are 2000-09-29 H.J. Lu * sysdeps/unix/sysv/linux/ia64/sysdep.S (__ia64_syscall): Removed. I believe the kernel should only export the system call numbers to the user space and the user programs should use syscall (__NR_xxx, .....) In anycase, glibc 2.2 doesn't export __ia64_syscall. We should fix it one way or the other. I prefer to fix the user programs. 2000-08-27 H.J. Lu * sysdeps/unix/sysv/linux/ia64/clone.S: Make it dummy. No need for it. Ulrich, I believe the consensus is to remove clone for ia64. Thanks. H.J.