From drepper@cygnus.com Fri Oct 1 08:31:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Fri, 01 Oct 1999 08:31:00 -0000 Subject: Patch missing from source, yet included in ChangeLog References: Message-ID: The patch is now on 2.1. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From hjl@valinux.com Sat Oct 2 16:53:00 1999 From: hjl@valinux.com (H.J. Lu) Date: Sat, 02 Oct 1999 16:53:00 -0000 Subject: Strange rt_sigsuspend problem with pthreads Message-ID: <19991002235256.2C99E3FC1@valinux.com> Hi, Here is the patch for the glibc bug, libc/1305. It is for glibc 2.1. I am not sure how to fix glibc 2.2. Maybe we should use DT_PREINIT. -- H.J. Lu (hjl@gnu.org) --- Sat Oct 2 16:38:20 1999 H.J. Lu * sysdeps/generic/libc-start.c (__libc_start_main): Call __libc_preinit (). * csu/set-init.c (__libc_preinit): New. * csu/munch-tmpl.c (__libc_preinit): New, a dummy. * malloc/malloc.c (ptmalloc_init): New, set to __libc_subpreinit. Index: sysdeps/generic/libc-start.c =================================================================== RCS file: /work/cvs/gnu/glibc-2.1/sysdeps/generic/libc-start.c,v retrieving revision 1.2 diff -u -p -r1.2 libc-start.c --- sysdeps/generic/libc-start.c 1999/08/08 17:03:51 1.2 +++ sysdeps/generic/libc-start.c 1999/10/02 23:38:18 @@ -24,6 +24,7 @@ #include #include +extern void __libc_preinit (int argc, char **argv, char **envp); extern void __libc_init_first (int argc, char **argv, char **envp); extern int _dl_starting_up; @@ -59,6 +60,14 @@ __libc_start_main (int (*main) (int, cha if (__libc_enable_secure) check_standard_fds (); + /* Call the preinitializer of the libc. */ +#ifdef SHARED + if (_dl_debug_impcalls) + _dl_debug_message (1, "\npreinitialize libc\n\n", NULL); +#endif + __libc_preinit (argc, argv, __environ); + + /* Register the destructor of the program, if any. */ /* Register the destructor of the dynamic linker if there is any. */ if (rtld_fini != NULL) atexit (rtld_fini); Index: csu/set-init.c =================================================================== RCS file: /work/cvs/gnu/glibc-2.1/csu/set-init.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 set-init.c --- csu/set-init.c 1998/05/09 20:38:38 1.1.1.1 +++ csu/set-init.c 1999/10/02 23:11:51 @@ -21,3 +21,6 @@ DEFINE_HOOK_RUNNER (__libc_subinit, __libc_init, (int argc, char **argv, char **envp), (argc, argv, envp)) + +DEFINE_HOOK_RUNNER (__libc_subpreinit, __libc_preinit, + (int argc, char **argv, char **envp), (argc, argv, envp)) Index: csu/munch-tmpl.c =================================================================== RCS file: /work/cvs/gnu/glibc-2.1/csu/munch-tmpl.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 munch-tmpl.c --- csu/munch-tmpl.c 1998/05/09 20:38:38 1.1.1.1 +++ csu/munch-tmpl.c 1999/10/02 23:30:50 @@ -36,3 +36,8 @@ __libc_init (int argc, char **argv, char } #endif } + +void +__libc_preinit (int argc, char **argv, char **envp) +{ +} Index: malloc/malloc.c =================================================================== RCS file: /work/cvs/gnu/glibc-2.1/malloc/malloc.c,v retrieving revision 1.1.1.27 diff -u -p -r1.1.1.27 malloc.c --- malloc/malloc.c 1999/10/02 16:56:31 1.1.1.27 +++ malloc/malloc.c 1999/10/02 23:17:48 @@ -4670,6 +4670,10 @@ weak_alias (__malloc_get_state, malloc_g weak_alias (__malloc_set_state, malloc_set_state) #endif +#ifdef HAVE_GNU_LD +text_set_element (__libc_subpreinit, ptmalloc_init); +#endif + /* History: From hjl@valinux.com Sun Oct 3 12:30:00 1999 From: hjl@valinux.com (H.J. Lu) Date: Sun, 03 Oct 1999 12:30:00 -0000 Subject: gdb 4.17.0.14 is released. Message-ID: <19991003192818.B5B7A3FC1@valinux.com> Hi, Folks, This is the beta release of gdb 4.17.0.14, which is based on gdb 4.17 plus Linux/x86 hardware watchpoint/FPU, glibc 2 pthread and Linux/PPC support. You need linux 2.0.35 or above, or 2.1.xx to get the x86 FPU to work correctly. The Linux/x86 binary works with all recent kernels and C libraries, and the x86 FPU support is enabled at the run-time, depending on the kernel version. You need the latest glibc 2.1.1 to debug LinuxThreads. Special thanks to Dan Bethe who provided the PowePC notebook which makes the LinuxPPC support in gdb possible. Please report any bugs related to gdb 4.17.0.14 to hjl@lucon.org. Problems: Because most of system calls in glibc 2 are written in assembly without frame pointer, gdb may not be able to debug nor get stack trace system calls on glibc-based 2 systems. Due to this, "make check" may fail in FAIL: gdb.base/a1-selftest.exp: backtrace through signal handler FAIL: gdb.base/signals.exp: bt in signals.exp with glibc 2. Also, it is normal to see FAIL: gdb.base/interrupt.exp: continue (timeout) FAIL: gdb.base/interrupt.exp: echo data (timeout) if there is XPASS: gdb.base/interrupt.exp: send_gdb end of file Due to the new cplus-dem.c from gcc 2.95.1, you will get a few FAIL: gdb.c++/demangle.exp: maint demangle __xxxxxxxxxx Changes from gdb 4.17.0.13: 1. Fixed a thread/signal race condition. 2. Fixed a dead thread bug. 3. Added AMD Athlon support in disassembler. Changes from gdb 4.17.0.12: 1. Update cplus-dem.c from gcc 2.95.1. Changes from gdb 4.17.0.11: 1. Support LinuxThreads on PowerPC. 2. Support P/III and AMD 3DNow! instructions. 3. Fix debugging dynamically loaded shared object. Changes from gdb 4.17.0.10: 1. Support glibc 2.0 and libc 5. 2. Support LinuxThreads on alpha. 3. Support Solaris 2.7/x86. Changes from gdb 4.17.0.9: 1. Fix support for glibc 2.1 pthread. Need the latest glibc 2.1, newer than 16:30pm PST of 19990-02-03. 2. Fix deleting the hardware watchpoint on x86. Changes from gdb 4.17.0.8: 1. The new cplus-dem.c from egcs 1999-01-12 with a bug fix. 2. Add support for deleting the hardware watchpoint on x86. 3. Update support for glibc 2.1 pthread. 4. Fix C++ testsuite. Changes from gdb 4.17.0.6: 1. Support for glibc 2.1 pthread. But it doesn't work, probably due to the CLONE_PTRACE change to pthread in glibc 2.1. 2. Add support for the older Linux C libraries. 3. Add -static support for glibc 2.1. Changes from gdb 4.17.0.5: 1. Support for glibc 2.0 pthread. It doesn't work with glibc 2.1. 2. The Linux/PPC support. 3. The Linux/Sparc support. Untested. Changes from gdb 4.17.0.4: 1. Fix the Intel FPU tag code handling. Changes from gdb 4.17.0.3: 1. Fix testcases for FPU. 2. Fix x86 hardware watchpoint support. Changes from gdb 4.17.0.2: 1. Fake FP registers on older kernels. Changes from gdb 4.17: 1. Linux/x86 FPU support is added. You can debug floating point numbers just like integers. 2. x86 hardware watchpoint is extended to long long, double and long double. 3. More information on x86 CPU status register. 4. Fix a bug when reading beyond the memory boundary. The file list: 1. gdb-4.17-4.17.0.14.diff.gz. Patch against gdb 4.17. 2. gdb-4.17.0.13-4.17.0.14.diff.gz. Patch against gdb 4.17.0.13. 3. gdb-4.17.0.14.x86.gz. Precompiled Linux/x86 statically linked binary. The ftp sites for my gdb patches: ftp://ftp.valinux.com/pub/support/hjl/gdb gdb 4.17 source code is available at ftp://ftp.gnu.org/pub/gnu To install the precompiled binary, # gunzp gdb-4.17.0.14.x86.gz # cp gdb-4.17.0.14.x86 /usr/bin/gdb H.J. hjl@gnu.org 10/03/1999 From drepper@cygnus.com Sun Oct 3 21:40:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Sun, 03 Oct 1999 21:40:00 -0000 Subject: memprof Message-ID: Hi, I've checked in a little program I wrote one or two years ago. It allows profiling to use of memory allocation (heap and stack). A preloadable module generates some binary output which is then transformed into a graphic by another program. The unusual thing about this addition is that the program depends on a library not part of glibc. There is a configure test to test whether the program can be generated but for bootstrapping this is of course not possible. But I really don't care that much about this case and have added a Makefile rule to still allow generating the program afterwards. Play around with it, it's quite useful. E.g., I used it to have "ammunition" when complaining about too much alloca use in gcc. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From aj@suse.de Mon Oct 4 01:49:00 1999 From: aj@suse.de (Andreas Jaeger) Date: Mon, 04 Oct 1999 01:49:00 -0000 Subject: memprof References: Message-ID: >>>>> Ulrich Drepper writes: > Hi, > I've checked in a little program I wrote one or two years ago. It > allows profiling to use of memory allocation (heap and stack). A > preloadable module generates some binary output which is then > transformed into a graphic by another program. > The unusual thing about this addition is that the program depends on a > library not part of glibc. There is a configure test to test whether > the program can be generated but for bootstrapping this is of course > not possible. But I really don't care that much about this case and > have added a Makefile rule to still allow generating the program > afterwards. I only see one problem: Where do distributions put the include files and libraries? Your configure test doesn't work for SuSE which uses /usr/include/gd/ and /usr/lib/libgd.a. Before I change the configure test, I'd like to get feedback from other distributors about the location of libgd files. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.rhein-neckar.de From jk@espy.org Mon Oct 4 05:38:00 1999 From: jk@espy.org (Joel Klecker) Date: Mon, 04 Oct 1999 05:38:00 -0000 Subject: memprof References: Message-ID: At 10:46 +0200 1999-10-04, Andreas Jaeger wrote: >I only see one problem: Where do distributions put the include files >and libraries? Your configure test doesn't work for SuSE which uses >/usr/include/gd/ and /usr/lib/libgd.a. > >Before I change the configure test, I'd like to get feedback from >other distributors about the location of libgd files. The existing test should work fine for Debian. -- Joel Klecker (aka Espy) Debian GNU/Linux Developer From drepper@cygnus.com Mon Oct 4 08:28:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Mon, 04 Oct 1999 08:28:00 -0000 Subject: memprof References: Message-ID: Andreas Jaeger writes: > I only see one problem: Where do distributions put the include files > and libraries? Your configure test doesn't work for SuSE which uses > /usr/include/gd/ and /usr/lib/libgd.a. This is why you can add --with-gd=/usr/local This is what I have to do. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From aj@suse.de Mon Oct 4 08:45:00 1999 From: aj@suse.de (Andreas Jaeger) Date: Mon, 04 Oct 1999 08:45:00 -0000 Subject: memprof References: Message-ID: >>>>> Ulrich Drepper writes: Uli> Andreas Jaeger writes: >> I only see one problem: Where do distributions put the include files >> and libraries? Your configure test doesn't work for SuSE which uses >> /usr/include/gd/ and /usr/lib/libgd.a. Uli> This is why you can add Uli> --with-gd=/usr/local Uli> This is what I have to do. This will not work. I need as include path: /usr/include/gd and --with-gd will always add an include directory. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.rhein-neckar.de From hjl@valinux.com Tue Oct 5 18:27:00 1999 From: hjl@valinux.com (H.J. Lu) Date: Tue, 05 Oct 1999 18:27:00 -0000 Subject: A patch for libresolv Message-ID: <19991006012700.3C0933FC1@valinux.com> Hi, There are many options in libresolve. However, there are no codes to set them. Here is a patch to handle options for libresolve. -- H.J. Lu (hjl@gnu.org) -- Tue Oct 5 18:23:01 1999 H.J. Lu * resolv/res_init.c (o_mnemonic): New. (res_setoptions): Use it. Index: resolv/res_init.c =================================================================== RCS file: /work/cvs/gnu/glibc-2.1/resolv/res_init.c,v retrieving revision 1.1.1.9 diff -u -p -r1.1.1.9 res_init.c --- resolv/res_init.c 1999/05/05 01:35:31 1.1.1.9 +++ resolv/res_init.c 1999/10/06 01:21:05 @@ -111,6 +111,7 @@ static int netinfo_res_init __P((int *ha #endif static void res_setoptions __P((char *, char *)) internal_function; +static u_long o_mnemonic __P((const char * mnemonic)) internal_function; #ifdef RESOLVSORT static const char sort_mask[] = "/&"; @@ -427,12 +428,66 @@ res_init() return (0); } +/* + * Return an option from a mnemonic. + */ +static u_long +internal_function +o_mnemonic (mnemonic) + const char * mnemonic; +{ + if (strncasecmp (mnemonic, "init", sizeof ("init") - 1) == 0) + return RES_INIT; + else if (strncasecmp (mnemonic, "debug", + sizeof ("debug") - 1) == 0) + return RES_DEBUG; + else if (strncasecmp (mnemonic, "aaonly", + sizeof ("aaonly") - 1) == 0) + return RES_AAONLY; + else if (strncasecmp (mnemonic, "usevc", + sizeof ("usevc") - 1) == 0) + return RES_USEVC; + else if (strncasecmp (mnemonic, "primry", + sizeof ("primry") - 1) == 0) + return RES_PRIMARY; + else if (strncasecmp (mnemonic, "igntc", + sizeof ("igntc") - 1) == 0) + return RES_IGNTC; + else if (strncasecmp (mnemonic, "recurs", + sizeof ("recurs") - 1) == 0) + return RES_RECURSE; + else if (strncasecmp (mnemonic, "defnam", + sizeof ("defnam") - 1) == 0) + return RES_DEFNAMES; + else if (strncasecmp (mnemonic, "styopn", + sizeof ("styopn") - 1) == 0) + return RES_STAYOPEN; + else if (strncasecmp (mnemonic, "dnsrch", + sizeof ("dnsrch") - 1) == 0) + return RES_DNSRCH; + else if (strncasecmp (mnemonic, "insecure1", + sizeof ("insecure1") - 1) == 0) + return RES_INSECURE1; + else if (strncasecmp (mnemonic, "insecure2", + sizeof ("insecure2") - 1) == 0) + return RES_INSECURE2; + else if (strncasecmp (mnemonic, "noaliases", + sizeof ("noaliases") - 1) == 0) + return RES_NOALIASES; + else if (strncasecmp (mnemonic, "inet6", + sizeof ("inet6") - 1) == 0) + return RES_USE_INET6; + else + return ~0; +} + static void internal_function res_setoptions(options, source) char *options, *source; { char *cp = options; + u_long option; int i; #ifdef DEBUG @@ -464,8 +519,8 @@ res_setoptions(options, source) } printf(";;\tdebug\n"); #endif - } else if (!strncmp(cp, "inet6", sizeof("inet6") - 1)) { - _res.options |= RES_USE_INET6; + } else if ((option = o_mnemonic (cp)) != ~0) { + _res.options |= option; } else { /* XXX - print a warning here? */ } From drepper@cygnus.com Thu Oct 7 00:28:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Thu, 07 Oct 1999 00:28:00 -0000 Subject: one more toy Message-ID: I've checked in one more toy. It is just one example what can be done with the pcprofile code which was already in debug/ (Now you know what it is for). Try running xtrace on a program and it will run the application in a second xterm while it tracks in the original program the names of the currently used functions. As I've said it's an example but maybe it's useful for the one or the other long running application. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From schwab@suse.de Thu Oct 7 03:18:00 1999 From: schwab@suse.de (Andreas Schwab) Date: Thu, 07 Oct 1999 03:18:00 -0000 Subject: one more toy References: Message-ID: Ulrich Drepper writes: |> I've checked in one more toy. It is just one example what can be done |> with the pcprofile code which was already in debug/ (Now you know what |> it is for). |> |> Try running xtrace on a program and it will run the application in a |> second xterm while it tracks in the original program the names of the |> currently used functions. As I've said it's an example but maybe it's |> useful for the one or the other long running application. Can you please give us a hint about what this toy is supposed to do? I cannot get this thing to do anything usefull. Andreas. -- Andreas Schwab "And now for something SuSE Labs completely different." schwab@suse.de SuSE GmbH, Schanz????ckerstr. 10, D-90443 N????rnberg From aj@suse.de Thu Oct 7 08:08:00 1999 From: aj@suse.de (Andreas Jaeger) Date: Thu, 07 Oct 1999 08:08:00 -0000 Subject: New mathetests - please send comments Message-ID: I've put on ftp.suse.com a version of my current development version of the new mathtest: < ftp://ftp.suse.com/pub/people/aj/mathtest-19991007-1650.tar.gz > The suite isn't finished yet - but it's in such a shape that I'd like to get your comments. Just unpack the sources, type make and run the files. The file Epsilon is a platform specific file that contains limits for the different functions and calls. Please note that I still need to do at least the following: - convert all test from libm-test.c - handle inline tests - incorporate the suite in glibc (this includes searching for the platform specific epsilon file) - clean up the different files - document everything The tests have two different options: --verbose=0,1,2 (0 is silent, 1 is just Failures and XPasses, 2 is everything) -u: Creates an epsilon file that can be read in again (filename ULPs) with all errors in it I've added the possibility to signal some tests as failing (just write e.g. "double: fail" in Epsilon for one test). This allows us to document known problems instead of using high ulp numbers. Uli suggested to generate the needed included files during `make check'. This means that the user needs to have perl installed. Since this is only a test, I don't see a problem here. Please speak up if see any problems with the suite or if anything is missing. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.rhein-neckar.de From drepper@cygnus.com Thu Oct 7 09:08:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Thu, 07 Oct 1999 09:08:00 -0000 Subject: one more toy References: Message-ID: Andreas Schwab writes: > Can you please give us a hint about what this toy is supposed to do? I > cannot get this thing to do anything usefull. If you run, e.g., xtrace someprogram itsargs you'll see in realtime in which function the program currently is working. This can (and will be) extended in future and I want to combine the functionality with that of the memory profiling. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From drepper@cygnus.com Thu Oct 7 09:19:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Thu, 07 Oct 1999 09:19:00 -0000 Subject: one more toy References: Message-ID: Uh, I forgot to mention. Since the preloaded module uses the __cyg_profile_func_* hooks you have to compile your code with -finstrument-functions. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From geoffk@ozemail.com.au Thu Oct 7 21:22:00 1999 From: geoffk@ozemail.com.au (Geoff Keating) Date: Thu, 07 Oct 1999 21:22:00 -0000 Subject: Fix for Mozilla problem on ppc... Message-ID: <199910080356.NAA00806@gluttony.geoffk.wattle.id.au> This fixes the first of the bugs that Greg reported. It was a cache-flushing bug, but I also fixed the FIXME because apparently mozilla has such huge objects that it might actually trigger it. The patch is relative to the release branch. I'd be interested in comments about the patch to the generic code. The problem was that the new approach is to always assume we will be doing lazy relocations, and then handle relocs later. This is actually slightly more efficient, but it means that the code for 'fixup' must not call any PLT entries itself as otherwise it will go into infinite recursion. The alternative would be to pass __elf_machine_runtime_setup a special flag that warns it that the object has already been relocated; or just don't call __elf_machine_runtime_setup in this case. Or perhaps I'll just take all the JMP_SLOT relocation into __elf_machine_runtime_setup when !lazy... I'm not proposing to add it just now, I want a little more experience with it before I let it loose on the world. -- Geoffrey Keating ===File ~/patches/glibc-56b.patch=========================== md5sum: 916abc2d60b09907 faaf19f926fdf535 141389 Index: libc/ChangeLog 0a 1999-10-07 Geoffrey Keating * sysdeps/powerpc/dl-machine.c: Many minor formatting changes. (OPCODE_LWZU): New macro. (OPCODE_ADDIS_HI): New macro. (OPCODE_LIS_HI): New macro. (__elf_machine_runtime_setup): Change PLT code-generation scheme for thread safety even with very large PLTs, better efficiency, and to fix a cache-flushing bug. (__elf_machine_fixup_plt): Likewise. * elf/dl-lookup.c (_dl_lookup_symbol): Add alias, __dl_lookup_symbol. (_dl_lookup_versioned_symbol): Add alias, __dl_lookup_versioned_symbol. * elf/ldsodefs.h: Prototype aliases. * elf/dl-runtime.c (fixup): Use aliases to avoid recursion during relocation of ld.so. . Changed files: libc/ChangeLog libc/elf/dl-lookup.c libc/elf/dl-runtime.c libc/elf/ldsodefs.h libc/sysdeps/powerpc/dl-machine.c md5sum: a0a6f74e1cfcac41 8b9c79d5bb32b606 10071 --- /sloth/disk0/co/glibc-release/libc/elf/dl-lookup.c Thu Oct 7 21:04:56 1999 +++ libc/elf/dl-lookup.c Thu Oct 7 22:37:25 1999 @@ -116,6 +116,7 @@ _dl_lookup_symbol (const char *undef_nam *ref = current_value.s; return current_value.m->l_addr; } +strong_alias(_dl_lookup_symbol, __dl_lookup_symbol) /* This function is nearly the same as `_dl_lookup_symbol' but it @@ -243,6 +244,7 @@ _dl_lookup_versioned_symbol (const char *ref = current_value.s; return current_value.m->l_addr; } +strong_alias(_dl_lookup_versioned_symbol, __dl_lookup_versioned_symbol) /* Similar to _dl_lookup_symbol_skip but takes an additional argument md5sum: 449ceed2fc99f121 20a2f482b8d0036f 6563 --- /sloth/disk0/co/glibc-release/libc/elf/dl-runtime.c Thu Oct 7 21:04:58 1999 +++ libc/elf/dl-runtime.c Thu Oct 7 22:34:29 1999 @@ -78,15 +78,16 @@ fixup ( if (version->hash != 0) { - value = _dl_lookup_versioned_symbol(strtab + sym->st_name, - &sym, l->l_scope, l->l_name, - version, ELF_MACHINE_JMP_SLOT); + value = __dl_lookup_versioned_symbol(strtab + sym->st_name, + &sym, l->l_scope, l->l_name, + version, + ELF_MACHINE_JMP_SLOT); break; } } case 0: - value = _dl_lookup_symbol (strtab + sym->st_name, &sym, l->l_scope, - l->l_name, ELF_MACHINE_JMP_SLOT); + value = __dl_lookup_symbol (strtab + sym->st_name, &sym, l->l_scope, + l->l_name, ELF_MACHINE_JMP_SLOT); } /* Currently value contains the base load address of the object md5sum: f3e1df8f76534560 ef74e4957d0f8da9 16755 --- /sloth/disk0/co/glibc-release/libc/elf/ldsodefs.h Thu Oct 7 21:05:03 1999 +++ libc/elf/ldsodefs.h Thu Oct 7 22:34:29 1999 @@ -306,6 +306,23 @@ extern ElfW(Addr) _dl_lookup_versioned_s int reloc_type) internal_function; +/* These are identical to the single-underscore versions, + but are not exported from ld.so which helps with lazy PLT + relocation. */ +extern ElfW(Addr) __dl_lookup_symbol (const char *undef, + const ElfW(Sym) **sym, + struct r_scope_elem *symbol_scope[], + const char *reference_name, + int reloc_type) + internal_function; +extern ElfW(Addr) __dl_lookup_versioned_symbol (const char *undef, + const ElfW(Sym) **sym, + struct r_scope_elem *symbol_scope[], + const char *reference_name, + const struct r_found_version *version, + int reloc_type) + internal_function; + /* For handling RTLD_NEXT we must be able to skip shared objects. */ extern ElfW(Addr) _dl_lookup_symbol_skip (const char *undef, const ElfW(Sym) **sym, md5sum: 1369ff9e2fe6e0bb 9641ed22ce705835 15250 --- /sloth/disk0/co/glibc-release/libc/sysdeps/powerpc/dl-machine.c Thu Oct 7 21:12:54 1999 +++ libc/sysdeps/powerpc/dl-machine.c Thu Oct 7 22:35:51 1999 @@ -33,17 +33,18 @@ #endif -/* stuff for the PLT */ +/* Stuff for the PLT. */ #define PLT_INITIAL_ENTRY_WORDS 18 -#define PLT_LONGBRANCH_ENTRY_WORDS 10 +#define PLT_LONGBRANCH_ENTRY_WORDS 12 #define PLT_DOUBLE_SIZE (1<<13) #define PLT_ENTRY_START_WORDS(entry_number) \ - (PLT_INITIAL_ENTRY_WORDS + (entry_number)*2 + \ - ((entry_number) > PLT_DOUBLE_SIZE ? \ - ((entry_number) - PLT_DOUBLE_SIZE)*2 : \ - 0)) + (PLT_INITIAL_ENTRY_WORDS + (entry_number)*2 \ + + ((entry_number) > PLT_DOUBLE_SIZE \ + ? ((entry_number) - PLT_DOUBLE_SIZE)*2 \ + : 0)) #define PLT_DATA_START_WORDS(num_entries) PLT_ENTRY_START_WORDS(num_entries) +/* Macros to build PowerPC opcode words. */ #define OPCODE_ADDI(rd,ra,simm) \ (0x38000000 | (rd) << 21 | (ra) << 16 | ((simm) & 0xffff)) #define OPCODE_ADDIS(rd,ra,simm) \ @@ -55,11 +56,16 @@ #define OPCODE_BCTR() 0x4e800420 #define OPCODE_LWZ(rd,d,ra) \ (0x80000000 | (rd) << 21 | (ra) << 16 | ((d) & 0xffff)) +#define OPCODE_LWZU(rd,d,ra) \ + (0x84000000 | (rd) << 21 | (ra) << 16 | ((d) & 0xffff)) #define OPCODE_MTCTR(rd) (0x7C0903A6 | (rd) << 21) #define OPCODE_RLWINM(ra,rs,sh,mb,me) \ (0x54000000 | (rs) << 21 | (ra) << 16 | (sh) << 11 | (mb) << 6 | (me) << 1) #define OPCODE_LI(rd,simm) OPCODE_ADDI(rd,0,simm) +#define OPCODE_ADDIS_HI(rd,ra,value) \ + OPCODE_ADDIS(rd,ra,((value) + 0x8000) >> 16) +#define OPCODE_LIS_HI(rd,value) OPCODE_ADDIS_HI(rd,0,value) #define OPCODE_SLWI(ra,rs,sh) OPCODE_RLWINM(ra,rs,sh,0,31-sh) @@ -136,126 +142,167 @@ __elf_preferred_address(struct link_map Also install a small trampoline to be used by entries that have been relocated to an address too far away for a single branch. */ -/* A PLT entry does one of three things: - (i) Jumps to the actual routine. Such entries are set up above, in - elf_machine_rela. +/* There are three kinds of PLT entries: - (ii) Jumps to the actual routine via glue at the start of the PLT. - We do this by putting the address of the routine in space - allocated at the end of the PLT, and when the PLT entry is - called we load the offset of that word (from the start of the - space) into r11, then call the glue, which loads the word and - branches to that address. These entries are set up in - elf_machine_rela, but the glue is set up here. + (1) A direct jump to the actual routine, either a relative or + absolute branch. These are set up in __elf_machine_fixup_plt. - (iii) Loads the index of this PLT entry (we count the double-size - entries as one entry for this purpose) into r11, then - branches to code at the start of the PLT. This code then - calls `fixup', in dl-runtime.c, via the glue in the macro - ELF_MACHINE_RUNTIME_TRAMPOLINE, which resets the PLT entry to - be one of the above two types. These entries are set up here. */ + (2) Short lazy entries. These cover the first 8192 slots in + the PLT, and look like (where 'index' goes from 0 to 8191): + + li %r11, index*4 + b &plt[1] + + (3) Short indirect jumps. These replace (2) when a direct jump + wouldn't reach. They look the same except that the branch + is 'b &plt[PLT_LONGBRANCH_ENTRY_WORDS]'. + + (4) Long lazy entries. These cover the slots when a short entry + won't fit ('index*4' overflows its field), and look like: + + lis %r11, %hi(index*4 + &plt[PLT_DATA_START_WORDS]) + lwzu %r12, %r11, %lo(index*4 + &plt[PLT_DATA_START_WORDS]) + b &plt[0] + bctr + + (5) Long indirect jumps. These replace (4) when a direct jump + wouldn't reach. They look like: + + lis %r11, %hi(index*4 + &plt[PLT_DATA_START_WORDS]) + lwz %r12, %r11, %lo(index*4 + &plt[PLT_DATA_START_WORDS]) + mtctr %r12 + bctr + + + The lazy entries, (2) and (4), are set up here in + __elf_machine_runtime_setup. The remainder are set up in + __elf_machine_fixup_plt. + + The reason for the somewhat strange construction of the long + entries, (4) and (5), is that we need to ensure thread-safety. For + (1) and (3), this is obvious because only one instruction is + changed and the PPC architecture guarantees that aligned stores are + atomic. For (5), this is more tricky. When changing (4) to (5), + the `b' instruction is first changed to to `mtctr'; this is safe + and is why the `lwzu' instruction is not just a simple `addi'. + Once this is done, and is visible to all processors, the `lwzu' can + safely be changed to a `lwz'. */ int __elf_machine_runtime_setup (struct link_map *map, int lazy, int profile) { if (map->l_info[DT_JMPREL]) { Elf32_Word i; - /* Fill in the PLT. Its initial contents are directed to a - function earlier in the PLT which arranges for the dynamic - linker to be called back. */ Elf32_Word *plt = (Elf32_Word *) map->l_info[DT_PLTGOT]->d_un.d_val; Elf32_Word num_plt_entries = (map->l_info[DT_PLTRELSZ]->d_un.d_val / sizeof (Elf32_Rela)); Elf32_Word rel_offset_words = PLT_DATA_START_WORDS (num_plt_entries); + Elf32_Word data_words = (Elf32_Word) (plt + rel_offset_words); Elf32_Word size_modified; + Elf32_Word offset; + extern void _dl_runtime_resolve (void); extern void _dl_prof_resolve (void); Elf32_Word dlrr; - dlrr = (Elf32_Word)(char *)(profile - ? _dl_prof_resolve - : _dl_runtime_resolve); + /* Note that when we first execute this code, to relocate ld.so, + this will produce garbage in 'dlrr' because the pointers + won't be set up yet. */ + dlrr = (Elf32_Word)(profile + ? _dl_prof_resolve + : _dl_runtime_resolve); + if (profile && _dl_name_match_p (_dl_profile, map)) + /* This is the object we are looking for. Say that we really + want profiling and the timers are started. */ + _dl_profile_map = map; - if (lazy) - for (i = 0; i < num_plt_entries; i++) + /* Set up the lazy PLT entries. + This is done even if we will not actually be using a lazy PLT, + as it saves us substantial work in __elf_machine_fixup_plt. + In particular, it means that __elf_machine_fixup_plt need + not have to worry about flushing more than one block from + the cache. */ + offset = PLT_INITIAL_ENTRY_WORDS; + i = 0; + while (i < num_plt_entries && i < PLT_DOUBLE_SIZE) { - Elf32_Word offset = PLT_ENTRY_START_WORDS (i); - - if (i >= PLT_DOUBLE_SIZE) - { - plt[offset ] = OPCODE_LI (11, i * 4); - plt[offset+1] = OPCODE_ADDIS (11, 11, (i * 4 + 0x8000) >> 16); - plt[offset+2] = OPCODE_B (-(4 * (offset + 2))); - } - else - { - plt[offset ] = OPCODE_LI (11, i * 4); - plt[offset+1] = OPCODE_B (-(4 * (offset + 1))); - } + plt[offset ] = OPCODE_LI (11, i * 4); + plt[offset+1] = OPCODE_B (4 * (2 - (offset+1))); /* To plt+2. */ + i++; + offset += 2; + } + while (i < num_plt_entries) + { + plt[offset ] = OPCODE_LIS_HI (11, i * 4 + data_words); + plt[offset+1] = OPCODE_LWZU (12, i * 4 + data_words, 11); + plt[offset+2] = OPCODE_B (4 * (0 - (offset+2))); /* To plt+0. */ + plt[offset+3] = OPCODE_BCTR (); + i++; + offset += 4; } + /* For the long entries, subtract off data_words. */ + plt[0] = OPCODE_ADDIS_HI (11, 11, -data_words); + plt[1] = OPCODE_ADDI (11, 11, -data_words); + /* Multiply index of entry by 3 (in r11). */ - plt[0] = OPCODE_SLWI (12, 11, 1); - plt[1] = OPCODE_ADD (11, 12, 11); + plt[2] = OPCODE_SLWI (12, 11, 1); + plt[3] = OPCODE_ADD (11, 12, 11); if (dlrr <= 0x01fffffc || dlrr >= 0xfe000000) { /* Load address of link map in r12. */ - plt[2] = OPCODE_LI (12, (Elf32_Word) (char *) map); - plt[3] = OPCODE_ADDIS (12, 12, (((Elf32_Word) (char *) map - + 0x8000) >> 16)); + plt[4] = OPCODE_LI (12, (Elf32_Word) map); + plt[5] = OPCODE_ADDIS_HI (12, 12, (Elf32_Word) map); /* Call _dl_runtime_resolve. */ - plt[4] = OPCODE_BA (dlrr); + plt[6] = OPCODE_BA (dlrr); } else { /* Get address of _dl_runtime_resolve in CTR. */ - plt[2] = OPCODE_LI (12, dlrr); - plt[3] = OPCODE_ADDIS (12, 12, (dlrr + 0x8000) >> 16); - plt[4] = OPCODE_MTCTR (12); + plt[4] = OPCODE_LI (12, dlrr); + plt[5] = OPCODE_ADDIS_HI (12, 12, dlrr); + plt[6] = OPCODE_MTCTR (12); /* Load address of link map in r12. */ - plt[5] = OPCODE_LI (12, (Elf32_Word) (char *) map); - plt[6] = OPCODE_ADDIS (12, 12, (((Elf32_Word) (char *) map - + 0x8000) >> 16)); + plt[7] = OPCODE_LI (12, (Elf32_Word) map); + plt[8] = OPCODE_ADDIS_HI (12, 12, (Elf32_Word) map); /* Call _dl_runtime_resolve. */ - plt[7] = OPCODE_BCTR (); + plt[9] = OPCODE_BCTR (); } - /* Convert the index in r11 into an actual address, and get the word at that address. */ - plt[PLT_LONGBRANCH_ENTRY_WORDS] = - OPCODE_ADDIS (11, 11, (((Elf32_Word) (char*) (plt + rel_offset_words) - + 0x8000) >> 16)); - plt[PLT_LONGBRANCH_ENTRY_WORDS+1] = - OPCODE_LWZ (11, (Elf32_Word) (char*) (plt + rel_offset_words), 11); + plt[PLT_LONGBRANCH_ENTRY_WORDS] = OPCODE_ADDIS_HI (11, 11, data_words); + plt[PLT_LONGBRANCH_ENTRY_WORDS+1] = OPCODE_LWZ (11, data_words, 11); /* Call the procedure at that address. */ plt[PLT_LONGBRANCH_ENTRY_WORDS + 2] = OPCODE_MTCTR (11); plt[PLT_LONGBRANCH_ENTRY_WORDS + 3] = OPCODE_BCTR (); - /* Now, we've modified code (quite a lot of code, possibly). We - need to write the changes from the data cache to a - second-level unified cache, then make sure that stale data in - the instruction cache is removed. (In a multiprocessor - system, the effect is more complex.) Most of the PLT shouldn't - be in the instruction cache, but there may be a little overlap - at the start and the end. + /* Now, we've modified code. We need to write the changes from + the data cache to a second-level unified cache, then make + sure that stale data in the instruction cache is removed. + (In a multiprocessor system, the effect is more complex.) + Most of the PLT shouldn't be in the instruction cache, but + there may be a little overlap at the start and the end. + + The cache management here relies on __elf_machine_fixup_plt + flushing the rest of the PLT when !lazy. Assumes the cache line size is at least 32 bytes, or at least that dcbst and icbi apply to 32-byte lines. At present, all PowerPC processors have line sizes of exactly 32 bytes. */ - size_modified = lazy ? rel_offset_words : PLT_INITIAL_ENTRY_WORDS; - for (i = 0; i < size_modified; i+= 8) + size_modified = lazy ? rel_offset_words : PLT_INITIAL_ENTRY_WORDS+1+7; + for (i = 0; i < size_modified; i += 8) PPC_DCBST (plt + i); - PPC_DCBST (plt + size_modified - 1); + PPC_DCBST (plt + rel_offset_words - 1); PPC_SYNC; PPC_ICBI (plt); - PPC_ICBI (plt + size_modified-1); + PPC_ICBI (plt + rel_offset_words - 1); PPC_ISYNC; } @@ -266,61 +313,45 @@ __elf_machine_runtime_setup (struct link __elf_machine_fixup_plt(struct link_map *map, const Elf32_Rela *reloc, Elf32_Addr *reloc_addr, Elf32_Addr finaladdr) { - Elf32_Sword delta = finaladdr - (Elf32_Word) (char *) reloc_addr; + Elf32_Sword delta = finaladdr - (Elf32_Word) reloc_addr; if (delta << 6 >> 6 == delta) *reloc_addr = OPCODE_B (delta); else if (finaladdr <= 0x01fffffc || finaladdr >= 0xfe000000) *reloc_addr = OPCODE_BA (finaladdr); else { - Elf32_Word *plt; - Elf32_Word index; - + Elf32_Word *plt, *data_words; + Elf32_Word index, offset, num_plt_entries; + + num_plt_entries = (map->l_info[DT_PLTRELSZ]->d_un.d_val + / sizeof(Elf32_Rela)); plt = (Elf32_Word *) map->l_info[DT_PLTGOT]->d_un.d_val; - index = (reloc_addr - plt - PLT_INITIAL_ENTRY_WORDS)/2; - if (index >= PLT_DOUBLE_SIZE) - { - /* Slots greater than or equal to 2^13 have 4 words available - instead of two. */ - /* FIXME: There are some possible race conditions in this code, - when called from 'fixup'. - - 1) Suppose that a lazy PLT entry is executing, a context switch - between threads (or a signal) occurs, and the new thread or - signal handler calls the same lazy PLT entry. Then the PLT entry - would be changed while it's being run, which will cause a segfault - (almost always). - - 2) Suppose the reverse: that a lazy PLT entry is being updated, - a context switch occurs, and the new code calls the lazy PLT - entry that is being updated. Then the half-fixed PLT entry will - be executed, which will also almost always cause a segfault. + offset = reloc_addr - plt; + index = (offset - PLT_INITIAL_ENTRY_WORDS)/2; + data_words = plt + PLT_DATA_START_WORDS (num_plt_entries); - These problems don't happen with the 2-word entries, because - only one of the two instructions are changed when a lazy entry - is retargeted at the actual PLT entry; the li instruction stays - the same (we have to update it anyway, because we might not be - updating a lazy PLT entry). */ + reloc_addr += 1; - reloc_addr[0] = OPCODE_LI (11, finaladdr); - reloc_addr[1] = OPCODE_ADDIS (11, 11, (finaladdr + 0x8000) >> 16); - reloc_addr[2] = OPCODE_MTCTR (11); - reloc_addr[3] = OPCODE_BCTR (); + if (index < PLT_DOUBLE_SIZE) + { + data_words[index] = finaladdr; + PPC_SYNC; + *reloc_addr = OPCODE_B ((PLT_LONGBRANCH_ENTRY_WORDS - (offset+1)) + * 4); } else { - Elf32_Word num_plt_entries; + index -= (index - PLT_DOUBLE_SIZE)/2; - num_plt_entries = (map->l_info[DT_PLTRELSZ]->d_un.d_val - / sizeof(Elf32_Rela)); + data_words[index] = finaladdr; + PPC_SYNC; - plt[index+PLT_DATA_START_WORDS (num_plt_entries)] = finaladdr; - reloc_addr[0] = OPCODE_LI (11, index*4); - reloc_addr[1] = OPCODE_B (-(4*(index*2 - + 1 - - PLT_LONGBRANCH_ENTRY_WORDS - + PLT_INITIAL_ENTRY_WORDS))); - reloc_addr += 1; /* This is the modified address. */ + reloc_addr[1] = OPCODE_MTCTR (12); + MODIFIED_CODE_NOQUEUE (reloc_addr + 1); + PPC_SYNC; + + reloc_addr[0] = OPCODE_LWZ (12, + (Elf32_Word) (data_words + index), 11); } } MODIFIED_CODE (reloc_addr); ============================================================ From drepper@cygnus.com Thu Oct 7 22:07:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Thu, 07 Oct 1999 22:07:00 -0000 Subject: K&R and ISO Message-ID: Hi, I got today the news that ISO C99 passed the JTC. This has multiple implications: - glibc is (almost) ready - we are missing the nice "ISO C9A" joke But this also brought up anothing thing: after 10 years we are still carrying around the balast of K&R. And this with a cost everybody has to pay everything s/he uses a compiler. I really think this is not acceptable anymore. K&R is dead, at least on GNU platforms. Therefore I would like to drop all K&R compatibility. This means, all headers will loose the __P and the __const and whatever junk we have. I think this can considerably speed up the preprocessor. Does anybody have problems with this? Are there any chances that you could thinnk this is a problem? -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From drepper@cygnus.com Fri Oct 8 00:05:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Fri, 08 Oct 1999 00:05:00 -0000 Subject: more new code Message-ID: Hi, you might have noticed that I checked in a whole bunch of new code. This is code from the thread debug support library in wrote in the last weeks as part of my job for a contract we have with API (Alpha Processor Inc). The interface of the library is designed after the library Sun uses on Solaris. It is by itself not very helpful but gdb currently also gets extended to make use of. This means that real thread debugging support is not too far away. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From aj@suse.de Fri Oct 8 07:36:00 1999 From: aj@suse.de (Andreas Jaeger) Date: Fri, 08 Oct 1999 07:36:00 -0000 Subject: New mathetests - please send comments References: Message-ID: >>>>> Andreas Jaeger writes: > I've put on ftp.suse.com a version of my current development version > of the new mathtest: > < ftp://ftp.suse.com/pub/people/aj/mathtest-19991007-1650.tar.gz > A new version should be available soon: < ftp://ftp.suse.com/pub/people/aj/mathtest-19991008-1625.tar.gz > > The suite isn't finished yet - but it's in such a shape that I'd like > to get your comments. Just unpack the sources, type make and run the files. > The file Epsilon is a platform specific file that contains limits for > the different functions and calls. > Please note that I still need to do at least the following: > - convert all test from libm-test.c I've converted some more. > - handle inline tests Done. > - incorporate the suite in glibc (this includes searching for the > platform specific epsilon file) > - clean up the different files > - document everything > The tests have two different options: > --verbose=0,1,2 (0 is silent, 1 is just Failures and XPasses, 2 is > everything) > -u: Creates an epsilon file that can be read in again (filename ULPs) > with all errors in it > I've added the possibility to signal some tests as failing (just write > e.g. "double: fail" in Epsilon for one test). This allows us to > document known problems instead of using high ulp numbers. > Uli suggested to generate the needed included files during `make > check'. This means that the user needs to have perl installed. Since > this is only a test, I don't see a problem here. > Please speak up if see any problems with the suite or if anything is > missing. The rest still applies;-). Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.rhein-neckar.de From roland@frob.com Fri Oct 8 10:32:00 1999 From: roland@frob.com (Roland McGrath) Date: Fri, 08 Oct 1999 10:32:00 -0000 Subject: K&R and ISO References: Message-ID: <199910081732.NAA17039@frob.com> I don't see a problem for libc itself, as long as you make sure that it still works to use gcc to compile K&R code with libc. That is, unconditionally using prototype declarations shouldn't be a problem. Using const instead of __const, et al, might be a problem for some old programs; and I don't think it is worthwhile to break those without gleaning a real benefit. In the case of the new reserved words, we can just use __const et al as now and let gcc's lexer rather than the preprocessor deal with them; it already handles the __ified names for the new reserved words. The problematic question is for the various pieces of libc that are also used in other packages. You should ask gnu-prog about the needs there. I would be inclined to leave all those (glob, fnmatch, etc) as they are. From drepper@cygnus.com Fri Oct 8 10:39:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Fri, 08 Oct 1999 10:39:00 -0000 Subject: K&R and ISO References: <199910081732.NAA17039@frob.com> Message-ID: Roland McGrath writes: > I don't see a problem for libc itself, as long as you make sure that it > still works to use gcc to compile K&R code with libc. That is, > unconditionally using prototype declarations shouldn't be a problem. I don't understand. Gcc can happily mix K&R code and ISO code. Using the -traditional flag of gcc already does not work so this is no additional restriction. > In the case of the new reserved words, we can just use __const et > al as now and let gcc's lexer rather than the preprocessor deal with them; > it already handles the __ified names for the new reserved words. This is what I intended to do. Simply remove the __const, __signed, __volatile macro definitions. > The problematic question is for the various pieces of libc that are also > used in other packages. You should ask gnu-prog about the needs there. > I would be inclined to leave all those (glob, fnmatch, etc) as they are. The only program needed for bootstrapping which takes code from glibc is make. For fnmatch/glob we can either leave them as is or use ansi2knr or unprotoize. The latter is what many GNU packages do nowadays. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From roland@frob.com Fri Oct 8 10:44:00 1999 From: roland@frob.com (Roland McGrath) Date: Fri, 08 Oct 1999 10:44:00 -0000 Subject: K&R and ISO References: Message-ID: <199910081744.NAA17183@frob.com> > I don't understand. Gcc can happily mix K&R code and ISO code. Using > the -traditional flag of gcc already does not work so this is no > additional restriction. That is what I said. We are in agreement. > The only program needed for bootstrapping which takes code from glibc > is make. For fnmatch/glob we can either leave them as is or use > ansi2knr or unprotoize. The latter is what many GNU packages do > nowadays. Though I guess it is not a priority for GNU, I would like to leave the decisions of how portable to what systems each package needs to be to the discretion of that package's maintainer. If using ansi2knr or unprotoize is sufficient, then all the better. I'd just like to give the maintainers a chance to explicitly respond to your proposal before just deciding for them. From drepper@cygnus.com Fri Oct 8 10:58:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Fri, 08 Oct 1999 10:58:00 -0000 Subject: K&R and ISO References: <199910081744.NAA17183@frob.com> Message-ID: Roland McGrath writes: > I'd just like to give the maintainers a chance to explicitly respond > to your proposal before just deciding for them. I'll leave the two files glob.h and fnmatch.h alone until this is resolved. Anybody else want to comment. So far we have three votes for yes (rth, roland, me). -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From alain@qnx.com Fri Oct 8 11:02:00 1999 From: alain@qnx.com (Alain Magloire) Date: Fri, 08 Oct 1999 11:02:00 -0000 Subject: K&R and ISO References: <199910081744.NAA17183@frob.com> Message-ID: <199910081802.OAA13779@qnx.com> > > > I don't understand. Gcc can happily mix K&R code and ISO code. Using > > the -traditional flag of gcc already does not work so this is no > > additional restriction. > > That is what I said. We are in agreement. > > > The only program needed for bootstrapping which takes code from glibc > > is make. For fnmatch/glob we can either leave them as is or use > > ansi2knr or unprotoize. The latter is what many GNU packages do > > nowadays. > > Though I guess it is not a priority for GNU, I would like to leave the > decisions of how portable to what systems each package needs to be to the > discretion of that package's maintainer. If using ansi2knr or unprotoize > is sufficient, then all the better. I'd just like to give the maintainers > a chance to explicitly respond to your proposal before just deciding for them. I already did, when I brought the point to U.D., regex.[ch] is use in many packages and will not compile without an ANSI C. I'm a bit worry that next time I'll look, it will need not only an ANSI C comp. but gcc. Of course I can not impose my views on the course of glibc, and I certainly can understand U.D. not to want to carry those extra wait any longer. Maybe it's time for a scission, in any case I(and many other maintainers) did benefice from the general improvements made in this forum. -- au revoir, alain ---- Aussi haut que l'on soit assis, on n'est toujours assis que sur son cul !!! From zack@bitmover.com Fri Oct 8 11:07:00 1999 From: zack@bitmover.com (Zack Weinberg) Date: Fri, 08 Oct 1999 11:07:00 -0000 Subject: K&R and ISO References: <199910081744.NAA17183@frob.com> Message-ID: <199910081807.LAA05052@zack.bitmover.com> Ulrich Drepper wrote: > Roland McGrath writes: > > > I'd just like to give the maintainers a chance to explicitly respond > > to your proposal before just deciding for them. > > I'll leave the two files glob.h and fnmatch.h alone until this is > resolved. > > Anybody else want to comment. So far we have three votes for yes > (rth, roland, me). I like the idea, but remember that people want to use libc headers with compilers other than GCC. Those compilers usually support C89 but don't understand the __ form of keywords. So we should #define them to the non-underscored form if __GNUC__ is not defined. Also, __restrict still needs to be conditional. zw From Philip.Blundell@pobox.com Fri Oct 8 11:14:00 1999 From: Philip.Blundell@pobox.com (Philip Blundell) Date: Fri, 08 Oct 1999 11:14:00 -0000 Subject: K&R and ISO References: <199910081744.NAA17183@frob.com> Message-ID: >Anybody else want to comment. So far we have three votes for yes >(rth, roland, me). I also vote for yes. p. From drepper@cygnus.com Fri Oct 8 11:24:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Fri, 08 Oct 1999 11:24:00 -0000 Subject: K&R and ISO References: <199910081802.OAA13779@qnx.com> Message-ID: "Alain Magloire" writes: > I'm a bit worry that next time I'll look, it will need not only an > ANSI C comp. but gcc. This is not a problem. ISO C is sufficently sane. I only don't like this K&R ballast. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From roland@frob.com Fri Oct 8 11:55:00 1999 From: roland@frob.com (Roland McGrath) Date: Fri, 08 Oct 1999 11:55:00 -0000 Subject: K&R and ISO References: <199910081803.OAA23712@qnx.com> Message-ID: <199910081855.OAA17983@frob.com> > I already did, when I brought the point to U.D., regex.[ch] is use in > many packages and will not compile without an ANSI C. I'm a bit worry that > next time I'll look, it will need not only an ANSI C comp. but gcc. There has been no suggestion to reduce the level of support for ANSI C compilers other than GCC, and I don't think that retaining portability to all ANSI C compliant compilers will be a problem in the future. I think that the libc team will happily continue to accept reports of nonportability to ANSI C compilers for these shared files as bonafide bugs. The remaining question is, is portability to non-ANSI C compilers is important to you at all, and if so, can you just you ansi2knr or protoize and be happy? From kettenis@wins.uva.nl Fri Oct 8 12:22:00 1999 From: kettenis@wins.uva.nl (Mark Kettenis) Date: Fri, 08 Oct 1999 12:22:00 -0000 Subject: K&R and ISO References: <199910081744.NAA17183@frob.com> Message-ID: <199910081927.VAA00223@delius.kettenis.local> From: Ulrich Drepper Date: 08 Oct 1999 10:55:21 -0700 I'll leave the two files glob.h and fnmatch.h alone until this is resolved. Other headers that are shared with other GNU packages are error.h, getopt.h, malloc.h, obstack.h and regex.h. As far as I can tell error.h, getopt.h and obstack.h don't use too much preprocessor madness to deal with K&R C. Wolfgang probably has something to say about malloc.h and maybe some other GNU developers besides Alain (Jim Meyering?) have some wishes about regex.h. Please give them some time (more than a few days) to react before you touch those files (if you plan to touch them at all). Anybody else want to comment. So far we have three votes for yes (rth, roland, me). I have no strong opinions. Several Hurd specific include files already use plain ISO C. However be prepared to get flamed about this issue. The whole ``glibc developers force people to use gcc'' flamewar will start all over again :-(. Mark From alain@qnx.com Fri Oct 8 12:28:00 1999 From: alain@qnx.com (Alain Magloire) Date: Fri, 08 Oct 1999 12:28:00 -0000 Subject: K&R and ISO References: <199910081855.OAA17983@frob.com> Message-ID: <199910081928.PAA08164@qnx.com> > > > I already did, when I brought the point to U.D., regex.[ch] is use in > > many packages and will not compile without an ANSI C. I'm a bit worry that > > next time I'll look, it will need not only an ANSI C comp. but gcc. > > There has been no suggestion to reduce the level of support for ANSI C > compilers other than GCC, and I don't think that retaining portability to > all ANSI C compliant compilers will be a problem in the future. I think > that the libc team will happily continue to accept reports of > nonportability to ANSI C compilers for these shared files as bonafide bugs. Thank you, for the clarification. > > The remaining question is, is portability to non-ANSI C compilers is > important to you at all, Yes, it is. > and if so, can you just you ansi2knr or protoize > and be happy? No. Certain semantics, will not pass like concatenation of strings at compile time. printf ("hello " "world\n"); The same for line split: I think ANSI C demands that one use a \ but some compilers will complain some will not, if you don't put it. printf ("hello world\n"); Obviously, I can not talk for all maintainers, but we do reuse code from glibc regex, glob, etc .. to name a few. Improvements in code such as regex is valuable for many *utils tools. If glibc decides to provide supports for only ANSI C, then it is time to bid farewell and exchange goodby kisses. My life will just be a tad more complex. -- au revoir, alain ---- Aussi haut que l'on soit assis, on n'est toujours assis que sur son cul !!! From roland@frob.com Fri Oct 8 12:36:00 1999 From: roland@frob.com (Roland McGrath) Date: Fri, 08 Oct 1999 12:36:00 -0000 Subject: K&R and ISO References: <199910081928.PAA08164@qnx.com> Message-ID: <199910081936.PAA18537@frob.com> > > and if so, can you just you ansi2knr or protoize > > and be happy? > > No. Certain semantics, will not pass like concatenation of strings > at compile time. > > printf ("hello " "world\n"); > > The same for line split: I think ANSI C demands that one use a \ > but some compilers will complain some will not, if you don't put it. > > printf ("hello > world\n"); Hmm. Ok. I do not speak for the libc maintainers, but still I don't think it will be a burden to avoid these few particular features for a few files (I assume they are not used now in any files that you care about). If ansi2knr/protoize can be made to flag these features and complain at you, then your normal testing of new libc code can readily flag these problems before they get into your packages. If you report these and supply the necessary fixes, I don't think the libc maintainers would have any trouble folding in those changes for the benefit of packages like yours. From alain@qnx.com Fri Oct 8 13:20:00 1999 From: alain@qnx.com (Alain Magloire) Date: Fri, 08 Oct 1999 13:20:00 -0000 Subject: K&R and ISO References: <199910081936.PAA18537@frob.com> Message-ID: <199910082020.QAA17109@qnx.com> > > > > and if so, can you just you ansi2knr or protoize > > > and be happy? > > > > No. Certain semantics, will not pass like concatenation of strings > > at compile time. > > > > printf ("hello " "world\n"); > > > > The same for line split: I think ANSI C demands that one use a \ > > but some compilers will complain some will not, if you don't put it. > > > > printf ("hello > > world\n"); > > Hmm. Ok. I do not speak for the libc maintainers, but still I don't think > it will be a burden to avoid these few particular features for a few files > (I assume they are not used now in any files that you care about). If > ansi2knr/protoize can be made to flag these features and complain at you, > then your normal testing of new libc code can readily flag these problems > before they get into your packages. If you report these and supply the > necessary fixes, I don't think the libc maintainers would have any trouble > folding in those changes for the benefit of packages like yours. The above was done, when I raised the flag, the answer was a flat "no". However, I did not submit a patch, doing this would revert to the old ways of having error msg, which exactly what the new code was trying to avoid. -- au revoir, alain ---- Aussi haut que l'on soit assis, on n'est toujours assis que sur son cul !!! From drepper@cygnus.com Fri Oct 8 13:57:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Fri, 08 Oct 1999 13:57:00 -0000 Subject: K&R and ISO References: <199910082020.QAA17109@qnx.com> Message-ID: "Alain Magloire" writes: > The above was done, when I raised the flag, the answer was a flat "no". I will not revert the patches to regex.c since they are optimizations which buy quite a lot in the glibc context. If there is a way to keep it usable without obsfutating the sources that's fine. Somebody should come up with a patch. I personally don't care a thing for K&R compilers. All you need is make, gcc, and perhaps binutils. With this you can get gcc running and you are set. If somebody does not want to do this because it's too much work they cannot expect the maintainer to spend time on their problems. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From aj@suse.de Sat Oct 9 08:40:00 1999 From: aj@suse.de (Andreas Jaeger) Date: Sat, 09 Oct 1999 08:40:00 -0000 Subject: K&R and ISO References: <199910081744.NAA17183@frob.com> Message-ID: >>>>> Ulrich Drepper writes: > Roland McGrath writes: >> I'd just like to give the maintainers a chance to explicitly respond >> to your proposal before just deciding for them. > I'll leave the two files glob.h and fnmatch.h alone until this is > resolved. > Anybody else want to comment. So far we have three votes for yes > (rth, roland, me). As long as the headers still work with other compilers (ISO C89) than gcc and the needs of other GNU packages are fulfilled, I vote for yes. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.rhein-neckar.de From drepper@cygnus.com Sat Oct 9 09:20:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Sat, 09 Oct 1999 09:20:00 -0000 Subject: server update Message-ID: sourceware.cygnus.com is now on a new, bigger, faster machine. This is what the downtime was about. At the same time Jason made the directory structure a bit more rational. This requires you to change the CVS/Root and CVS/Repository files. I had to do this: find -name Root | while read f; do mv $f $f.old; sed -e 's/:glibc/:sourceware/' -e 's|glibc/cvsfiles|cvs/glibc|' < $f.old > $f; done find -name Repository | while read f; do mv $f $f.old; sed 's|glibc/cvsfiles|cvs/glibc|' < $f.old > $f; done Your lines might be a bit different depending on the hostname you used. Please avoid checking out everything again. The old machine will sometime soon be transformed into anoncvs.cygnus.com. I.e., it will mirror the content of sourceware but is mean only for the anoncvs checkouts. The time difference will be insignificant but it will help the developers in the checkin process since the locks created by all the anonymous checkouts are not there anymore. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From roland@frob.com Sat Oct 9 09:43:00 1999 From: roland@frob.com (Roland McGrath) Date: Sat, 09 Oct 1999 09:43:00 -0000 Subject: server update References: Message-ID: <199910091643.MAA15437@frob.com> A slightly more general form that will probably work for you, this is what I use to relocate the repository for a CVS checkout: $ echo sourceware.cygnus.com:/cvs/glibc > root $ find libc -name Root -exec cp -f root {} \; $ find libc -name Repository -print | xargs sh foo and here is the script foo: root=`cat root` || exit; rep=${root#*:} for f; do case "$f" in /*|./*|../*) echo >&2 "$0 wants relative path from top of checkout"; exit 1;; esac echo > $f $rep/${f%/CVS/Repository} done From aj@suse.de Sat Oct 9 09:50:00 1999 From: aj@suse.de (Andreas Jaeger) Date: Sat, 09 Oct 1999 09:50:00 -0000 Subject: server update References: Message-ID: >>>>> Ulrich Drepper writes: > sourceware.cygnus.com is now on a new, bigger, faster machine. This > is what the downtime was about. > At the same time Jason made the directory structure a bit more > rational. This requires you to change the CVS/Root and CVS/Repository > files. I had to do this: > find -name Root | while read f; do mv $f $f.old; sed -e 's/:glibc/:sourceware/' -e 's|glibc/cvsfiles|cvs/glibc|' < $f.old > $f; done > find -name Repository | while read f; do mv $f $f.old; sed 's|glibc/cvsfiles|cvs/glibc|' < $f.old > $f; done > Your lines might be a bit different depending on the hostname you > used. Please avoid checking out everything again. > The old machine will sometime soon be transformed into > anoncvs.cygnus.com. I.e., it will mirror the content of sourceware > but is mean only for the anoncvs checkouts. The time difference will > be insignificant but it will help the developers in the checkin > process since the locks created by all the anonymous checkouts are not > there anymore. Could you please explain how Root and Repository should look now? If I use the anoncvs access, I should probably switch to anoncvs, shouldn't I? I currently have which might already be the correct setup: $ cat CVS/Root :pserver:anoncvs@anoncvs.cygnus.com:/cvs/glibc $ cat CVS/Repository /cvs/glibc/libc Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.rhein-neckar.de From roland@frob.com Sat Oct 9 09:53:00 1999 From: roland@frob.com (Roland McGrath) Date: Sat, 09 Oct 1999 09:53:00 -0000 Subject: server update References: Message-ID: <199910091653.MAA15991@frob.com> > Could you please explain how Root and Repository should look now? If > I use the anoncvs access, I should probably switch to anoncvs, > shouldn't I? Yes, though at the moment anoncvs is still an alias for sourceware. > I currently have which might already be the correct setup: > $ cat CVS/Root > :pserver:anoncvs@anoncvs.cygnus.com:/cvs/glibc > $ cat CVS/Repository > /cvs/glibc/libc That is the correct setup for anoncvs. For non-anonymous cvs, Root should be: sourcware.cygnus.com:/cvs/glibc or user@sourceware.cygnus.com or :rsh:user@sourceware.cygnus.com or whatever, and CVS/Repository is the same. From drepper@cygnus.com Sat Oct 9 14:30:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Sat, 09 Oct 1999 14:30:00 -0000 Subject: first bunch of header changes Message-ID: While the CVS archive was down yesterday I made the first changes to the headers. I think I've convered all generic headers and some more. If you stumble accross cases I left out (there are definitely several) just fix it. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From alain@qnx.com Sun Oct 10 10:22:00 1999 From: alain@qnx.com (Alain Magloire) Date: Sun, 10 Oct 1999 10:22:00 -0000 Subject: K&R and ISO References: Message-ID: <199910101722.NAA26002@qnx.com> Bonjour > "Alain Magloire" writes: > > > The above was done, when I raised the flag, the answer was a flat "no". > > I will not revert the patches to regex.c since they are optimizations > which buy quite a lot in the glibc context. > If there is a way to keep > it usable without obsfutating the sources that's fine. Somebody > should come up with a patch. No, this is a loosing strategy, it does not scale. If you choose to walk this path and use the full ANSI C semantics then be it. > I personally don't care a thing for K&R > compilers. All you need is make, gcc, and perhaps binutils. With > this you can get gcc running and you are set. If somebody does not > want to do this because it's too much work they cannot expect the > maintainer to spend time on their problems. K&R is dead! The king is dead! Long Live the King! Epitaphe for K&R : ... Surrender I? Parley? No, never! You too, Folly, --you? I know that you will lay me low at last; Let be! Yet I fall fighting, fighting still! You strip from me the laurel and the rose! Take all! Despite you there is yet one thing I hold against you all, and when, tonight, I enter Christ's fair courts, and, lowly bowed, Sweep with doffed casque the heaven's threshold blue, One thing is left, that, void of stain or smutch, I bear away despite you. ... My panache. [Cyrano De Bergerac, --Rostand] Sortie, rideau, Ovation de la foule. -- au revoir, alain ---- Aussi haut que l'on soit assis, on n'est toujours assis que sur son cul !!! From drepper@cygnus.com Mon Oct 11 14:47:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Mon, 11 Oct 1999 14:47:00 -0000 Subject: A patch for libresolv References: <19991006012700.3C0933FC1@valinux.com> Message-ID: hjl@valinux.com (H.J. Lu) writes: > There are many options in libresolve. However, there are no codes to > set them. Here is a patch to handle options for libresolve. Where is the existing practice for this? We cannot simply invent this because at least I don't understand the code completely. Just a brief look already showed a problem. The RES_IGNTC flag is used in the bind 8 code internally (res_sendsigned.c). It is obviously not meant to be set by the user. Probably this is correct for the rest as well. I'll compare the res_init code in glibc and in bind 8 and make whatever changes this suggests. But simply extending the option format is not correct. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From hjl@valinux.com Mon Oct 11 15:00:00 1999 From: hjl@valinux.com (H.J. Lu) Date: Mon, 11 Oct 1999 15:00:00 -0000 Subject: A patch for libresolv References: Message-ID: <19991011215952.E1D603FC1@valinux.com> > > hjl@valinux.com (H.J. Lu) writes: > > > There are many options in libresolve. However, there are no codes to > > set them. Here is a patch to handle options for libresolve. > > Where is the existing practice for this? We cannot simply invent this > because at least I don't understand the code completely. > > Just a brief look already showed a problem. The RES_IGNTC flag is > used in the bind 8 code internally (res_sendsigned.c). It is Then take it out from my patch. > obviously not meant to be set by the user. Probably this is correct > for the rest as well. > > I'll compare the res_init code in glibc and in bind 8 and make > whatever changes this suggests. But simply extending the option > format is not correct. > There are many RES_XXXXX macros but they are not settable by users. I have a need to set RES_INSECURE1/RES_INSECURE2. I don't want to recompile glibc to do it. -- H.J. Lu (hjl@gnu.org) From drepper@cygnus.com Mon Oct 11 15:07:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Mon, 11 Oct 1999 15:07:00 -0000 Subject: A patch for libresolv References: <19991011215952.E1D603FC1@valinux.com> Message-ID: hjl@valinux.com (H.J. Lu) writes: > Then take it out from my patch. So I go through your patch and correct the problems? There is something wrong with this... > There are many RES_XXXXX macros but they are not settable by users. > I have a need to set RES_INSECURE1/RES_INSECURE2. I don't want to > recompile glibc to do it. Identify exactly which flags you need and I will try to find out how they are supposed to be used. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From hjl@valinux.com Mon Oct 11 15:11:00 1999 From: hjl@valinux.com (H.J. Lu) Date: Mon, 11 Oct 1999 15:11:00 -0000 Subject: A patch for libresolv References: Message-ID: <19991011221115.0170F3FC1@valinux.com> > > > There are many RES_XXXXX macros but they are not settable by users. > > I have a need to set RES_INSECURE1/RES_INSECURE2. I don't want to > > recompile glibc to do it. > > Identify exactly which flags you need and I will try to find out how > they are supposed to be used. > I need to be able to set RES_INSECURE1/RES_INSECURE2 in /etc/resolv.conf and via an environment variable. Thanks. -- H.J. Lu (hjl@gnu.org) From geoffk@ozemail.com.au Mon Oct 11 17:20:00 1999 From: geoffk@ozemail.com.au (Geoff Keating) Date: Mon, 11 Oct 1999 17:20:00 -0000 Subject: A patch for libresolv References: <19991011221115.0170F3FC1@valinux.com> Message-ID: <199910120019.KAA00686@gluttony.geoffk.wattle.id.au> > Date: Mon, 11 Oct 1999 15:11:15 -0700 (PDT) > Cc: libc-hacker@sourceware.cygnus.com (GNU C Library) > From: hjl@valinux.com (H.J. Lu) > I need to be able to set RES_INSECURE1/RES_INSECURE2 in > /etc/resolv.conf and via an environment variable. You've considered the security issues involved in this, and you're sure it's OK to put it in everyone's glibc? -- Geoffrey Keating From hjl@valinux.com Mon Oct 11 17:26:00 1999 From: hjl@valinux.com (H.J. Lu) Date: Mon, 11 Oct 1999 17:26:00 -0000 Subject: A patch for libresolv References: <199910120019.KAA00686@gluttony.geoffk.wattle.id.au> Message-ID: <19991012002642.323523FC1@valinux.com> > > > Date: Mon, 11 Oct 1999 15:11:15 -0700 (PDT) > > Cc: libc-hacker@sourceware.cygnus.com (GNU C Library) > > From: hjl@valinux.com (H.J. Lu) > > > I need to be able to set RES_INSECURE1/RES_INSECURE2 in > > /etc/resolv.conf and via an environment variable. > > You've considered the security issues involved in this, and you're > sure it's OK to put it in everyone's glibc? > They are off by default. You have to turn them on by hand in /etc/resolv.conf or via an environment variable. They are a few sites on the Internet which rerquires them. I'd like to be able to do # RES_OPTS=insecure2 foobar What is the problem with that? Are you suggesting we should check # rm -rf /dev now? -- H.J. Lu (hjl@gnu.org) From geoffk@ozemail.com.au Mon Oct 11 17:37:00 1999 From: geoffk@ozemail.com.au (Geoff Keating) Date: Mon, 11 Oct 1999 17:37:00 -0000 Subject: A patch for libresolv References: <19991012002642.323523FC1@valinux.com> Message-ID: <199910120036.KAA00744@gluttony.geoffk.wattle.id.au> > Date: Mon, 11 Oct 1999 17:26:42 -0700 (PDT) > Cc: libc-hacker@sourceware.cygnus.com (GNU C Library) > From: hjl@valinux.com (H.J. Lu) > They are off by default. You have to turn them on by hand in > /etc/resolv.conf or via an environment variable. They are a few > sites on the Internet which rerquires them. I'd like to be able > to do > > # RES_OPTS=insecure2 foobar > > What is the problem with that? Are you suggesting we should check > > # rm -rf /dev > > now? So your proposed patch checks for getuid() == 0? -- Geoffrey Keating From hjl@valinux.com Mon Oct 11 17:56:00 1999 From: hjl@valinux.com (H.J. Lu) Date: Mon, 11 Oct 1999 17:56:00 -0000 Subject: A patch for libresolv References: <199910120036.KAA00744@gluttony.geoffk.wattle.id.au> Message-ID: <19991012005611.C92F03FC1@valinux.com> > > > Date: Mon, 11 Oct 1999 17:26:42 -0700 (PDT) > > Cc: libc-hacker@sourceware.cygnus.com (GNU C Library) > > From: hjl@valinux.com (H.J. Lu) > > > They are off by default. You have to turn them on by hand in > > /etc/resolv.conf or via an environment variable. They are a few > > sites on the Internet which rerquires them. I'd like to be able > > to do > > > > # RES_OPTS=insecure2 foobar > > > > What is the problem with that? Are you suggesting we should check > > > > # rm -rf /dev > > > > now? > > So your proposed patch checks for getuid() == 0? > RES_OPTIONS is called with __secure_getenv so that it is not a problem. However, all those options, including RES_IGNTC, are set/cleared in dig/host/nslookup in bind 8. Right now my patch will only affect root if those options are turned on in /etc/resolv.conf. If anyone can change /etc/resolv.conf on your machine, my patch is the last thing you want to worry about. -- H.J. Lu (hjl@gnu.org) From aj@suse.de Mon Oct 11 23:43:00 1999 From: aj@suse.de (Andreas Jaeger) Date: Mon, 11 Oct 1999 23:43:00 -0000 Subject: ftp.gnu.org && crypt && linuxthreads Message-ID: <199910111607.SAA16653@zermelo.suse.de> Since we get every week a number of reports that glibc 2.1.2 doesn't work with crypt 2.0.6, I'd like (a suggestion made by Thorsten) to get crypt 2.0.6 removed from ftp.gnu.org. crypt will then only live on ftp.gwdg.de. Otherwise we should update README.crypt to point to gwdg. Ulrich, if you would do this, I would update the documentation to reflect that crypt is only available from gwdg. Another problem is that ftp.gnu.org has only glibc-2.1.2 but no linuxthreads add-on. Could you upload the actual version? Thanks, Andreas -- Andreas Jaeger aj@suse.de aj@arthur.rhein-neckar.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From drepper@cygnus.com Mon Oct 11 23:51:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Mon, 11 Oct 1999 23:51:00 -0000 Subject: ftp.gnu.org && crypt && linuxthreads References: <199910111607.SAA16653@zermelo.suse.de> Message-ID: Andreas Jaeger writes: > Ulrich, if you would do this, I would update the documentation to > reflect that crypt is only available from gwdg. I have no access to this machine anymore after they switched to use Kerberos without taking those of us who use Kerberos for other domains into account. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From aj@suse.de Tue Oct 12 06:48:00 1999 From: aj@suse.de (Andreas Jaeger) Date: Tue, 12 Oct 1999 06:48:00 -0000 Subject: on alpha Message-ID: <199910121348.PAA23013@zermelo.suse.de> Trying to compile the current glibc 2.2 on alpha, I noticed that isn't in synch with the other architectures. Appended is a patch to add the missing parts. I'd appreciate if somebody would check if this is ok. Andreas 1999-10-12 Andreas Jaeger * sysdeps/unix/sysv/linux/alpha/sys/ucontext.h: Synch with other architectures: Add NGREGS, greg_t, gregset_t, _fpstate. Index: sysdeps/unix/sysv/linux/alpha/sys/ucontext.h =================================================================== RCS file: /cvs/glibc/libc/sysdeps/unix/sysv/linux/alpha/sys/ucontext.h,v retrieving revision 1.2 diff -u -u -r1.2 ucontext.h --- ucontext.h 1999/03/01 07:20:35 1.2 +++ ucontext.h 1999/10/12 13:46:00 @@ -22,7 +22,21 @@ #include #include +/* We need the signal context definitions even if they are not used + included in . */ #include + +/* Type for general register. */ +typedef long int greg_t; + +/* Number of general registers. */ +#define NGREG 33 + +/* Container for all general registers. */ +typedef greg_t gregset_t[NGREG]; + +/* Structure to describe FPU registers. */ +typedef struct _fpstate *fpregset_t; /* A machine context is exactly a sigcontext. */ typedef struct sigcontext mcontext_t; From drepper@cygnus.com Tue Oct 12 08:52:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Tue, 12 Oct 1999 08:52:00 -0000 Subject: on alpha References: <199910121348.PAA23013@zermelo.suse.de> Message-ID: Andreas Jaeger writes: > Trying to compile the current glibc 2.2 on alpha, I noticed that > isn't in synch with the other architectures. > Appended is a patch to add the missing parts. I'd appreciate if > somebody would check if this is ok. I've checked in a little bit different patch which is in sync with the definitions in asm/elf.h. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From hjl@lucon.org Tue Oct 12 09:45:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Tue, 12 Oct 1999 09:45:00 -0000 Subject: binutils 2.9.5.0.16 is released. Message-ID: <19991012164515.481E41B493@ocean.lucon.org> This is the beta release of binutils 2.9.5.0.16 for Linux, which is based on binutils 1999 1012 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.9.5.0.16 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 ar melf_linux26} %{!mapcs-26:-m armelf_linux} -p 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.9.5.0.16.tar.bz2. Source code. 2. binutils-2.9.5.0.14-2.9.5.0.16.diff.bz2. Patch against the previous beta source code. 3. binutils-2.9.5.0.16-1.src.rpm. Source RPM. 4. binutils-2.9.5.0.16-1.i386.rpm. X86 inary RPM for RedHat 6.1. 5. binutils-2.9.5.0.16-1.alpha.rpm. Alpha binary RPM for RedHat 6.1. There are no gz versions of tar and diff files. The primary ftp sites for the beta Linux binutils are: 1. ftp://ftp.valinux.com/pub/support/hjl/binutils Thanks. H.J. Lu hjl@lucon.org 10/12/99 From aj@suse.de Mon Oct 18 06:27:00 1999 From: aj@suse.de (Andreas Jaeger) Date: Mon, 18 Oct 1999 06:27:00 -0000 Subject: libm-test rewrite Message-ID: I've put on ftp.suse.com/pub/people/aj/libm-test.diff.gz [1] a patch for glibc 2.2 which adds the rewritten libm-tests. The only problems with libm-tests are: - I forgot to rm math/libm-tests.c - please do so before testing. - The make rules aren't correct. The generated libm-test.c is not build before generating the dependencies. Could anybody fix this, please? - We need system specific libm-test-ulps files which contain the deltas (in ulps) for each function. I only provided an empty sysdeps/generic/libm-test-ulps as fallback. You can create a machine readable file with e.g.: test-double -u (-u outputs an unsorted file, cat all those files together) and run: gen-libm-test.pl -u allULPs -n Since libm-test-ulps can be generated automatically, just a few notes. The file contains lines for single tests, like: Test "cos (pi/2) == 0": float: 1 and lines for maximal errors of single functions, like: Function "yn": idouble: 6.0000 The keywords are float, ifloat, double, idouble, ldouble and ildouble (the prefix i stands for inline). You can also specify known failures, e.g.: Test "cos (pi/2) == 0": float: 1 float: fail Uli, I've added a ChangeLog. Please add the patch to glibc 2.2. Andreas Footnotes: [1] It might have been a wee bit too large for the mailing list. If you have problems getting, just ask me for a copy per email. -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.rhein-neckar.de From drepper@cygnus.com Mon Oct 18 23:33:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Mon, 18 Oct 1999 23:33:00 -0000 Subject: libm-test rewrite References: Message-ID: Andreas Jaeger writes: > I've put on ftp.suse.com/pub/people/aj/libm-test.diff.gz [1] a patch for > glibc 2.2 which adds the rewritten libm-tests. Many thanks to Andreas. Good job. I feel much better about this form for the test suite. I haven't given it a full run yet but I managed to create the ULPs file for x86. There are only three more things to do as far as I'm concerned: - write documentation on how to generate initial error files for a new architecture - add a mode where the test program complains even if the error is smaller than the one from the error file. This should be enabled for all development and test releases. - somehow generate from the error files a table where for each function and each architecture the maximal error is listed. I've mentioned before that this is a requirement for a Unix library. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From aj@suse.de Mon Oct 18 23:48:00 1999 From: aj@suse.de (Andreas Jaeger) Date: Mon, 18 Oct 1999 23:48:00 -0000 Subject: libm-test rewrite References: Message-ID: >>>>> Ulrich Drepper writes: Uli> Andreas Jaeger writes: >> I've put on ftp.suse.com/pub/people/aj/libm-test.diff.gz [1] a patch for >> glibc 2.2 which adds the rewritten libm-tests. Uli> Many thanks to Andreas. Good job. I feel much better about this form Uli> for the test suite. I haven't given it a full run yet but I managed Uli> to create the ULPs file for x86. Glad to hear. Btw. I don't think the make rules are fixed yet. Just rm all test files from math and you notice while generating the *.d files: test-float.c:34: libm-test.c: No such file or directory Uli> There are only three more things to do as far as I'm concerned: Uli> - write documentation on how to generate initial error files for a new Uli> architecture Ok, I'll do that. Uli> - add a mode where the test program complains even if the error is smaller Uli> than the one from the error file. This should be enabled for all Uli> development and test releases. Should we even complain about an error of 1 ulp? Uli> - somehow generate from the error files a table where for each function Uli> and each architecture the maximal error is listed. I've mentioned Uli> before that this is a requirement for a Unix library. Do you want to have one file which contains all the information? I guess I can come up with something. There's only one problem: The tests are pointwise and not exhaustive - the maximum error given is a minimal maximum error. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.rhein-neckar.de From aj@suse.de Tue Oct 19 09:27:00 1999 From: aj@suse.de (Andreas Jaeger) Date: Tue, 19 Oct 1999 09:27:00 -0000 Subject: README-glibc-crypt on ftp.gnu.org Message-ID: I've updated the file README-glibc-crypt on ftp.gnu.org to point to ftp.gwdg.de. The text is now: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The GNU C library now includes Michael Glad's Ultra Fast Crypt, which provides the Unix `crypt' function, plus some other entry points. Because of the United States export restriction on DES implementations, we are distributing this code separately from the rest of the C library. There is an extra distribution tar file just for crypt; it is called `glibc-crypt-2.1.1.tar.gz' (or whatever the last version is). You can just unpack the crypt distribution along with the rest of the C library and build; you can also build the library without getting crypt. Users outside the USA can get the crypt distribution via anonymous FTP from ftp://ftp.gwdg.de/pub/linux/glibc [134.76.11.100], or another archive site outside the USA. Archive maintainers are encouraged to copy this distribution to their archives outside the USA. Please get it from ftp.gwdg.de; transferring this distribution from ftp.gnu.org (or any other site in the USA) to a site outside the USA is in violation of US export laws. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If you like to have anything changed, please tell me. Please note that current versions of crypt (2.1 and newer) are not on ftp.gnu.org. Are there any objections to remove all crypt 2.0.x versions also? I'm in favor of removing it since I see every odd day a report that crypt 2.0.6 doesn't work with glibc 2.1.2 :-(. I've also put the current linuxthreads add-on on ftp.gnu.org. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.rhein-neckar.de From drepper@cygnus.com Tue Oct 19 19:42:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Tue, 19 Oct 1999 19:42:00 -0000 Subject: new math test suite Message-ID: Those of you who tried to compile glibc today on x86 will have noticed that the tests fail. This is actually a bug in the script generating the error files. It currently seems not to handle the complex functions correctly. Andreas, could you look at this? Otherwise please tell me. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From aj@suse.de Tue Oct 19 22:32:00 1999 From: aj@suse.de (Andreas Jaeger) Date: Tue, 19 Oct 1999 22:32:00 -0000 Subject: new math test suite References: Message-ID: >>>>> Ulrich Drepper writes: Uli> Those of you who tried to compile glibc today on x86 will have noticed Uli> that the tests fail. This is actually a bug in the script generating Uli> the error files. It currently seems not to handle the complex Uli> functions correctly. Uli> Andreas, could you look at this? Otherwise please tell me. I'll have a look. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.rhein-neckar.de From jk@espy.org Fri Oct 22 00:10:00 1999 From: jk@espy.org (Joel Klecker) Date: Fri, 22 Oct 1999 00:10:00 -0000 Subject: Current glibc-2-1-branch linuxthreads/signals.c doesn't compile Message-ID: Without --with-headers, ends up being gotten from the system headers, which is perhaps why this wasn't caught before. linuxthreads/signals.c doesn't appear to need any of the functions prototyped in , so I believe this is the correct fix. 1999-10-22 Joel Klecker * signals.c: Include instead of . Index: linuxthreads/signals.c =================================================================== RCS file: /cvs/glibc/libc/linuxthreads/signals.c,v retrieving revision 1.8.2.3 diff -u -r1.8.2.3 signals.c --- linuxthreads/signals.c 1999/09/25 16:59:50 1.8.2.3 +++ linuxthreads/signals.c 1999/10/22 06:54:36 @@ -19,7 +19,7 @@ #include "pthread.h" #include "internals.h" #include "spinlock.h" -#include +#include #include int pthread_sigmask(int how, const sigset_t * newmask, sigset_t * oldmask) -- Joel Klecker (aka Espy) Debian Package Maintainer for the GNU C Library. From drepper@cygnus.com Fri Oct 22 20:30:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Fri, 22 Oct 1999 20:30:00 -0000 Subject: no connection Message-ID: Just a warning: the internal network at Cygnus will be updated this weekend. This means I wil not be able to read or send email nor get to the sourceware machine. sourceware should be up most of the time but who knows. Also our mail server should be running but maybe you can keep your important messages for me until late Sunday (Pacific time) so that we can be sure they reach me. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From drepper@cygnus.com Sat Oct 23 21:05:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Sat, 23 Oct 1999 21:05:00 -0000 Subject: Current glibc-2-1-branch linuxthreads/signals.c doesn't compile References: Message-ID: Joel Klecker writes: > linuxthreads/signals.c doesn't appear to need any of the functions > prototyped in , so I believe this is the correct fix. I prefer to have the real heade included and so I make the same change as for 2.2 (where I fixed this already some time ago). -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From drepper@cygnus.com Sun Oct 24 15:05:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Sun, 24 Oct 1999 15:05:00 -0000 Subject: math test suite Message-ID: Hi, Just a short note that I have now fixed all the problems with the x86 math testing. It should work again. This also means I'd love to get appropriate definitions of the delta file for other architectures. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From scottb@netwinder.org Sun Oct 24 19:24:00 1999 From: scottb@netwinder.org (Scott Bambrough) Date: Sun, 24 Oct 1999 19:24:00 -0000 Subject: math test suite References: Message-ID: <012001bf1e91$12d67900$LocalHost@fiji> > From: Ulrich Drepper > Just a short note that I have now fixed all the problems with the x86 > math testing. It should work again. This also means I'd love to get > appropriate definitions of the delta file for other architectures. I tried building the mainline on the NetWinder late last week. Most of the math test failed from a cursory glance at the logs. The NWFPE also spat out an extraordinary number of floating point exceptions. I haven't investigated the cause yet or determined if they were valid. More later this week after I have a chance to investigate. Scott From aj@suse.de Sun Oct 24 23:19:00 1999 From: aj@suse.de (Andreas Jaeger) Date: Sun, 24 Oct 1999 23:19:00 -0000 Subject: math test suite References: <012001bf1e91$12d67900$LocalHost@fiji> Message-ID: >>>>> Scott Bambrough writes: >> From: Ulrich Drepper >> Just a short note that I have now fixed all the problems with the x86 >> math testing. It should work again. This also means I'd love to get >> appropriate definitions of the delta file for other architectures. Scott> I tried building the mainline on the NetWinder late last week. Most of the Scott> math test failed from a cursory glance at the logs. The NWFPE also spat out Scott> an extraordinary number of floating point exceptions. I haven't Scott> investigated the cause yet or determined if they were valid. They should be valid. I've coded everything with a ISO C9x draft and the IEEE 754 standard besides me. But if you've got any doubts or questions, just ask me. Scott> More later this week after I have a chance to investigate. Andreas -- Andreas Jaeger SuSE Linux Labs aj@suse.de private aj@arthur.rhein-neckar.de From aj@suse.de Mon Oct 25 01:23:00 1999 From: aj@suse.de (Andreas Jaeger) Date: Mon, 25 Oct 1999 01:23:00 -0000 Subject: README-glibc-crypt on ftp.gnu.org References: Message-ID: >>>>> Andreas Jaeger writes: > Are there any objections to remove all crypt 2.0.x versions also? I'm > in favor of removing it since I see every odd day a report that crypt > 2.0.6 doesn't work with glibc 2.1.2 :-(. Last call for votes;-) I didn't get any responses so far and will remove tomorrow the crypt files if I don't get any objections. Andreas -- Andreas Jaeger SuSE Linux Labs aj@suse.de private aj@arthur.rhein-neckar.de From aj@suse.de Mon Oct 25 03:25:00 1999 From: aj@suse.de (Andreas Jaeger) Date: Mon, 25 Oct 1999 03:25:00 -0000 Subject: README.libm-test Message-ID: I'm appending a README for the libm-test tests. Please note that for using the option -n to gen-libm-test.pl as described in the README, you need a separate patch which I've send already to Uli for inclusion. Uli, please add this to glibc. Andreas 1999-10-25 Andreas Jaeger * math/README.libm-test: New file, documents libm-test.inc. README for libm-test math test suite ==================================== The libm-test math test suite tests a number of function points of math functions in the GNU C library. The following sections contain a brief overview. Please note that the test drivers and the perl script "gen-libm-test.pl" have some options. A full list of options is available with --help (for the test drivers) and -h for "gen-libm-test.pl". What is tested? =============== The tests just evaluate the functions at specified points and compare the results with precomputed values and the requirements of the ISO C99 standard. Besides testing the special values mandated by IEEE 754 (infinities, NaNs and minus zero), some more or less random values are tested. Files that are part of libm-test ================================ The main file is "libm-test.inc". It is platform and floating point format independend. The file must be preprocessed by the Perl script "gen-libm-test.pl". The results are "libm-test.c" and a file "libm-test-ulps.h" with platform specific deltas. The test drivers test-double.c, test-float.c, test-ldouble.c test the normal double, float and long double implementation of libm. The test drivers with an i in it (test-idouble.c, test-ifloat.c, test-ildoubl.c) test the corresponding inline functions (where available - otherwise they also test the real functions in libm). "gen-libm-test.pl" needs a platform specific files with ulps. The file is called "libm-test-ulps" and lives in platform specific sysdep directory. How can I generate "libm-test-ulps"? ==================================== The test drivers have an option "-u" to output an unsorted list of all epsilons that the functions have. The output can be read in directly but it's better to pretty print it first. "gen-libm-test.pl" has an option to generate a pretty-printed and sorted new ulps file from the output of the test drivers. To generate a new "libm-test-ulps" file, you can execute for example: test-double -u --ignore-max-ulp=yes This generates a file "ULPs" with all double ulps in it, ignoring any previous calculated ulps. Now move this away, e.g. "mv ULPs allULPs" and generate the ulps for all other formats and concat all ulp files together (e.g. "cat ULPs >> allULPs"). As final step run "gen-libm-test.pl" with the file as input and ask to generate a pretty printed output in the file "NewUlps": gen-libm-test.pl -u allULPs -n Now you can rename "NewUlps" to "libm-test-ulps" and move it into sysdeps. Contents of libm-test-ulps ========================== Since libm-test-ulps can be generated automatically, just a few notes. The file contains lines for single tests, like: Test "cos (pi/2) == 0": float: 1 and lines for maximal errors of single functions, like: Function "yn": idouble: 6.0000 The keywords are float, ifloat, double, idouble, ldouble and ildouble (the prefix i stands for inline). You can also specify known failures, e.g.: Test "cos (pi/2) == 0": float: 1 float: fail Adding tests to libm-test.inc ============================= The tests are evalued by a set of special test macros. The macros start with "TEST_" followed by a specifiction the input values, an underscore and a specifiction of the output values. As an example, the test macro for a function with input of type FLOAT (FLOAT is either float, double, long double) and output of type FLOAT is "TEST_f_f". The macro's parameter are the name of the function, the input parameter, output parameter and optionally one exeception parameter. The accepted parameter types are: - "f" for FLOAT - "b" for boolean - just tests if the output parameter evaluates to 0 or 1 (only for output). - "c" for complex. This parameter needs two values, first the real, then the imaginary part. - "i" for int. - "l" for long int. - "L" for long long int. - "F" for the address of a FLOAT (only as input parameter) - "I" for the address of an int (only as input parameter) Some functions need special handling. For example gamma sets the global variable signgam and frexp takes an argument to &int. This special treatmeant is coded in "gen-libm-test.pl" and used while parsing "libm-test.inc". ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Andreas Jaeger aj@suse.de -- Andreas Jaeger SuSE Linux Labs aj@suse.de private aj@arthur.rhein-neckar.de From drepper@cygnus.com Mon Oct 25 13:13:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Mon, 25 Oct 1999 13:13:00 -0000 Subject: README.libm-test References: Message-ID: Andreas Jaeger writes: > Uli, please add this to glibc. Done. Thanks for writing this up so quickly. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From hjl@lucon.org Thu Oct 28 08:43:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Thu, 28 Oct 1999 08:43:00 -0000 Subject: Problem with __malloc_hooks :-( References: Message-ID: <19991028154315.11DF51B493@ocean.lucon.org> > > > The following program shows a problem I noticed with a current glibc > 2.1.3 CVS versions and XEmacs [1]: > > #define _GNU_SOURCE > #include > #include > > int > main (int argc, char argv[]) > { > char *p; > > if (argc == 1) > { > __malloc_hook = NULL; > __realloc_hook = NULL; > __free_hook = NULL; > } > > p = malloc (1000); > printf ("%p\n", p); > return 0; > } > > Have a look at the output: > > gromit:/tmp:[0]$ ./malloc > (nil) > gromit:/tmp:[0]$ ./malloc 1 > 0x8049670 > > If __malloc_hook is NULL, malloc returns NULL. The problem is that > malloc internally uses __malloc_hook and the current CVS version > doesn't call malloc before main any more :-(. > > Wolfram, can you give me some feedback, please? > Ulrich, I have verified that my preinit patch works fine. It seems that my patch has more than one benefit. Maybe it should be considered instead of your patch to exit/atexit. -- H.J. Lu (hjl@gnu.org) From hjl@lucon.org Thu Oct 28 08:47:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Thu, 28 Oct 1999 08:47:00 -0000 Subject: Problem with __malloc_hooks :-( References: Message-ID: <19991028154700.D70A91B493@ocean.lucon.org> > > hjl@lucon.org (H.J. Lu) writes: > > > Have you tried my preinit patch? It is for the static libpthread bug > > which Ulrich fixed with a different approach. But it seems that my > > patch has other potential benefits :-). > > Of course this patch would change the behaviour but you cannot > honestly believe I would use it. I'm not yet sure at all whether > there is a real problem. If there is one it has to be fixed at the > source and not worked around by such a hack. > You can call it a hack if you want. The preinit issue is a real problem. It also happens to other people. I believe that is why DT_PREINIT_XXXX was invented. I belive glibc 2.1.x should support preinit in one form or the other. -- H.J. Lu (hjl@gnu.org) From drepper@cygnus.com Thu Oct 28 08:53:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Thu, 28 Oct 1999 08:53:00 -0000 Subject: Problem with __malloc_hooks :-( References: <19991028154700.D70A91B493@ocean.lucon.org> Message-ID: hjl@lucon.org (H.J. Lu) writes: > You can call it a hack if you want. The preinit issue is a real > problem. It also happens to other people. I believe that is why > DT_PREINIT_XXXX was invented. I belive glibc 2.1.x should support > preinit in one form or the other. Wait a minute. This are two completely different things. Supporting preinit is fine, but using it to fix a completely unrelated issue is not acceptable. Beside, glibc does not have to use the feature to support it. Especially since adding a preinit table to libc.so will not help at all since it is never used (except if libc.so is executed directly). -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From drepper@cygnus.com Fri Oct 29 10:17:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Fri, 29 Oct 1999 10:17:00 -0000 Subject: [PATCH] sparc linux ptrace.h References: <19991029131820.N525@mff.cuni.cz> Message-ID: Jakub Jelinek writes: > Repost of an older patch - Ulrich, could you please commit this in or do > you have objections against it? Looks fine but please include a ChageLog entry the next time. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From jakub@redhat.com Fri Oct 29 11:53:00 1999 From: jakub@redhat.com (Jakub Jelinek) Date: Fri, 29 Oct 1999 11:53:00 -0000 Subject: Assorted SPARC patches Message-ID: <19991029205532.S525@mff.cuni.cz> Hi! These are SPARC patches collected over time. 1999-10-29 Jakub Jelinek * stdlib/longlong.h: Avoid UDIV_TIME redefinition. * sysdeps/sparc/sparc32/dl-machine.h: Fix loading of SPARC v8plus libraries from statically linked programs. * sysdeps/unix/sysv/linux/sparc/bits/sigaction.h: POSIX 199309 fix for sigaction on SPARC. Patches by David S. Miller . * sysdeps/unix/sysv/linux/sparc/sys/ucontext.h: Declare gregset_t and other required structures and defines for SPARC 64bit ABI as well, not only 32bit ABI. --- ./stdlib/longlong.h.jj Mon Jun 21 16:58:27 1999 +++ ./stdlib/longlong.h Fri Oct 29 20:23:48 1999 @@ -1179,7 +1179,9 @@ extern USItype __udiv_qrnnd (); #define UDIV_TIME (3+7*32) /* 7 instructions/iteration. 32 iterations. */ #else extern USItype __udiv_qrnnd __P ((USItype *, USItype, USItype, USItype)); +#ifndef UDIV_TIME #define UDIV_TIME 140 +#endif /* UDIV_TIME */ #endif /* udiv_qrnnd */ #endif /* __sparc__ */ --- ./sysdeps/sparc/sparc32/dl-machine.h.jj Wed Jul 21 18:57:50 1999 +++ ./sysdeps/sparc/sparc32/dl-machine.h Fri Oct 29 20:25:54 1999 @@ -56,7 +56,7 @@ elf_machine_matches_host (Elf32_Half e_m weak_extern (_dl_hwcap_mask); hwcap = WEAKADDR(_dl_hwcap); - return hwcap && (*hwcap & _dl_hwcap_mask & HWCAP_SPARC_V9); + return ! hwcap || (*hwcap & _dl_hwcap_mask & HWCAP_SPARC_V9); } else return 0; --- ./sysdeps/unix/sysv/linux/sparc/bits/sigaction.h.jj Thu Oct 22 16:41:23 1998 +++ ./sysdeps/unix/sysv/linux/sparc/bits/sigaction.h Fri Oct 29 20:21:36 1999 @@ -1,5 +1,5 @@ /* The proper definitions for Linux/SPARC sigaction. - Copyright (C) 1996, 1997, 1998 Free Software Foundation, Inc. + Copyright (C) 1996, 1997, 1998, 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 @@ -24,8 +24,21 @@ /* Structure describing the action to be taken when a signal arrives. */ struct sigaction { - /* Signal handler. */ + /* Signal handler. */ +#ifdef __USE_POSIX199309 + union + { + /* Used if SA_SIGINFO is not set. */ + __sighandler_t sa_handler; + /* Used if SA_SIGINFO is set. */ + void (*sa_sigaction) (int, siginfo_t *, void *); + } + __sigaction_handler; +# define sa_handler __sigaction_handler.sa_handler +# define sa_sigaction __sigaction_handler.sa_sigaction +#else __sighandler_t sa_handler; +#endif /* Additional set of signals to be blocked. */ __sigset_t sa_mask; --- ./sysdeps/unix/sysv/linux/sparc/sys/ucontext.h.jj Tue May 25 13:52:25 1999 +++ ./sysdeps/unix/sysv/linux/sparc/sys/ucontext.h Fri Oct 29 20:12:08 1999 @@ -85,7 +85,7 @@ typedef struct ucontext { mcontext_t uc_mcontext; } ucontext_t; -#else /* __WORDSIZE == 32 */ +#endif /* __WORDISIZE == 64 */ /* * Location of the users' stored registers relative to R0. @@ -117,11 +117,24 @@ typedef struct ucontext { * treats arrays and structures as parameters. * * Note that NGREG is really (sizeof (struct regs) / sizeof (greg_t)), - * but that the ABI defines it absolutely to be 19. + * but that the ABI defines it absolutely to be 21 (resp. 19). */ -#define NGREG 19 +#if __WORDSIZE == 64 + +#define REG_ASI (19) +#define REG_FPRS (20) + +#define NGREG 21 +typedef long greg_t; + +#else /* __WORDSIZE == 32 */ + +#define NGREG 19 typedef int greg_t; + +#endif /* __WORDSIZE == 32 */ + typedef greg_t gregset_t[NGREG]; /* @@ -181,6 +194,24 @@ struct fq #define V7_FPU_FSR_TYPE unsigned #define V9_FPU_FSR_TYPE unsigned long long #define V9_FPU_FPRS_TYPE unsigned + +#if __WORDSIZE == 64 + +typedef struct fpu + { + union { /* FPU floating point regs */ + unsigned fpu_regs[32]; /* 32 singles */ + double fpu_dregs[16]; /* 32 doubles */ + long double fpu_qregs[16]; /* 16 quads */ + } fpu_fr; + struct fq *fpu_q; /* ptr to array of FQ entries */ + unsigned long fpu_fsr; /* FPU status register */ + unsigned char fpu_qcnt; /* # of entries in saved FQ */ + unsigned char fpu_q_entrysize; /* # of bytes per FQ entry */ + unsigned char fpu_en; /* flag signifying fpu in use */ + } fpregset_t; + +#else /* __WORDSIZE == 32 */ typedef struct fpu { Cheers, Jakub ___________________________________________________________________ Jakub Jelinek | jakub@redhat.com | http://sunsite.mff.cuni.cz/~jj Linux version 2.3.18 on a sparc64 machine (1343.49 BogoMips) ___________________________________________________________________ From drepper@cygnus.com Sat Oct 30 09:14:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Sat, 30 Oct 1999 09:14:00 -0000 Subject: ISO C99 references Message-ID: Just a quick comment: if you see ISO C9x somewhere in the sources start changing it to ISO C99. I'll start cleaning up the __USE_ISOC9X stuff sometime soon but there are are many other places. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------