From aj@suse.de Wed Nov 1 01:41:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Wed, 01 Nov 2000 01:41:00 -0000 Subject: make --without-cvs the default Message-ID: I propose to add the following patch to glibc. It makes --without-cvs the default and therefore life easier for all non-developers - and harder for those few developers that like to have *automatic* checkin (I also use without-cvs because I don't like automatic checkin of changes). Ok to commit (with a regenerated configure)? Andreas 2000-11-01 Andreas Jaeger * configure.in: Make --without-cvs the default. ============================================================ Index: configure.in --- configure.in 2000/10/15 06:43:13 1.292 +++ configure.in 2000/11/01 09:38:42 @@ -66,8 +66,8 @@ --with-elf if using the ELF object format, elf=$withval, elf=no) AC_ARG_WITH(cvs, dnl -[ --without-cvs if CVS should not be used], - with_cvs=$withval, with_cvs=yes) +[ --with-cvs if CVS should be used automatically], + with_cvs=$withval, with_cvs=no) AC_SUBST(with_cvs) AC_ARG_WITH(headers, dnl -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From drepper@redhat.com Wed Nov 1 08:13:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Wed, 01 Nov 2000 08:13:00 -0000 Subject: make --without-cvs the default References: Message-ID: Andreas Jaeger writes: > I propose to add the following patch to glibc. It makes --without-cvs > the default and therefore life easier for all non-developers - and > harder for those few developers that like to have *automatic* checkin > (I also use without-cvs because I don't like automatic checkin of > changes). > > Ok to commit (with a regenerated configure)? No, I don't want this. It just means that files are not correctly checked in. If somebody wants to use the CVS archive s/he better makes sure s/he knows what she does. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Wed Nov 1 23:16:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Wed, 01 Nov 2000 23:16:00 -0000 Subject: next (and final?) pre-release Message-ID: I hope to make the next and hopefully final pre-release tomorrow. If you have anything you are secretly working on or there is a problem I've missed let me know now. Thanks, -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Thu Nov 2 19:30:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Thu, 02 Nov 2000 19:30:00 -0000 Subject: announcement text Message-ID: Please review the text for the glibc 2.2 announcement. I've made it available at http://www.cygnus.com/~drepper/ANNOUNCE One thing I'd like to change is to provide a list of architecture and the recommended compilers (and tools if necessary). It would be good if you could provide this information. Any other feedback is welcome, too. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From aj@suse.de Thu Nov 2 22:56:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Thu, 02 Nov 2000 22:56:00 -0000 Subject: announcement text References: Message-ID: >>>>> Ulrich Drepper writes: > Please review the text for the glibc 2.2 announcement. I've made it > available at > http://www.cygnus.com/~drepper/ANNOUNCE > One thing I'd like to change is to provide a list of architecture and > the recommended compilers (and tools if necessary). It would be good For MIPS have a look at the FAQ. > if you could provide this information. Any other feedback is welcome, > too. Thanks Uli! One problem I see is that Gnats is still not working. The GNU machine has moved and Gnats has not been set up.:-( Shouldn't you mention that the locale format has changed and therefore the compiled files have to be recompiled. I suggest: The internal locale format has been changed. All locale information has to be regenerated with localedef, static programs using i18n features from earlier releases (including test releases) have to be recompiled to work properly. Go ahead with the release, Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From kettenis@wins.uva.nl Sat Nov 4 14:17:00 2000 From: kettenis@wins.uva.nl (Mark Kettenis) Date: Sat, 04 Nov 2000 14:17:00 -0000 Subject: announcement text References: Message-ID: <200011042219.eA4MJGf22208@soliton.wins.uva.nl> From: Ulrich Drepper Date: 02 Nov 2000 19:30:50 -0800 Please review the text for the glibc 2.2 announcement. I've made it available at http://www.cygnus.com/~drepper/ANNOUNCE One thing I'd like to change is to provide a list of architecture and the recommended compilers (and tools if necessary). It would be good if you could provide this information. Any other feedback is welcome, too. For the Hurd, I use GCC 2.95.2 and binutils 2.10. Note that I'm cross-compiling from Linux (the tools are actually the native Linux tools with modified specs, and some home-brewn scripts, but that shouldn't really matter). I'm not very confident that current mainline GCC will correctly compile glibc for the Hurd. On the Hurd we use even more GNU-isms than the rest of the ports, and the GCC folks have a tendency to break those from time to time. 2.1.97 seems to be fine for the Hurd. No build problems, and my Hurd system seems to be happy with it. By the way, I checked in some changes to make the Hurd's CLK_TCK handling similar to what you did for Linux. We already determined CLK_TCK at runtime for the Hurd since glibc 2.1.1, but in a slightly different way: # define CLK_TCK __libc_clk_tck() extern int __libc_clk_tck (void) __attribute__ ((__const__)); where __libc_clk_tck() is basically what's now the new __getclktck() function. Note the const attribute. Is it possible to make __sysconf() a const function too? Mark From drepper@redhat.com Sat Nov 4 14:52:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Sat, 04 Nov 2000 14:52:00 -0000 Subject: announcement text References: <200011042219.eA4MJGf22208@soliton.wins.uva.nl> Message-ID: Mark Kettenis writes: > I'm not very confident that current mainline GCC will correctly > compile glibc for the Hurd. On the Hurd we use even more GNU-isms > than the rest of the ports, and the GCC folks have a tendency to > break those from time to time. The mainline gcc is completely unable to compile glibc. Regardless of the architecture and OS. > where __libc_clk_tck() is basically what's now the new __getclktck() > function. Note the const attribute. Is it possible to make > __sysconf() a const function too? Probably, yes. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From hjl@valinux.com Mon Nov 6 12:19:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Mon, 06 Nov 2000 12:19:00 -0000 Subject: A symbol version patch for glibc 2.x compatibility Message-ID: <20001106121912.A23139@valinux.com> Glibc 2.2 is run-time compatible with glibc 2.0 and 2.1. But it is not enough for ISVs. Oracle 8i compiled against glibc 2.1 won't install under glibc 2.2 since the Oracle installation involves relinking. Also, all the libraries are compiled against glibc 2.1. It is not easy to develop Oracle 8i applications under glibc 2.2. I am working on providing the compile-time, link-time compatible option to glibc. The idea is or will include which will provide all the symbol information. Depending on the glibc version selected at the command line, will provide the correct __asm__ (".symver bar,bar@GLIBC_2.x.x"); for each versioned symbol. I modified as so that it will 1. Allow duplicated version name like .symver bar,bar@GLIBC_2.1 .symver bar,bar@GLIBC_2.1 2. Remove unneeded versioned symbols from the symbol table. The asm code like ---- .file "x.c" .version "01.01" .symver bar,bar@GLIBC_2.1 .symver bar,bar@GLIBC_2.1 .globl foobar foobar: .long foo .symver foobar,foobar@GLIBC_2.1 dummy: .long foo .symver foo,foo@GLIBC_2.1 ----- will get # gcc -c x.s # readelf -a x.o ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: REL (Relocatable file) Machine: Intel 80386 Version: 0x1 Entry point address: 0x0 Start of program headers: 0 (bytes into file) Start of section headers: 196 (bytes into file) Flags: 0x0 Size of this header: 52 (bytes) Size of program headers: 0 (bytes) Number of program headers: 0 Size of section headers: 40 (bytes) Number of section headers: 10 Section header string table index: 7 Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .text PROGBITS 00000000 000034 000008 00 AX 0 0 4 [ 2] .rel.text REL 00000000 000340 000010 08 8 1 4 [ 3] .data PROGBITS 00000000 00003c 000000 00 WA 0 0 4 [ 4] .bss NOBITS 00000000 00003c 000000 00 WA 0 0 4 [ 5] .note NOTE 00000000 00003c 000014 00 0 0 1 [ 6] .comment PROGBITS 00000000 000050 00002e 00 0 0 1 [ 7] .shstrtab STRTAB 00000000 00007e 000045 00 0 0 1 [ 8] .symtab SYMTAB 00000000 000254 0000b0 10 9 8 4 [ 9] .strtab STRTAB 00000000 000304 00003a 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), O (extra OS processing required) o (os specific), p (processor specific) x (unknown) There are no program headers in this file. There is no dynamic segment in this file. Relocation section '.rel.text' at offset 0x340 contains 2 entries: Offset Info Type Symbol's Value Symbol's Name 00000000 00901 R_386_32 00000000 foo@GLIBC_2.1 00000004 00901 R_386_32 00000000 foo@GLIBC_2.1 Symbol table '.symtab' contains 11 entries: Num: Value Size Type Bind Vis Ndx Name 0: 00000000 0 NOTYPE LOCAL DEFAULT UND 1: 00000000 0 FILE LOCAL DEFAULT ABS x.c 2: 00000000 0 SECTION LOCAL DEFAULT 1 3: 00000000 0 SECTION LOCAL DEFAULT 3 4: 00000000 0 SECTION LOCAL DEFAULT 4 5: 00000004 0 NOTYPE LOCAL DEFAULT 1 gcc2_compiled. 6: 00000000 0 SECTION LOCAL DEFAULT 5 7: 00000000 0 SECTION LOCAL DEFAULT 6 8: 00000000 0 NOTYPE GLOBAL DEFAULT 1 foobar 9: 00000000 0 NOTYPE GLOBAL DEFAULT UND foo@GLIBC_2.1 10: 00000000 0 NOTYPE GLOBAL DEFAULT 1 foobar@GLIBC_2.1 No version information found in this file. Any comments? -- H.J. Lu (hjl@gnu.org) --- 2000-11-06 H.J. Lu * obj.h (format_ops): Add the frob_file_before_adjust field. * config/obj-aout.c (aout_format_ops): Set the frob_file_before_adjust field to 0. * config/obj-coff.c (coff_format_ops): Likewise. * config/obj-ecoff.c (ecoff_format_ops): Likewise. * config/obj-elf.c (obj_elf_symver): Allow duplicated version name. (elf_frob_file_before_adjust): New function to remove unneeded versioned symbols from the symbol table. (elf_format_ops): Set the frob_file_before_adjust field to elf_frob_file_before_adjust. * config/obj-elf.h (obj_frob_file_before_adjust): Defined if not defined. * config/obj-multi.h (obj_frob_file_before_adjust): Defined. Index: obj.h =================================================================== RCS file: /work/cvs/gnu/binutils/gas/obj.h,v retrieving revision 1.1.1.3 diff -u -p -r1.1.1.3 obj.h --- obj.h 2000/05/30 05:36:04 1.1.1.3 +++ obj.h 2000/11/06 19:04:11 @@ -54,6 +54,7 @@ struct format_ops { void (*app_file) PARAMS ((const char *)); void (*frob_symbol) PARAMS ((symbolS *, int *)); void (*frob_file) PARAMS ((void)); + void (*frob_file_before_adjust) PARAMS ((void)); void (*frob_file_after_relocs) PARAMS ((void)); bfd_vma (*s_get_size) PARAMS ((symbolS *)); void (*s_set_size) PARAMS ((symbolS *, bfd_vma)); Index: config/obj-aout.c =================================================================== RCS file: /work/cvs/gnu/binutils/gas/config/obj-aout.c,v retrieving revision 1.1.1.8 diff -u -p -r1.1.1.8 obj-aout.c --- config/obj-aout.c 2000/09/17 23:02:05 1.1.1.8 +++ config/obj-aout.c 2000/11/06 19:03:24 @@ -732,6 +732,7 @@ const struct format_ops aout_format_ops 0, /* app_file */ obj_aout_frob_symbol, obj_aout_frob_file, + 0, /* frob_file_before_adjust */ 0, /* frob_file_after_relocs */ 0, /* s_get_size */ 0, /* s_set_size */ Index: config/obj-coff.c =================================================================== RCS file: /work/cvs/gnu/binutils/gas/config/obj-coff.c,v retrieving revision 1.1.1.23 diff -u -p -r1.1.1.23 obj-coff.c --- config/obj-coff.c 2000/09/17 23:02:05 1.1.1.23 +++ config/obj-coff.c 2000/11/06 19:03:29 @@ -4653,6 +4653,7 @@ const struct format_ops coff_format_ops c_dot_file_symbol, coff_frob_symbol, 0, /* frob_file */ + 0, /* frob_file_before_adjust */ coff_frob_file_after_relocs, 0, /* s_get_size */ 0, /* s_set_size */ Index: config/obj-ecoff.c =================================================================== RCS file: /work/cvs/gnu/binutils/gas/config/obj-ecoff.c,v retrieving revision 1.1.1.5 diff -u -p -r1.1.1.5 obj-ecoff.c --- config/obj-ecoff.c 2000/09/17 23:02:05 1.1.1.5 +++ config/obj-ecoff.c 2000/11/06 19:03:33 @@ -309,6 +309,7 @@ const struct format_ops ecoff_format_ops ecoff_new_file, obj_ecoff_frob_symbol, ecoff_frob_file, + 0, /* frob_file_before_adjust */ 0, /* frob_file_after_relocs */ 0, /* s_get_size */ 0, /* s_set_size */ Index: config/obj-elf.c =================================================================== RCS file: /work/cvs/gnu/binutils/gas/config/obj-elf.c,v retrieving revision 1.22 diff -u -p -r1.22 obj-elf.c --- config/obj-elf.c 2000/10/11 18:23:38 1.22 +++ config/obj-elf.c 2000/11/06 19:57:09 @@ -1106,14 +1106,6 @@ obj_elf_symver (ignore) *input_line_pointer = c; - if (symbol_get_obj (sym)->versioned_name != NULL) - { - as_bad (_("multiple .symver directives for symbol `%s'"), - S_GET_NAME (sym)); - ignore_rest_of_line (); - return; - } - SKIP_WHITESPACE (); if (*input_line_pointer != ',') { @@ -1132,16 +1124,33 @@ obj_elf_symver (ignore) *input_line_pointer++ = c; } - symbol_get_obj (sym)->versioned_name = xstrdup (name); + if (symbol_get_obj (sym)->versioned_name == NULL) + { + symbol_get_obj (sym)->versioned_name = xstrdup (name); - *input_line_pointer = c; + *input_line_pointer = c; - if (strchr (symbol_get_obj (sym)->versioned_name, ELF_VER_CHR) == NULL) + if (strchr (symbol_get_obj (sym)->versioned_name, + ELF_VER_CHR) == NULL) + { + as_bad (_("missing version name in `%s' for symbol `%s'"), + symbol_get_obj (sym)->versioned_name, + S_GET_NAME (sym)); + ignore_rest_of_line (); + return; + } + } + else { - as_bad (_("missing version name in `%s' for symbol `%s'"), - symbol_get_obj (sym)->versioned_name, S_GET_NAME (sym)); - ignore_rest_of_line (); - return; + if (strcmp (symbol_get_obj (sym)->versioned_name, name)) + { + as_bad (_("multiple .symver directives for symbol `%s'"), + S_GET_NAME (sym)); + ignore_rest_of_line (); + return; + } + + *input_line_pointer = c; } demand_empty_rest_of_line (); @@ -1753,6 +1762,24 @@ elf_frob_file () #endif } +/* It removes any unneeded versioned symbols from the symbol table. */ + +void +elf_frob_file_before_adjust () +{ + if (symbol_rootP) + { + symbolS *symp; + + for (symp = symbol_rootP; symp; symp = symbol_next (symp)) + if (symbol_get_obj (symp)->versioned_name + && !S_IS_DEFINED (symp) + && symbol_used_p (symp) == 0 + && symbol_used_in_reloc_p (symp) == 0) + symbol_remove (symp, &symbol_rootP, &symbol_lastP); + } +} + /* It is required that we let write_relocs have the opportunity to optimize away fixups before output has begun, since it is possible to eliminate all fixups for a section and thus we never should @@ -1957,6 +1984,7 @@ const struct format_ops elf_format_ops = elf_file_symbol, elf_frob_symbol, elf_frob_file, + elf_frob_file_before_adjust, elf_frob_file_after_relocs, elf_s_get_size, elf_s_set_size, elf_s_get_align, elf_s_set_align, Index: config/obj-elf.h =================================================================== RCS file: /work/cvs/gnu/binutils/gas/config/obj-elf.h,v retrieving revision 1.8 diff -u -p -r1.8 obj-elf.h --- config/obj-elf.h 2000/09/17 23:09:52 1.8 +++ config/obj-elf.h 2000/11/06 19:02:24 @@ -132,6 +132,11 @@ extern asection *gdb_section; #endif extern void elf_frob_file PARAMS ((void)); +#ifndef obj_frob_file_before_adjust +#define obj_frob_file_before_adjust elf_frob_file_before_adjust +#endif +extern void elf_frob_file_before_adjust PARAMS ((void)); + #ifndef obj_frob_file_after_relocs #define obj_frob_file_after_relocs elf_frob_file_after_relocs #endif Index: config/obj-multi.h =================================================================== RCS file: /work/cvs/gnu/binutils/gas/config/obj-multi.h,v retrieving revision 1.1.1.4 diff -u -p -r1.1.1.4 obj-multi.h --- config/obj-multi.h 2000/05/30 05:36:07 1.1.1.4 +++ config/obj-multi.h 2000/11/06 19:02:47 @@ -50,6 +50,11 @@ ? (*this_format->frob_file) () \ : (void) 0) +#define obj_frob_file_before_adjust() \ + (this_format->frob_file_before_adjust \ + ? (*this_format->frob_file_before_adjust) () \ + : (void) 0) + #define obj_frob_file_after_relocs() \ (this_format->frob_file_after_relocs \ ? (*this_format->frob_file_after_relocs) () \ From kkojima@rr.iij4u.or.jp Tue Nov 7 05:19:00 2000 From: kkojima@rr.iij4u.or.jp (kaz Kojima) Date: Tue, 07 Nov 2000 05:19:00 -0000 Subject: A forgotten patch for SH Message-ID: <200011071319.WAA01355@rr.iij4u.or.jp> Hi, There is a forgotten patch for the SH processor without FPU. Sorry for my carelessness. kaz -- 2000-11-07 Kazumoto Kojima * sysdeps/sh/sh4/bits/setjmp.h: New file. * sysdeps/sh/bits/setjmp.h: Changes for no FPU case. --- /dev/null Wed May 6 05:32:27 1998 +++ sysdeps/sh/sh4/bits/setjmp.h Tue Nov 7 09:18:51 2000 @@ -0,0 +1,2 @@ +#define HAVE_FPU +#include Index: bits/setjmp.h =================================================================== RCS file: /cvs/glibc/libc/sysdeps/sh/bits/setjmp.h,v retrieving revision 1.1 diff -u -r1.1 setjmp.h --- setjmp.h 2000/06/13 01:00:45 1.1 +++ setjmp.h 2000/11/07 00:18:05 @@ -34,15 +34,21 @@ /* The global pointer. */ void * __gbr; +#ifdef HAVE_FPU /* Floating point status register. */ int __fpscr; /* Callee-saved floating point registers fr12 through fr15. */ int __fpregs[4]; +#endif } __jmp_buf[1]; #endif +#ifdef HAVE_FPU #define JB_SIZE (4 * 15) +#else +#define JB_SIZE (4 * 10) +#endif /* Test if longjmp to JMPBUF would unwind the frame containing a local variable at ADDRESS. */ From aj@suse.de Tue Nov 7 05:31:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Tue, 07 Nov 2000 05:31:00 -0000 Subject: A forgotten patch for SH References: <200011071319.WAA01355@rr.iij4u.or.jp> Message-ID: >>>>> kaz Kojima writes: > Hi, > There is a forgotten patch for the SH processor without FPU. > Sorry for my carelessness. The patch doesn't look right for me - where is HAVE_FPU defined for user programs? is used by user programs. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From kkojima@rr.iij4u.or.jp Tue Nov 7 06:19:00 2000 From: kkojima@rr.iij4u.or.jp (kaz Kojima) Date: Tue, 07 Nov 2000 06:19:00 -0000 Subject: A forgotten patch for SH References: Message-ID: <200011071419.XAA21665@rr.iij4u.or.jp> Andreas Jaeger wrote: > The patch doesn't look right for me - where is HAVE_FPU defined for > user programs? is used by user programs. Ah! I agree. How about the following patch? Thanks, kaz -- 2000-11-07 Kazumoto Kojima * sysdeps/sh/bits/setjmp.h: Move * sysdeps/sh/sh4/bits/setjmp.h: to here. * sysdeps/sh/sh3/bits/setjmp.h: New file. --- bits/setjmp.h Tue Jun 13 10:00:45 2000 +++ /dev/null Mon Nov 2 21:13:57 1998 @@ -1,50 +0,0 @@ -/* Copyright (C) 1999, 2000 Free Software Foundation, Inc. - This file is part of the GNU C Library. - - The GNU C Library is free software; you can redistribute it and/or - modify it under the terms of the GNU Library General Public License as - published by the Free Software Foundation; either version 2 of the - License, or (at your option) any later version. - - The GNU C Library is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - Library General Public License for more details. - - You should have received a copy of the GNU Library General Public - License along with the GNU C Library; see the file COPYING.LIB. If not, - write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, - Boston, MA 02111-1307, USA. */ - -/* Define the machine-dependent type `jmp_buf'. SH version. */ - -#ifndef _SETJMP_H -# error "Never include directly; use instead." -#endif - -#ifndef _ASM -typedef struct - { - /* Callee-saved registers r8 through r15. */ - int __regs[8]; - - /* Program counter. */ - void * __pc; - - /* The global pointer. */ - void * __gbr; - - /* Floating point status register. */ - int __fpscr; - - /* Callee-saved floating point registers fr12 through fr15. */ - int __fpregs[4]; - } __jmp_buf[1]; -#endif - -#define JB_SIZE (4 * 15) - -/* Test if longjmp to JMPBUF would unwind the frame - containing a local variable at ADDRESS. */ -#define _JMPBUF_UNWINDS(jmpbuf, address) \ - ((void *) (address) < &(jmpbuf)[0].__regs[7]) --- /dev/null Wed May 6 05:32:27 1998 +++ sysdeps/sh/sh4/bits/setjmp.h Tue Nov 7 23:04:51 2000 @@ -0,0 +1,50 @@ +/* Copyright (C) 1999, 2000 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Library General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Library General Public License for more details. + + You should have received a copy of the GNU Library General Public + License along with the GNU C Library; see the file COPYING.LIB. If not, + write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, + Boston, MA 02111-1307, USA. */ + +/* Define the machine-dependent type `jmp_buf'. SH version. */ + +#ifndef _SETJMP_H +# error "Never include directly; use instead." +#endif + +#ifndef _ASM +typedef struct + { + /* Callee-saved registers r8 through r15. */ + int __regs[8]; + + /* Program counter. */ + void * __pc; + + /* The global pointer. */ + void * __gbr; + + /* Floating point status register. */ + int __fpscr; + + /* Callee-saved floating point registers fr12 through fr15. */ + int __fpregs[4]; + } __jmp_buf[1]; +#endif + +#define JB_SIZE (4 * 15) + +/* Test if longjmp to JMPBUF would unwind the frame + containing a local variable at ADDRESS. */ +#define _JMPBUF_UNWINDS(jmpbuf, address) \ + ((void *) (address) < &(jmpbuf)[0].__regs[7]) --- /dev/null Wed May 6 05:32:27 1998 +++ sysdeps/sh/sh3/bits/setjmp.h Tue Nov 7 23:06:26 2000 @@ -0,0 +1,44 @@ +/* Copyright (C) 1999, 2000 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Library General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Library General Public License for more details. + + You should have received a copy of the GNU Library General Public + License along with the GNU C Library; see the file COPYING.LIB. If not, + write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, + Boston, MA 02111-1307, USA. */ + +/* Define the machine-dependent type `jmp_buf'. SH version. */ + +#ifndef _SETJMP_H +# error "Never include directly; use instead." +#endif + +#ifndef _ASM +typedef struct + { + /* Callee-saved registers r8 through r15. */ + int __regs[8]; + + /* Program counter. */ + void * __pc; + + /* The global pointer. */ + void * __gbr; + } __jmp_buf[1]; +#endif + +#define JB_SIZE (4 * 10) + +/* Test if longjmp to JMPBUF would unwind the frame + containing a local variable at ADDRESS. */ +#define _JMPBUF_UNWINDS(jmpbuf, address) \ + ((void *) (address) < &(jmpbuf)[0].__regs[7]) From aj@suse.de Tue Nov 7 06:33:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Tue, 07 Nov 2000 06:33:00 -0000 Subject: A forgotten patch for SH References: <200011071419.XAA21665@rr.iij4u.or.jp> Message-ID: >>>>> kaz Kojima writes: > Andreas Jaeger wrote: >> The patch doesn't look right for me - where is HAVE_FPU defined for >> user programs? is used by user programs. > Ah! I agree. How about the following patch? That looks fine, Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From drepper@redhat.com Tue Nov 7 08:50:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Tue, 07 Nov 2000 08:50:00 -0000 Subject: A forgotten patch for SH References: <200011071419.XAA21665@rr.iij4u.or.jp> Message-ID: kaz Kojima writes: > 2000-11-07 Kazumoto Kojima > > * sysdeps/sh/bits/setjmp.h: Move > * sysdeps/sh/sh4/bits/setjmp.h: to here. > * sysdeps/sh/sh3/bits/setjmp.h: New file. I've applied the patch now. But please remember: we've changed this some time back (2000-6-7) to have the same definition on both SH3 and SH4. This increases binary compatibility. You have now reverted this change and went back to the original definition. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From hjl@valinux.com Tue Nov 7 15:50:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Tue, 07 Nov 2000 15:50:00 -0000 Subject: A symbol version patch for glibc 2.x compatibility References: <200011071901.LAA30915@elmo.cygnus.com> Message-ID: <20001107155008.A24646@valinux.com> On Tue, Nov 07, 2000 at 11:01:59AM -0800, Nick Clifton wrote: > Hi H.J. > > I am not familiar with this versioning stuff, so please could you > help me understand your patch by answering a few questions: > > : I modified as so that it will > : > : 1. Allow duplicated version name like > : > : .symver bar,bar@GLIBC_2.1 > : .symver bar,bar@GLIBC_2.1 > > Why do you need this ability ? (I have no objections to it, I am just > wondering whether there ought to be a warning generated if a second, > duplicate, definition is encountered). I am working on a glibc patch. With my patch, 2 identical symbol version definitions may wind up in the asm code. I don't think it should cause any harm, like .globl foo .globl foo > > : ---- > : .file "x.c" > : .version "01.01" > : .symver bar,bar@GLIBC_2.1 > : .symver bar,bar@GLIBC_2.1 > : .globl foobar > : foobar: > : .long foo > : .symver foobar,foobar@GLIBC_2.1 > : dummy: > : .long foo > : .symver foo,foo@GLIBC_2.1 > : ----- > > Does this really work ? I thought that the symbol defined in a > .symver op had to be defined in the same file. Quoting from the as > info file: > > For ELF targets, the `.symver' directive is used like this: > > .symver NAME, NAME2@NODENAME > > In this case, the symbol NAME must exist and be defined within the > file being assembled. The `.versym' directive effectively creates > [snip] It should be updated to something like If NAME is not defined in the file, all references to NAME will be changed to NAME2@NODENAME. > > Or is this your point about removing unneeded version symbols ? (In > which case maybe the documentation ought to be updated as well). > I will update the documentation. -- H.J. Lu (hjl@gnu.org) From hjl@valinux.com Tue Nov 7 16:03:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Tue, 07 Nov 2000 16:03:00 -0000 Subject: A symbol version patch for glibc 2.x compatibility References: <200011071901.LAA30915@elmo.cygnus.com> Message-ID: <20001107160342.B24646@valinux.com> On Tue, Nov 07, 2000 at 11:01:59AM -0800, Nick Clifton wrote: > Other than that, I think that the patch is OK. So, please could you > extend your patch to update the documentation, and also include a new > testsuite case to check the new functionality. > > Cheers > Nick Here it is. -- H.J. Lu (hjl@gnu.org) --- 2000-11-07 H.J. Lu * doc/as.texinfo (.symver): Updated for versioned symbol reference. 2000-11-06 H.J. Lu * obj.h (format_ops): Add the frob_file_before_adjust field. * config/obj-aout.c (aout_format_ops): Set the frob_file_before_adjust field to 0. * config/obj-coff.c (coff_format_ops): Likewise. * config/obj-ecoff.c (ecoff_format_ops): Likewise. * config/obj-elf.c (obj_elf_symver): Allow duplicated version name. (elf_frob_file_before_adjust): New function to remove unneeded versioned symbols from the symbol table. (elf_format_ops): Set the frob_file_before_adjust field to elf_frob_file_before_adjust. * config/obj-elf.h (obj_frob_file_before_adjust): Defined if not defined. * config/obj-multi.h (obj_frob_file_before_adjust): Defined. Index: obj.h =================================================================== RCS file: /work/cvs/gnu/binutils/gas/obj.h,v retrieving revision 1.1.1.3 retrieving revision 1.2 diff -u -p -r1.1.1.3 -r1.2 --- obj.h 2000/05/30 05:36:04 1.1.1.3 +++ obj.h 2000/11/07 01:04:40 1.2 @@ -54,6 +54,7 @@ struct format_ops { void (*app_file) PARAMS ((const char *)); void (*frob_symbol) PARAMS ((symbolS *, int *)); void (*frob_file) PARAMS ((void)); + void (*frob_file_before_adjust) PARAMS ((void)); void (*frob_file_after_relocs) PARAMS ((void)); bfd_vma (*s_get_size) PARAMS ((symbolS *)); void (*s_set_size) PARAMS ((symbolS *, bfd_vma)); Index: config/obj-aout.c =================================================================== RCS file: /work/cvs/gnu/binutils/gas/config/obj-aout.c,v retrieving revision 1.1.1.8 retrieving revision 1.2 diff -u -p -r1.1.1.8 -r1.2 --- config/obj-aout.c 2000/09/17 23:02:05 1.1.1.8 +++ config/obj-aout.c 2000/11/07 01:04:42 1.2 @@ -732,6 +732,7 @@ const struct format_ops aout_format_ops 0, /* app_file */ obj_aout_frob_symbol, obj_aout_frob_file, + 0, /* frob_file_before_adjust */ 0, /* frob_file_after_relocs */ 0, /* s_get_size */ 0, /* s_set_size */ Index: config/obj-coff.c =================================================================== RCS file: /work/cvs/gnu/binutils/gas/config/obj-coff.c,v retrieving revision 1.1.1.23 retrieving revision 1.2 diff -u -p -r1.1.1.23 -r1.2 --- config/obj-coff.c 2000/09/17 23:02:05 1.1.1.23 +++ config/obj-coff.c 2000/11/07 01:04:42 1.2 @@ -4653,6 +4653,7 @@ const struct format_ops coff_format_ops c_dot_file_symbol, coff_frob_symbol, 0, /* frob_file */ + 0, /* frob_file_before_adjust */ coff_frob_file_after_relocs, 0, /* s_get_size */ 0, /* s_set_size */ Index: config/obj-ecoff.c =================================================================== RCS file: /work/cvs/gnu/binutils/gas/config/obj-ecoff.c,v retrieving revision 1.1.1.5 retrieving revision 1.2 diff -u -p -r1.1.1.5 -r1.2 --- config/obj-ecoff.c 2000/09/17 23:02:05 1.1.1.5 +++ config/obj-ecoff.c 2000/11/07 01:04:42 1.2 @@ -309,6 +309,7 @@ const struct format_ops ecoff_format_ops ecoff_new_file, obj_ecoff_frob_symbol, ecoff_frob_file, + 0, /* frob_file_before_adjust */ 0, /* frob_file_after_relocs */ 0, /* s_get_size */ 0, /* s_set_size */ Index: config/obj-elf.c =================================================================== RCS file: /work/cvs/gnu/binutils/gas/config/obj-elf.c,v retrieving revision 1.22 retrieving revision 1.23 diff -u -p -r1.22 -r1.23 --- config/obj-elf.c 2000/10/11 18:23:38 1.22 +++ config/obj-elf.c 2000/11/07 01:04:42 1.23 @@ -1106,14 +1106,6 @@ obj_elf_symver (ignore) *input_line_pointer = c; - if (symbol_get_obj (sym)->versioned_name != NULL) - { - as_bad (_("multiple .symver directives for symbol `%s'"), - S_GET_NAME (sym)); - ignore_rest_of_line (); - return; - } - SKIP_WHITESPACE (); if (*input_line_pointer != ',') { @@ -1132,16 +1124,34 @@ obj_elf_symver (ignore) *input_line_pointer++ = c; } - symbol_get_obj (sym)->versioned_name = xstrdup (name); + if (symbol_get_obj (sym)->versioned_name == NULL) + { + symbol_get_obj (sym)->versioned_name = xstrdup (name); - *input_line_pointer = c; + *input_line_pointer = c; - if (strchr (symbol_get_obj (sym)->versioned_name, ELF_VER_CHR) == NULL) + if (strchr (symbol_get_obj (sym)->versioned_name, + ELF_VER_CHR) == NULL) + { + as_bad (_("missing version name in `%s' for symbol `%s'"), + symbol_get_obj (sym)->versioned_name, + S_GET_NAME (sym)); + ignore_rest_of_line (); + return; + } + } + else { - as_bad (_("missing version name in `%s' for symbol `%s'"), - symbol_get_obj (sym)->versioned_name, S_GET_NAME (sym)); - ignore_rest_of_line (); - return; + if (strcmp (symbol_get_obj (sym)->versioned_name, name)) + { + as_bad (_("multiple versions [`%s'|`%s'] for symbol `%s'"), + name, symbol_get_obj (sym)->versioned_name, + S_GET_NAME (sym)); + ignore_rest_of_line (); + return; + } + + *input_line_pointer = c; } demand_empty_rest_of_line (); @@ -1753,6 +1763,24 @@ elf_frob_file () #endif } +/* It removes any unneeded versioned symbols from the symbol table. */ + +void +elf_frob_file_before_adjust () +{ + if (symbol_rootP) + { + symbolS *symp; + + for (symp = symbol_rootP; symp; symp = symbol_next (symp)) + if (symbol_get_obj (symp)->versioned_name + && !S_IS_DEFINED (symp) + && symbol_used_p (symp) == 0 + && symbol_used_in_reloc_p (symp) == 0) + symbol_remove (symp, &symbol_rootP, &symbol_lastP); + } +} + /* It is required that we let write_relocs have the opportunity to optimize away fixups before output has begun, since it is possible to eliminate all fixups for a section and thus we never should @@ -1957,6 +1985,7 @@ const struct format_ops elf_format_ops = elf_file_symbol, elf_frob_symbol, elf_frob_file, + elf_frob_file_before_adjust, elf_frob_file_after_relocs, elf_s_get_size, elf_s_set_size, elf_s_get_align, elf_s_set_align, Index: config/obj-elf.h =================================================================== RCS file: /work/cvs/gnu/binutils/gas/config/obj-elf.h,v retrieving revision 1.8 retrieving revision 1.9 diff -u -p -r1.8 -r1.9 --- config/obj-elf.h 2000/09/17 23:09:52 1.8 +++ config/obj-elf.h 2000/11/07 01:04:42 1.9 @@ -132,6 +132,11 @@ extern asection *gdb_section; #endif extern void elf_frob_file PARAMS ((void)); +#ifndef obj_frob_file_before_adjust +#define obj_frob_file_before_adjust elf_frob_file_before_adjust +#endif +extern void elf_frob_file_before_adjust PARAMS ((void)); + #ifndef obj_frob_file_after_relocs #define obj_frob_file_after_relocs elf_frob_file_after_relocs #endif Index: config/obj-multi.h =================================================================== RCS file: /work/cvs/gnu/binutils/gas/config/obj-multi.h,v retrieving revision 1.1.1.4 retrieving revision 1.2 diff -u -p -r1.1.1.4 -r1.2 --- config/obj-multi.h 2000/05/30 05:36:07 1.1.1.4 +++ config/obj-multi.h 2000/11/07 01:04:42 1.2 @@ -50,6 +50,11 @@ ? (*this_format->frob_file) () \ : (void) 0) +#define obj_frob_file_before_adjust() \ + (this_format->frob_file_before_adjust \ + ? (*this_format->frob_file_before_adjust) () \ + : (void) 0) + #define obj_frob_file_after_relocs() \ (this_format->frob_file_after_relocs \ ? (*this_format->frob_file_after_relocs) () \ Index: doc/as.texinfo =================================================================== RCS file: /work/cvs/gnu/binutils/gas/doc/as.texinfo,v retrieving revision 1.15 diff -u -p -r1.15 as.texinfo --- doc/as.texinfo 2000/10/18 18:23:49 1.15 +++ doc/as.texinfo 2000/11/07 23:56:12 @@ -4938,8 +4938,8 @@ For ELF targets, the @code{.symver} dire @smallexample .symver @var{name}, @var{name2@@nodename} @end smallexample -In this case, the symbol @var{name} must exist and be defined within the file -being assembled. The @code{.versym} directive effectively creates a symbol +If the symbol @var{name} is defined within the file +being assembled, the @code{.versym} directive effectively creates a symbol alias with the name @var{name2@@nodename}, and in fact the main reason that we just don't try and create a regular alias is that the @var{@@} character isn't permitted in symbol names. The @var{name2} part of the name is the actual name @@ -4952,6 +4952,11 @@ the name of a node specified in the vers building a shared library. If you are attempting to override a versioned symbol from a shared library, then @var{nodename} should correspond to the nodename of the symbol you are trying to override. + +If the symbol @var{name} is not defined within the file being assembled, all +references to @var{name} will be changed to @var{name2@@nodename}. If no +reference to @var{name} is made, @var{name2@@nodename} will be removed from the +symbol table. @end ifset @ifset COFF From hjl@valinux.com Tue Nov 7 16:25:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Tue, 07 Nov 2000 16:25:00 -0000 Subject: A symbol version patch for glibc 2.x compatibility References: <200011080009.QAA02251@elmo.cygnus.com> Message-ID: <20001107162508.A22802@valinux.com> On Tue, Nov 07, 2000 at 04:09:09PM -0800, Nick Clifton wrote: > > Approved. > Done. > I would still like to see a test case added to make sure that this new > code continues to work in the future. > That is my plan. I have some simple testcases. I will submit a patch for testcase later. -- H.J. Lu (hjl@gnu.org) From kkojima@rr.iij4u.or.jp Tue Nov 7 18:14:00 2000 From: kkojima@rr.iij4u.or.jp (kaz Kojima) Date: Tue, 07 Nov 2000 18:14:00 -0000 Subject: A forgotten patch for SH References: Message-ID: <200011080214.LAA18597@rr.iij4u.or.jp> Hi, Ulrich Drepper wrote: >> * sysdeps/sh/bits/setjmp.h: Move >> * sysdeps/sh/sh4/bits/setjmp.h: to here. >> * sysdeps/sh/sh3/bits/setjmp.h: New file. > > I've applied the patch now. But please remember: we've changed this > some time back (2000-6-7) to have the same definition on both SH3 and > SH4. This increases binary compatibility. You have now reverted this > change and went back to the original definition. This patch is requested by SH3 people, but I may be confused as you pointed out. I could fix sh3/setjmp.S and sh3/__longjmp.S so to use one common setjmp.h. I'll ask SH3 people whether this is ok or not. Thank you for your comment. kaz From kkojima@rr.iij4u.or.jp Tue Nov 7 20:58:00 2000 From: kkojima@rr.iij4u.or.jp (kaz Kojima) Date: Tue, 07 Nov 2000 20:58:00 -0000 Subject: A forgotten patch for SH References: <200011080214.LAA18597@rr.iij4u.or.jp> Message-ID: <200011080458.NAA28562@rr.iij4u.or.jp> kaz Kojima wrote: > Ulrich Drepper wrote: >>> * sysdeps/sh/bits/setjmp.h: Move >>> * sysdeps/sh/sh4/bits/setjmp.h: to here. >>> * sysdeps/sh/sh3/bits/setjmp.h: New file. >> >> I've applied the patch now. But please remember: we've changed this >> some time back (2000-6-7) to have the same definition on both SH3 and >> SH4. This increases binary compatibility. You have now reverted this >> change and went back to the original definition. > > This patch is requested by SH3 people, but I may be confused as you > pointed out. I could fix sh3/setjmp.S and sh3/__longjmp.S so to use > one common setjmp.h. I'll ask SH3 people whether this is ok or not. They say that you are right. I'd like to withdraw my previous patch and want to fix sh/sh3/setjmp.S only. Is it ok? Sorry for my confusion. kaz -- * sysdeps/sh/sh3/setjmp.S (__sigsetjmp): Skip FPU fields. Index: setjmp.S =================================================================== RCS file: /cvs/glibc/libc/sysdeps/sh/sh3/setjmp.S,v retrieving revision 1.1 diff -u -r1.1 setjmp.S --- setjmp.S 2000/06/12 20:09:26 1.1 +++ setjmp.S 2000/11/08 02:22:41 @@ -1,4 +1,4 @@ -/* setjmp for SH4. +/* setjmp for SH3. Copyright (C) 1999, 2000 Free Software Foundation, Inc. This file is part of the GNU C Library. @@ -27,7 +27,7 @@ mov #0, r5 ENTRY (__sigsetjmp) /* Save registers */ - add #JB_SIZE, r4 + add #(JB_SIZE - 4 * 5), r4 stc.l gbr, @-r4 sts.l pr, @-r4 mov.l r15, @-r4 From drepper@redhat.com Tue Nov 7 21:09:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Tue, 07 Nov 2000 21:09:00 -0000 Subject: A forgotten patch for SH References: <200011080214.LAA18597@rr.iij4u.or.jp> <200011080458.NAA28562@rr.iij4u.or.jp> Message-ID: kaz Kojima writes: > They say that you are right. I'd like to withdraw my previous patch > and want to fix sh/sh3/setjmp.S only. Is it ok? OK, I'll add this one. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From jakub@redhat.com Wed Nov 8 03:41:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Wed, 08 Nov 2000 03:41:00 -0000 Subject: [PATCH] Don't "optimize" strchr(x, 0) on sparc Message-ID: <20001108124503.P6915@sunsite.ms.mff.cuni.cz> Hi! sparc/sparc32/strchr.S and sparc/sparc64/strchr.S are optimized even for the case where the second argument is 0, so on sparc* we should get rid of the strchr(x, '\0') -> __rawmemchr(x, '\0') optimization (rawmemchr even in assembly does not special case this and has to compute c * 0x01010101 and has to do one additional xor inside of the loop. _HAVE_STRING_ARCH macros were used for 2 purposes: to find out whether bits/string2.h should define its own and to find out whether that particular function will be expanded inline. This patch separates them into _HAVE_STRING_ARCH macros (the first meaning) and _USE_STRING_ARCH (the latter) - eventhough we define _HAVE_STRING_ARCH_strchr on sparc, we don't want strncat to be optimized into two function calls instead of one. 2000-11-08 Jakub Jelinek * string/bits/string2.h: Check if _USE_STRING_ARCH_ macros are defined, not _HAVE_STRING_ARCH_. * sysdeps/i386/bits/string.h (_USE_STRING_ARCH_memset, _USE_STRING_ARCH_strchr): Define. * sysdeps/i386/i486/bits/string.h (_USE_STRING_ARCH_memset, _USE_STRING_ARCH_strchr): Define. * sysdeps/sparc/bits/string.h: New. --- libc/string/bits/string2.h.jj Thu Nov 2 08:52:18 2000 +++ libc/string/bits/string2.h Wed Nov 8 12:35:35 2000 @@ -698,7 +698,7 @@ __stpcpy_small (char *__dest, /* Copy no more than N characters of SRC to DEST. */ #ifndef _HAVE_STRING_ARCH_strncpy -# if defined _HAVE_STRING_ARCH_memset && defined _HAVE_STRING_ARCH_mempcpy +# if defined _USE_STRING_ARCH_memset && defined _USE_STRING_ARCH_mempcpy # define strncpy(dest, src, n) \ (__extension__ ({ char *__dest = (dest); \ __builtin_constant_p (src) && __builtin_constant_p (n) \ @@ -721,7 +721,7 @@ __stpcpy_small (char *__dest, /* Append no more than N characters from SRC onto DEST. */ #ifndef _HAVE_STRING_ARCH_strncat -# ifdef _HAVE_STRING_ARCH_strchr +# ifdef _USE_STRING_ARCH_strchr # define strncat(dest, src, n) \ (__extension__ ({ char *__dest = (dest); \ __builtin_constant_p (src) && __builtin_constant_p (n) \ --- libc/sysdeps/i386/bits/string.h.jj Thu Jul 27 16:04:13 2000 +++ libc/sysdeps/i386/bits/string.h Wed Nov 8 12:37:04 2000 @@ -176,6 +176,7 @@ memmove (void *__dest, __const void *__s /* Set N bytes of S to C. */ #define _HAVE_STRING_ARCH_memset 1 +#define _USE_STRING_ARCH_memset 1 #define memset(s, c, n) \ (__extension__ (__builtin_constant_p (c) \ ? (__builtin_constant_p (n) \ @@ -513,6 +514,7 @@ strncmp (__const char *__s1, __const cha /* Find the first occurrence of C in S. */ #define _HAVE_STRING_ARCH_strchr 1 +#define _USE_STRING_ARCH_strchr 1 #define strchr(s, c) \ (__extension__ (__builtin_constant_p (c) \ ? __strchr_c (s, ((c) & 0xff) << 8) \ --- libc/sysdeps/i386/i486/bits/string.h.jj Tue Nov 7 08:40:26 2000 +++ libc/sysdeps/i386/i486/bits/string.h Wed Nov 8 12:38:05 2000 @@ -192,6 +192,7 @@ memcmp (__const void *__s1, __const void /* Set N bytes of S to C. */ #define _HAVE_STRING_ARCH_memset 1 +#define _USE_STRING_ARCH_memset 1 #define memset(s, c, n) \ (__extension__ (__builtin_constant_p (n) && (n) <= 16 \ ? ((n) == 1 \ @@ -1188,6 +1189,7 @@ __strncmp_g (__const char *__s1, __const /* Find the first occurrence of C in S. */ #define _HAVE_STRING_ARCH_strchr 1 +#define _USE_STRING_ARCH_strchr 1 #define strchr(s, c) \ (__extension__ (__builtin_constant_p (c) \ ? ((c) == '\0' \ --- libc/sysdeps/sparc/bits/string.h.jj Wed Nov 8 12:19:43 2000 +++ libc/sysdeps/sparc/bits/string.h Wed Nov 8 12:41:15 2000 @@ -0,0 +1,26 @@ +/* Optimized, inlined string functions. SPARC version. + Copyright (C) 2000 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Library General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Library General Public License for more details. + + You should have received a copy of the GNU Library General Public + License along with the GNU C Library; see the file COPYING.LIB. If not, + write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, + Boston, MA 02111-1307, USA. */ + +#ifndef _STRING_H +# error "Never use directly; include instead." +#endif + +/* sparc32 and sparc64 strchr(x, '\0') perform better than + __rawmemchr(x, '\0'). */ +#define _HAVE_STRING_ARCH_strchr 1 Jakub From hjl@valinux.com Wed Nov 8 09:48:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Wed, 08 Nov 2000 09:48:00 -0000 Subject: A patch for pwd/Versions Message-ID: <20001108094826.A14067@valinux.com> While working on the link-time compatibility, I noticed that getpwnam_r was missing from GLIBC_2.1.2 in both glibc 2.1 and 2.2. Here is a patch. -- H.J. Lu (hjl@gnu.org) --- 2000-11-08 H.J. Lu * pwd/Versions (GLIBC_2.1.2): Add getpwnam_r. Index: pwd/Versions =================================================================== RCS file: /work/cvs/gnu/glibc/pwd/Versions,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 Versions --- pwd/Versions 2000/05/21 21:11:24 1.1.1.1 +++ pwd/Versions 2000/11/08 17:44:21 @@ -14,6 +14,6 @@ libc { } GLIBC_2.1.2 { # g* - getpwent_r; getpwuid_r; + getpwent_r; getpwuid_r; getpwnam_r; } } From drepper@redhat.com Wed Nov 8 12:50:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Wed, 08 Nov 2000 12:50:00 -0000 Subject: [PATCH] Don't "optimize" strchr(x, 0) on sparc References: <20001108124503.P6915@sunsite.ms.mff.cuni.cz> Message-ID: Jakub Jelinek writes: > 2000-11-08 Jakub Jelinek > I've applied the patch. Thanks, -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Wed Nov 8 12:52:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Wed, 08 Nov 2000 12:52:00 -0000 Subject: A patch for pwd/Versions References: <20001108094826.A14067@valinux.com> Message-ID: "H . J . Lu" writes: > While working on the link-time compatibility, I noticed that getpwnam_r > was missing from GLIBC_2.1.2 in both glibc 2.1 and 2.2. Here is a > patch. Thanks, I've applied the patch. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From hjl@valinux.com Wed Nov 8 13:11:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Wed, 08 Nov 2000 13:11:00 -0000 Subject: libio is seriously broken Message-ID: <20001108131031.A5772@valinux.com> I got #0 fprintf (stream=0x4014fc60, format=0x40147f82 "free(): invalid pointer %p!\n") at fprintf.c:31 #1 0x400a90f4 in free_check (mem=0x4001d000, caller=0x400a2e2b) at malloc.c:4542 #2 0x400a6e1d in __libc_free (mem=0x4001d000) at malloc.c:3012 #3 0x400a2e2b in __underflow (fp=0x80fbee0) at genops.c:167 #4 0x400a24a5 in _IO_file_xsgetn (fp=0x80fbee0, data=0xbffff3e0, n=40) at fileops.c:970 #5 0x400a37f2 in _IO_sgetn (fp=0x80fbee0, data=0xbffff3e0, n=40) at genops.c:448 #6 0x40098847 in _IO_fread (buf=0xbffff3e0, size=1, count=40, fp=0x80fbee0) at iofread.c:42 #7 0x80648ce in bfd_read (ptr=0xbffff3e0, size=40, nitems=1, abfd=0x81abd78) The problem is free (fp->_IO_save_base); in _IO_free_backup_area () in genops.c. Please keep in mind that libio uses ALLOC_BUF for main buffer allocation, which calls mmap. But malloc/free is used for _IO_save_base. When we switch between backup and main buffer, we have to be very careful. Otherwise, we will be screwed. I will see what I can do. -- H.J. Lu (hjl@gnu.org) From hjl@valinux.com Wed Nov 8 13:32:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Wed, 08 Nov 2000 13:32:00 -0000 Subject: libio is seriously broken References: <20001108131031.A5772@valinux.com> Message-ID: <20001108133247.A6789@valinux.com> On Wed, Nov 08, 2000 at 01:10:31PM -0800, H . J . Lu wrote: > The problem is > > free (fp->_IO_save_base); > > in _IO_free_backup_area () in genops.c. Please keep in mind that libio > uses ALLOC_BUF for main buffer allocation, which calls mmap. But > malloc/free is used for _IO_save_base. When we switch between backup > and main buffer, we have to be very careful. Otherwise, we will be > screwed. I will see what I can do. > Never mind. It was my fault :-). -- H.J. Lu (hjl@gnu.org) From drepper@redhat.com Wed Nov 8 13:46:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Wed, 08 Nov 2000 13:46:00 -0000 Subject: libio is seriously broken References: <20001108131031.A5772@valinux.com> Message-ID: "H . J . Lu" writes: > I got Test case? > in _IO_free_backup_area () in genops.c. Please keep in mind that libio > uses ALLOC_BUF for main buffer allocation, which calls mmap. But > malloc/free is used for _IO_save_base. That's right. But the free() should only be called for backup buffers. If it's called for something else the tests for the availability of a backup buffer are somehow wrong. And this does not automatically imply a bug in libio since it's easy enough to incorrectly modify one of the pointers of flags. I need a test case. There are millions of people using the code without problems (and this is no new code) so you cannot expect me to go hunting down your problem with a backtrace only. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Wed Nov 8 14:23:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Wed, 08 Nov 2000 14:23:00 -0000 Subject: last call Message-ID: If you have anything left or I haven't applied some patch let me know today. I don't think any of the changes made since .97 require another test release to the next one is for real. I shoot for tomorrow (my time). I've updated and extended the announcement text with the help of the feedback I got. You can find the updated text again at http://www.cygnus.com/~drepper/ANNOUNCE -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From jes@linuxcare.com Wed Nov 8 14:33:00 2000 From: jes@linuxcare.com (Jes Sorensen) Date: Wed, 08 Nov 2000 14:33:00 -0000 Subject: last call References: Message-ID: >>>>> "Ulrich" == Ulrich Drepper writes: Ulrich> If you have anything left or I haven't applied some patch let Ulrich> me know today. I don't think any of the changes made since Ulrich> .97 require another test release to the next one is for real. Ulrich> I shoot for tomorrow (my time). Ulrich> I've updated and extended the announcement text with the help Ulrich> of the feedback I got. You can find the updated text again at I have a few things I need to implement for the ia64 (AT_PAGESIZE etc.) all ia64 specific so I don't think thats reason to hold back the release. There will be bits and pieces coming along but I'd suggest we just put that in 2.2.x (for x >= 1). Jes From hjl@valinux.com Thu Nov 9 00:15:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Thu, 09 Nov 2000 00:15:00 -0000 Subject: Functions with different versions in libc and libpthread Message-ID: <20001109001530.A23552@valinux.com> Some functions have different versions in libc and libpthread. For example, pread has GLIBC_2.1 in libc and GLIBC_2.2 in libpthread. I can imagine potential problems with it. Shouldn't a fuction have the same verion cross all libraries? -- H.J. Lu (hjl@valinux.com) From drepper@redhat.com Thu Nov 9 00:23:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Thu, 09 Nov 2000 00:23:00 -0000 Subject: Functions with different versions in libc and libpthread References: <20001109001530.A23552@valinux.com> Message-ID: "H . J . Lu" writes: > Some functions have different versions in libc and libpthread. For > example, pread has GLIBC_2.1 in libc and GLIBC_2.2 in libpthread. > I can imagine potential problems with it. Shouldn't a fuction have > the same verion cross all libraries? The names, although the same in all libraries, are completely separated. They don't stand alone, they are used as a tuple (library,version). It doesn't matter whether a symbol has different names in different DSOs. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From schwidefsky@de.ibm.com Thu Nov 9 00:39:00 2000 From: schwidefsky@de.ibm.com (schwidefsky@de.ibm.com) Date: Thu, 09 Nov 2000 00:39:00 -0000 Subject: last call Message-ID: I still have the mmap2 support for 2.4 in the pipe (for the s/390 backend). The assembly file is done but I haven't found a way to reliably test it. Any ideas? blue skies, Martin Linux/390 Design & Development, IBM Deutschland Entwicklung GmbH Sch????naicherstr. 220, D-71032 B????blingen, Telefon: 49 - (0)7031 - 16-2247 E-Mail: schwidefsky@de.ibm.com From drepper@redhat.com Thu Nov 9 00:52:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Thu, 09 Nov 2000 00:52:00 -0000 Subject: last call References: Message-ID: schwidefsky@de.ibm.com writes: > I still have the mmap2 support for 2.4 in the pipe (for the s/390 backend). > The assembly file is done but I haven't found a way to reliably test it. > Any ideas? Look at the x86 mmap.S file. We are using the mmap2 syscall even for the mmap() and not only the mmap64() implementation. The implementation is therefore tested in every single program run. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From jakub@redhat.com Thu Nov 9 04:07:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Thu, 09 Nov 2000 04:07:00 -0000 Subject: [PATCH] Fix LC_PAPER Message-ID: <20001109131025.U6915@sunsite.ms.mff.cuni.cz> Hi! Most of the common paper sizes are not squares... 2000-11-09 Jakub Jelinek * locale/programs/ld-paper.c (paper_output): Fix offset into width field. --- libc/locale/programs/ld-paper.c.jj Mon Jan 17 07:58:52 2000 +++ libc/locale/programs/ld-paper.c Thu Nov 9 13:05:21 2000 @@ -138,7 +138,7 @@ paper_output (struct localedef_t *locale iov[cnt].iov_len = 4; ++cnt; - idx[cnt - 2] = iov[0].iov_len + iov[1].iov_len; + idx[cnt - 2] = idx[cnt - 3] + iov[cnt - 1].iov_len; iov[cnt].iov_base = &paper->width; iov[cnt].iov_len = 4; ++cnt; Jakub From jakub@redhat.com Thu Nov 9 04:40:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Thu, 09 Nov 2000 04:40:00 -0000 Subject: [PATCH] Fix LC_TIME Message-ID: <20001109134343.V6915@sunsite.ms.mff.cuni.cz> Hi! _NL_TIME_WEEK_1STWEEK is described as byte, so we cannot put word in there because then we segfault. I have no idea about what that value means though, so it is just the value from en_US, which might be wrong because unlike C en_US uses 19971201 for _NL_TIME_WEEK_1STDAY. 2000-11-09 Jakub Jelinek * locale/C-time.c (_nl_C_LC_TIME): Fix value for _NL_TIME_WEEK_1STWEEK. --- libc/locale/C-time.c.jj Thu Nov 2 08:51:42 2000 +++ libc/locale/C-time.c Thu Nov 9 13:42:08 2000 @@ -135,7 +135,7 @@ const struct locale_data _nl_C_LC_TIME = { wstr: (const uint32_t *) L"" }, { string: "\7" }, { word: 19971130 }, - { word: 19971130 }, + { string: "\4" }, { string: "\7" }, { string: "\1" }, { string: "\1" }, Jakub From jakub@redhat.com Thu Nov 9 07:35:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Thu, 09 Nov 2000 07:35:00 -0000 Subject: [PATCH] Build proper bits/syscall.h on sparc* Message-ID: <20001109163857.Y6915@sunsite.ms.mff.cuni.cz> Hi! As mentioned some time ago, sparc*-*-linux* needs to do more work to build bits/syscall.h than most of the other ports, because although most of the syscalls are common to both platforms, some syscalls are 32bit and some syscalls are 64bit only. This patch was tested on sparc32 by full bootstrap/make check (passed) and on sparc64 (just did this by hand to see whether it works). It should work on all other arches since nothing else defines no_syscall_list_h. 2000-11-09 Jakub Jelinek * sysdeps/unix/sysv/linux/Makefile: Allow ports to override syscall-list.h goal. * sysdeps/unix/sysv/linux/sparc/Makefile: New. --- libc/sysdeps/unix/sysv/linux/sparc/Makefile.jj Thu Nov 9 10:51:46 2000 +++ libc/sysdeps/unix/sysv/linux/sparc/Makefile Thu Nov 9 11:26:57 2000 @@ -0,0 +1,44 @@ +ifeq ($(subdir),misc) + +no_syscall_list_h = 1 + +# Generate the list of SYS_* macros for the system calls (__NR_* macros). +$(objpfx)syscall-%.h $(objpfx)syscall-%.d: ../sysdeps/unix/sysv/linux/sys/syscall.h + rm -f $(@:.h=.d)-t + { \ + echo '/* Generated at libc build time from kernel syscall list. */';\ + echo ''; \ + echo '#ifndef _SYSCALL_H'; \ + echo '# error "Never use directly; include instead."'; \ + echo '#endif'; \ + echo ''; \ + SUNPRO_DEPENDENCIES='$(@:.h=.d)-t $@' \ + $(CC) -E -x c $(sysincludes) $< -U__sparc_v9__ -U__arch64__ -D_LIBC -dM | \ + sed -n 's@^#define __NR_\([^ ]*\) .*$$@#define SYS_\1 __NR_\1@p' | \ + LC_ALL=C sort > $(@:.d=.h).new32; \ + SUNPRO_DEPENDENCIES='$(@:.h=.d)-t $@' \ + $(CC) -E -x c $(sysincludes) $< -D__sparc_v9__ -D__arch64__ -D_LIBC -dM | \ + sed -n 's@^#define __NR_\([^ ]*\) .*$$@#define SYS_\1 __NR_\1@p' | \ + LC_ALL=C sort > $(@:.d=.h).new64; \ + if cmp -s $(@:.d=.h).new32 $(@:.d=.h).new64; then \ + cat $(@:.d=.h).new32; \ + else \ + echo '#include '; \ + echo ''; \ + comm -12 $(@:.d=.h).new32 $(@:.d=.h).new64; \ + echo '#if __WORDSIZE == 64'; \ + comm -13 $(@:.d=.h).new32 $(@:.d=.h).new64; \ + echo '#else'; \ + comm -23 $(@:.d=.h).new32 $(@:.d=.h).new64; \ + echo '#endif'; \ + fi; \ + rm -f $(@:.d=.h).new32 $(@:.d=.h).new64 \ + } > $(@:.d=.h).new + mv -f $(@:.d=.h).new $(@:.d=.h) + sed < $(@:.h=.d)-t > $(@:.h=.d)-t2 \ + -e 's,$(subst .,\.,$@),$(patsubst $(objpfx)%,$$(objpfx)%,\ + $(@:.d=.h) $(@:.h=.d)),' + rm -f $(@:.h=.d)-t + mv -f $(@:.h=.d)-t2 $(@:.h=.d) + +endif --- libc/sysdeps/unix/sysv/linux/Makefile.jj Tue Oct 17 07:18:13 2000 +++ libc/sysdeps/unix/sysv/linux/Makefile Thu Nov 9 10:50:08 2000 @@ -25,6 +25,7 @@ sysdep_headers += sys/mount.h sys/acct.h install-others += $(inst_includedir)/bits/syscall.h +ifndef no_syscall_list_h # Generate the list of SYS_* macros for the system calls (__NR_* macros). $(objpfx)syscall-%.h $(objpfx)syscall-%.d: ../sysdeps/unix/sysv/linux/sys/syscall.h rm -f $(@:.h=.d)-t @@ -45,6 +46,7 @@ $(objpfx)syscall-%.h $(objpfx)syscall-%. $(@:.d=.h) $(@:.h=.d)),' rm -f $(@:.h=.d)-t mv -f $(@:.h=.d)-t2 $(@:.h=.d) +endif $(inst_includedir)/bits/syscall.h: $(objpfx)syscall-list.h $(+force) $(make-target-directory) Jakub From drepper@redhat.com Thu Nov 9 08:34:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Thu, 09 Nov 2000 08:34:00 -0000 Subject: [PATCH] Fix LC_PAPER References: <20001109131025.U6915@sunsite.ms.mff.cuni.cz> Message-ID: Jakub Jelinek writes: > 2000-11-09 Jakub Jelinek > > * locale/programs/ld-paper.c (paper_output): Fix offset into width > field. I've applied the patch. Thanks, -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Thu Nov 9 08:44:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Thu, 09 Nov 2000 08:44:00 -0000 Subject: [PATCH] Fix LC_TIME References: <20001109134343.V6915@sunsite.ms.mff.cuni.cz> Message-ID: Jakub Jelinek writes: > 2000-11-09 Jakub Jelinek > > * locale/C-time.c (_nl_C_LC_TIME): Fix value for > _NL_TIME_WEEK_1STWEEK. This patch is OK. The value isn't present in the current 14652 draft anyway so the value doesn't matter. But I thing it's correct. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From schwidefsky@de.ibm.com Thu Nov 9 09:39:00 2000 From: schwidefsky@de.ibm.com (schwidefsky@de.ibm.com) Date: Thu, 09 Nov 2000 09:39:00 -0000 Subject: last call Message-ID: >Look at the x86 mmap.S file. We are using the mmap2 syscall even for >the mmap() and not only the mmap64() implementation. The >implementation is therefore tested in every single program run. I took x86 as sample implementation and changed s390 accordingly. The mmap2 system call itself works and mmap64 should be ok too. Here is the patch: 2000-11-09 Martin Schwidefsky * sysdeps/unix/sysv/linux/s390/mmap.S: Use mmap2 if it is present. * sysdeps/unix/sysv/linux/s390/mmap64.S: New file. (See attached file: mmap2-s390.diff) blue skies, Martin Linux/390 Design & Development, IBM Deutschland Entwicklung GmbH Sch????naicherstr. 220, D-71032 B????blingen, Telefon: 49 - (0)7031 - 16-2247 E-Mail: schwidefsky@de.ibm.com -------------- next part -------------- A non-text attachment was scrubbed... Name: mmap2-s390.diff Type: text/x-diff Size: 6768 bytes Desc: not available URL: From hjl@valinux.com Thu Nov 9 09:49:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Thu, 09 Nov 2000 09:49:00 -0000 Subject: Functions with different versions in libc and libpthread References: <20001109001530.A23552@valinux.com> Message-ID: <20001109094937.A8670@valinux.com> On Thu, Nov 09, 2000 at 12:23:18AM -0800, Ulrich Drepper wrote: > "H . J . Lu" writes: > > > Some functions have different versions in libc and libpthread. For > > example, pread has GLIBC_2.1 in libc and GLIBC_2.2 in libpthread. > > I can imagine potential problems with it. Shouldn't a fuction have > > the same verion cross all libraries? > > The names, although the same in all libraries, are completely > separated. They don't stand alone, they are used as a tuple > (library,version). It doesn't matter whether a symbol has different > names in different DSOs. > I am enclosing a testcase here taken from glibc 2.2: # ldd /usr/lib/librt.so libc.so.6 => /lib/libc.so.6 (0x40023000) libpthread.so.0 => /lib/libpthread.so.0 (0x40149000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) # make cc -D_GNU_SOURCE -I. -c -o tst-aio64.o tst-aio64.c cc -o test1 tst-aio64.o -lpthread -lrt cc -o test2 tst-aio64.o -lrt ./test1 aio_write test ok aio_read test ok lio_listio (write) test ok aio_fsync (aio_write) test ok finished3 finished2 finished ./test2 make: *** wait: No child processes. Stop. make: *** Waiting for unfinished jobs.... make: *** wait: No child processes. Stop. # nm test1 | grep pread U pread@@GLIBC_2.2 # nm test2 | grep pread U pread@@GLIBC_2.1 # ldd test2 librt.so.1 => /lib/librt.so.1 (0x40023000) libc.so.6 => /lib/libc.so.6 (0x40035000) libpthread.so.0 => /lib/libpthread.so.0 (0x4015b000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Even though libpthread.so.0 is linked with test2. But the wrong pread is used. -- H.J. Lu (hjl@valinux.com) From hjl@valinux.com Thu Nov 9 09:58:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Thu, 09 Nov 2000 09:58:00 -0000 Subject: Functions with different versions in libc and libpthread References: <20001109001530.A23552@valinux.com> <20001109094937.A8670@valinux.com> Message-ID: <20001109095819.A11305@valinux.com> On Thu, Nov 09, 2000 at 09:49:37AM -0800, H . J . Lu wrote: > On Thu, Nov 09, 2000 at 12:23:18AM -0800, Ulrich Drepper wrote: > > "H . J . Lu" writes: > > > > > Some functions have different versions in libc and libpthread. For > > > example, pread has GLIBC_2.1 in libc and GLIBC_2.2 in libpthread. > > > I can imagine potential problems with it. Shouldn't a fuction have > > > the same verion cross all libraries? > > > > The names, although the same in all libraries, are completely > > separated. They don't stand alone, they are used as a tuple > > (library,version). It doesn't matter whether a symbol has different > > names in different DSOs. > > > > I am enclosing a testcase here taken from glibc 2.2: > > # ldd /usr/lib/librt.so > libc.so.6 => /lib/libc.so.6 (0x40023000) > libpthread.so.0 => /lib/libpthread.so.0 (0x40149000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) > # make > cc -D_GNU_SOURCE -I. -c -o tst-aio64.o tst-aio64.c > cc -o test1 tst-aio64.o -lpthread -lrt > cc -o test2 tst-aio64.o -lrt > ./test1 > aio_write test ok > aio_read test ok > lio_listio (write) test ok > aio_fsync (aio_write) test ok > finished3 > finished2 > finished > ./test2 > make: *** wait: No child processes. Stop. > make: *** Waiting for unfinished jobs.... > make: *** wait: No child processes. Stop. > # nm test1 | grep pread > U pread@@GLIBC_2.2 > # nm test2 | grep pread > U pread@@GLIBC_2.1 > # ldd test2 > librt.so.1 => /lib/librt.so.1 (0x40023000) > libc.so.6 => /lib/libc.so.6 (0x40035000) > libpthread.so.0 => /lib/libpthread.so.0 (0x4015b000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) > > Even though libpthread.so.0 is linked with test2. But the wrong pread > is used. > > Ooops. Here is the testcase. -- H.J. Lu (hjl@valinux.com) -------------- next part -------------- A non-text attachment was scrubbed... Name: ver.tar.gz Type: application/x-gzip Size: 4310 bytes Desc: not available URL: From hjl@valinux.com Thu Nov 9 10:06:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Thu, 09 Nov 2000 10:06:00 -0000 Subject: A patch for io/Versions and linuxthreads/Versions Message-ID: <20001109100549.B8670@valinux.com> Here is a patch for http://sources.redhat.com/ml/libc-hacker/2000-11/msg00039.html Also we need to export __open64 since libpthread will override it. -- H.J. Lu (hjl@valinux.com) --- 2000-11-09 H.J. Lu * io/Versions (GLIBC_2.2): Add __open64. * linuxthreads/Versions (libpthread:GLIBC_2.2): Move pread, __pread64, pread64, pwrite, __pwrite64, pwrite64, lseek64 and open64 to ... (libpthread:GLIBC_2.1): Here. Index: ./io/Versions =================================================================== RCS file: /work/cvs/gnu/glibc/io/Versions,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 Versions --- ./io/Versions 2000/05/21 21:11:03 1.1.1.1 +++ ./io/Versions 2000/11/09 17:54:46 @@ -94,5 +94,7 @@ libc { GLIBC_2.2 { # p* posix_fadvise; posix_fadvise64; posix_fallocate; posix_fallocate64; + + __open64; } } Index: ./linuxthreads/Versions =================================================================== RCS file: /work/cvs/gnu/glibc/linuxthreads/Versions,v retrieving revision 1.1.1.5 diff -u -p -r1.1.1.5 Versions --- ./linuxthreads/Versions 2000/09/11 22:11:04 1.1.1.5 +++ ./linuxthreads/Versions 2000/11/09 17:54:55 @@ -113,6 +113,10 @@ libpthread { # helper functions __libc_current_sigrtmin; __libc_current_sigrtmax; __libc_allocate_rtsig; + + # For the cancelation wrappers. + pread; __pread64; pread64; pwrite; __pwrite64; pwrite64; lseek64; + open64; } GLIBC_2.1.1 { sem_close; sem_open; sem_unlink; @@ -123,8 +127,7 @@ libpthread { } GLIBC_2.2 { # For the cancelation wrappers. - pread; __pread64; pread64; pwrite; __pwrite64; pwrite64; lseek64; - open64; __open64; + __open64; __res_state; From drepper@redhat.com Thu Nov 9 10:17:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Thu, 09 Nov 2000 10:17:00 -0000 Subject: Functions with different versions in libc and libpthread References: <20001109001530.A23552@valinux.com> <20001109094937.A8670@valinux.com> Message-ID: "H . J . Lu" writes: > I am enclosing a testcase here taken from glibc 2.2: What you see has nothing to do with symbol versioning. Run test2 with --direct as the parameter. This doesn't change the lookup, it only avoids the fork. I don't know what the reason for this is but it's not symbol related. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Thu Nov 9 10:23:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Thu, 09 Nov 2000 10:23:00 -0000 Subject: A patch for io/Versions and linuxthreads/Versions References: <20001109100549.B8670@valinux.com> Message-ID: "H . J . Lu" writes: > * linuxthreads/Versions (libpthread:GLIBC_2.2): Move pread, > __pread64, pread64, pwrite, __pwrite64, pwrite64, lseek64 and > open64 to ... > (libpthread:GLIBC_2.1): Here. This is wrong. There were no such symbols in the 2.1 version. Therefore applications which as linked against 2.2 and run with 2.1 will silently fail. These are exactly the kind of things the versioning mechanism is catching. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From hjl@valinux.com Thu Nov 9 11:10:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Thu, 09 Nov 2000 11:10:00 -0000 Subject: Functions with different versions in libc and libpthread References: <20001109001530.A23552@valinux.com> <20001109094937.A8670@valinux.com> Message-ID: <20001109110955.A31531@valinux.com> On Thu, Nov 09, 2000 at 10:17:11AM -0800, Ulrich Drepper wrote: > "H . J . Lu" writes: > > > I am enclosing a testcase here taken from glibc 2.2: > > What you see has nothing to do with symbol versioning. Run test2 with > --direct as the parameter. This doesn't change the lookup, it only > avoids the fork. I don't know what the reason for this is but it's > not symbol related. > It looks like we may have 2 problems. I did # LD_DEBUG=bindings LD_DEBUG_OUTPUT=test1 ./test1 --direct # cat test1.31054 ... ' [31056: GLIBC_2.0binding file ] /lib/libpthread.so.0 to /lib/libc.so.6: 31054: normalbinding file symbol `./test1__gettimeofday to ' [/lib/libpthread.so.0GLIBC_2.0: ] normal31056: symbol `binding file pread/lib/libpthread.so.0' [ to GLIBC_2.2/lib/libc.so.6] : 31054: normalbinding file symbol `/lib/libpthread.so.0__libc_nanosleep to ' [/lib/libc.so.6GLIBC_2.0: ] normal symbol `__libc_pread' [GLIBC_2.1.3] ... # LD_DEBUG=bindings LD_DEBUG_OUTPUT=test2 ./test2 --direc # cat test2.31028 ... : 31028: normalbinding file symbol `./test2__sigsetjmp to ' [/lib/libc.so.6GLIBC_2.0: ] normal31030: symbol `binding file __fxstat/lib/libpthread.so.0' [ to GLIBC_2.0/lib/libc.so.6] : normal symbol `__gettimeofday31028: ' [binding file GLIBC_2.0./test2] to 31030: /lib/libc.so.6binding file : /lib/libpthread.so.0normal to symbol `/lib/libc.so.6pread: ' [normalGLIBC_2.1 symbol `] __libc_nanosleep' [GLIBC_2.031028: ] ... It looks like pread bound to pread@GLIBC_2.2 in libpthread.so.0 for test1 and bound pread@GLIBC_2.1 in libc.so.6 for test2. I guess "test2 --direct" may work by accident since the wrong pread is used. There may be cases where a correct pread is required. BTW, I may be able to find a testcase where the wrong pread is used even with "-lpthread -lrt" at the final link command. I think another problem may be in symbol resolution. With # gcc ... -lpthread -lrt libpthread.so.0 is searched before libc.so.6 at the run-time and with # gcc ... -lrt libpthread.so.0 is searched after libc.so.6 at the run-time. We already treat libpthread.so.0 as a special case for init. Should we also do it for symbol resolution? -- H.J. Lu (hjl@valinux.com) From drepper@redhat.com Thu Nov 9 11:18:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Thu, 09 Nov 2000 11:18:00 -0000 Subject: Functions with different versions in libc and libpthread References: <20001109001530.A23552@valinux.com> <20001109094937.A8670@valinux.com> <20001109110955.A31531@valinux.com> Message-ID: "H . J . Lu" writes: > It looks like pread bound to pread@GLIBC_2.2 in libpthread.so.0 for > test1 and bound pread@GLIBC_2.1 in libc.so.6 for test2. And this is how it must be. These are the lookup runs. If you expect the main application to use the pread from the thread library you have to link with the thread library. > I guess "test2 --direct" may work by accident since the wrong pread > is used. The --direct parameter doesn't change anything in the symbol lookup. It just avoids running the test in a forked child. > I think another problem may be in symbol resolution. With > > # gcc ... -lpthread -lrt > > libpthread.so.0 is searched before libc.so.6 at the run-time and with > > # gcc ... -lrt > > libpthread.so.0 is searched after libc.so.6 at the run-time. We already > treat libpthread.so.0 as a special case for init. Should we also do it > for symbol resolution? No. The above is exactly correct. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From hjl@valinux.com Thu Nov 9 11:23:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Thu, 09 Nov 2000 11:23:00 -0000 Subject: A patch for io/Versions and linuxthreads/Versions References: <20001109100549.B8670@valinux.com> Message-ID: <20001109112334.B31531@valinux.com> On Thu, Nov 09, 2000 at 10:22:57AM -0800, Ulrich Drepper wrote: > "H . J . Lu" writes: > > > * linuxthreads/Versions (libpthread:GLIBC_2.2): Move pread, > > __pread64, pread64, pwrite, __pwrite64, pwrite64, lseek64 and > > open64 to ... > > (libpthread:GLIBC_2.1): Here. > > This is wrong. There were no such symbols in the 2.1 version. > Therefore applications which as linked against 2.2 and run with 2.1 > will silently fail. These are exactly the kind of things the > versioning mechanism is catching. > It is very unfortunate. But I don't think there is nothing we can do about it. If there is a new symbol in linuxthreads 2.2 which must be linked with every single pthread application. In that case, any pthread application linked with 2.2 will fail with 2.1. The alternative is pthread applications in 2.2 may fail silently due to wrong functions being used. -- H.J. Lu (hjl@valinux.com) From drepper@redhat.com Thu Nov 9 11:33:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Thu, 09 Nov 2000 11:33:00 -0000 Subject: A patch for io/Versions and linuxthreads/Versions References: <20001109100549.B8670@valinux.com> <20001109112334.B31531@valinux.com> Message-ID: "H . J . Lu" writes: > If there is a new symbol in linuxthreads 2.2 which must > be linked with every single pthread application. In that case, any > pthread application linked with 2.2 will fail with 2.1. Right. That's the way it is until the ABI becomes stable. It isn't that bad anymore, you can run quite a lot of applications compiled for glibc 2.2 on 2.1 systems. Just run ldd -v on an application on a glibc 2.2 system. There is not often GLIBC_2.2 mentioned. But if it is there is a good reason. > The alternative is pthread applications in 2.2 may fail silently due > to wrong functions being used. That is what has to be avoided. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From hjl@valinux.com Thu Nov 9 12:33:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Thu, 09 Nov 2000 12:33:00 -0000 Subject: versioned_symbol and symbol_version/default_symbol_version Message-ID: <20001109123303.A3686@valinux.com> As I understand, we should use versioned_symbol instead of use symbol_version/default_symbol_version directly. Am I wrong? What is the guide line? I can see cases I want to create a glibc for ia32 without the support for the older versions. -- H.J. Lu (hjl@valinux.com) From schwab@suse.de Thu Nov 9 15:31:00 2000 From: schwab@suse.de (Andreas Schwab) Date: Thu, 09 Nov 2000 15:31:00 -0000 Subject: posix/Makefile Message-ID: <200011092331.eA9NV6011790@hawking.suse.de> The last change for make check in posix/Makefile is not enough when $(srcdir) is relative. 2000-11-10 Andreas Schwab * posix/Makefile (tst-dir-ARGS): Also handle the case when $(srcdir) is relative. --- posix/Makefile.~1.110.~ Thu Nov 9 23:55:54 2000 +++ posix/Makefile Fri Nov 10 00:29:27 2000 @@ -114,7 +114,9 @@ tst-exec-ARGS = -- $(built-program-cmd) tst-spawn-ARGS = -- $(built-program-cmd) -tst-dir-ARGS = `pwd` `cd $(common-objdir)/$(subdir); pwd` `cd $(common-objdir); pwd` $(objpfx)tst-dir +tst-dir-ARGS = `pwd` `$(patsubst %/,cd %; ,$(objpfx))pwd` \ + `cd $(common-objdir); pwd` \ + `$(patsubst %/,cd %; ,$(objpfx))pwd`/tst-dir tst-chmod-ARGS = $(objpfx) tst-fnmatch-ENV = LOCPATH=$(common-objpfx)localedata -- Andreas Schwab "And now for something SuSE Labs completely different." Andreas.Schwab@suse.de SuSE GmbH, Schanz????ckerstr. 10, D-90443 N????rnberg From drepper@redhat.com Thu Nov 9 16:17:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Thu, 09 Nov 2000 16:17:00 -0000 Subject: posix/Makefile References: <200011092331.eA9NV6011790@hawking.suse.de> Message-ID: Andreas Schwab writes: > The last change for make check in posix/Makefile is not enough when > $(srcdir) is relative. I've tried that (in srcdir, relative srcdir, absolute srcdir) and the current Makefile is OK. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Thu Nov 9 16:18:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Thu, 09 Nov 2000 16:18:00 -0000 Subject: last call References: Message-ID: schwidefsky@de.ibm.com writes: > I took x86 as sample implementation and changed s390 accordingly. The > mmap2 system call itself works and mmap64 should be ok too. There are too many should's. I'll leave that for 2.2.1. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Thu Nov 9 17:03:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Thu, 09 Nov 2000 17:03:00 -0000 Subject: 2.2 on ftp server Message-ID: Anybody with write access to ftp.gnu.org there? The release is available on sourceware and I'll send out the announcement in a bit. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From schwab@suse.de Thu Nov 9 17:10:00 2000 From: schwab@suse.de (Andreas Schwab) Date: Thu, 09 Nov 2000 17:10:00 -0000 Subject: posix/Makefile References: <200011092331.eA9NV6011790@hawking.suse.de> Message-ID: <200011100107.eAA17bK30727@hawking.suse.de> Ulrich Drepper writes: |> Andreas Schwab writes: |> |> > The last change for make check in posix/Makefile is not enough when |> > $(srcdir) is relative. |> |> I've tried that (in srcdir, relative srcdir, absolute srcdir) and the |> current Makefile is OK. Did you try with relative srcdir _and_ srcdir != objdir? That's the one which is failing. Andreas. -- Andreas Schwab "And now for something SuSE Labs completely different." Andreas.Schwab@suse.de SuSE GmbH, Schanz????ckerstr. 10, D-90443 N????rnberg From drepper@redhat.com Thu Nov 9 17:15:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Thu, 09 Nov 2000 17:15:00 -0000 Subject: posix/Makefile References: <200011092331.eA9NV6011790@hawking.suse.de> <200011100107.eAA17bK30727@hawking.suse.de> Message-ID: Andreas Schwab writes: > Did you try with relative srcdir _and_ srcdir != objdir? That's the one > which is failing. I've tried ./configure, ../configure, and /some/path/configure. If you have another case like ../some/path/configure I haven't tried it but I don't care in the moment. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From schwab@suse.de Thu Nov 9 17:20:00 2000 From: schwab@suse.de (Andreas Schwab) Date: Thu, 09 Nov 2000 17:20:00 -0000 Subject: posix/Makefile References: <200011092331.eA9NV6011790@hawking.suse.de> <200011100107.eAA17bK30727@hawking.suse.de> Message-ID: <200011100120.eAA1KP113866@hawking.suse.de> Ulrich Drepper writes: |> Andreas Schwab writes: |> |> > Did you try with relative srcdir _and_ srcdir != objdir? That's the one |> > which is failing. |> |> I've tried ./configure, ../configure, and /some/path/configure. If |> you have another case like ../some/path/configure I haven't tried it |> but I don't care in the moment. OK, that's not important enough to delay 2.2. :-) Andreas. -- Andreas Schwab "And now for something SuSE Labs completely different." Andreas.Schwab@suse.de SuSE GmbH, Schanz????ckerstr. 10, D-90443 N????rnberg From hjl@valinux.com Thu Nov 9 17:34:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Thu, 09 Nov 2000 17:34:00 -0000 Subject: A patch for io/Versions and linuxthreads/Versions References: <20001109100549.B8670@valinux.com> <20001109112334.B31531@valinux.com> Message-ID: <20001109173352.A25570@valinux.com> On Thu, Nov 09, 2000 at 11:23:34AM -0800, H . J . Lu wrote: > On Thu, Nov 09, 2000 at 10:22:57AM -0800, Ulrich Drepper wrote: > > "H . J . Lu" writes: > > > > > * linuxthreads/Versions (libpthread:GLIBC_2.2): Move pread, > > > __pread64, pread64, pwrite, __pwrite64, pwrite64, lseek64 and > > > open64 to ... > > > (libpthread:GLIBC_2.1): Here. > > > > This is wrong. There were no such symbols in the 2.1 version. > > Therefore applications which as linked against 2.2 and run with 2.1 > > will silently fail. These are exactly the kind of things the > > versioning mechanism is catching. > > > > It is very unfortunate. But I don't think there is nothing we can > do about it. If there is a new symbol in linuxthreads 2.2 which must > be linked with every single pthread application. In that case, any > pthread application linked with 2.2 will fail with 2.1. The alternative > is pthread applications in 2.2 may fail silently due to wrong functions > being used. > Here is a testcase: # make cc -g -O -c -o test.o test.c cc -o foo.os -c -g -O -fPIC foo.c cc -shared -o libfoo-1.so foo.os -lpthread cc -o test1 test.o libfoo-1.so -lpthread -Wl,-rpath,. cc -shared -o libfoo-2.so foo.os cc -o test2 test.o libfoo-2.so -lpthread -Wl,-rpath,. ./test1 open is ok pread is ok ./test2 open is ok pread is not ok make: *** [all] Error 1 The problem is libfoo-2.so is built with # cc -shared -o libfoo-2.so foo.os which binds pread to the one in libc. Later even # cc -o test2 test.o libfoo-2.so -lpthread -Wl,-rpath,. won't help. In this case, pthread applications in 2.2 may fail silently. I think we have to make sure versions in libc and linuxthreads are the same for a function. It is bad when applications linked against 2.2 may fail silently under 2.1. But it is even worse when pthread applications in 2.2 fail silently. -- H.J. Lu (hjl@valinux.com) From hjl@valinux.com Thu Nov 9 17:39:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Thu, 09 Nov 2000 17:39:00 -0000 Subject: A patch for io/Versions and linuxthreads/Versions References: <20001109100549.B8670@valinux.com> <20001109112334.B31531@valinux.com> <20001109173352.A25570@valinux.com> Message-ID: <20001109173929.A25934@valinux.com> On Thu, Nov 09, 2000 at 05:33:52PM -0800, H . J . Lu wrote: > On Thu, Nov 09, 2000 at 11:23:34AM -0800, H . J . Lu wrote: > > On Thu, Nov 09, 2000 at 10:22:57AM -0800, Ulrich Drepper wrote: > > > "H . J . Lu" writes: > > > > > > > * linuxthreads/Versions (libpthread:GLIBC_2.2): Move pread, > > > > __pread64, pread64, pwrite, __pwrite64, pwrite64, lseek64 and > > > > open64 to ... > > > > (libpthread:GLIBC_2.1): Here. > > > > > > This is wrong. There were no such symbols in the 2.1 version. > > > Therefore applications which as linked against 2.2 and run with 2.1 > > > will silently fail. These are exactly the kind of things the > > > versioning mechanism is catching. > > > > > > > It is very unfortunate. But I don't think there is nothing we can > > do about it. If there is a new symbol in linuxthreads 2.2 which must > > be linked with every single pthread application. In that case, any > > pthread application linked with 2.2 will fail with 2.1. The alternative > > is pthread applications in 2.2 may fail silently due to wrong functions > > being used. > > > > Here is a testcase: > > # make > cc -g -O -c -o test.o test.c > cc -o foo.os -c -g -O -fPIC foo.c > cc -shared -o libfoo-1.so foo.os -lpthread > cc -o test1 test.o libfoo-1.so -lpthread -Wl,-rpath,. > cc -shared -o libfoo-2.so foo.os > cc -o test2 test.o libfoo-2.so -lpthread -Wl,-rpath,. > ./test1 > open is ok > pread is ok > ./test2 > open is ok > pread is not ok > make: *** [all] Error 1 > > The problem is libfoo-2.so is built with > > # cc -shared -o libfoo-2.so foo.os > > which binds pread to the one in libc. Later even > > # cc -o test2 test.o libfoo-2.so -lpthread -Wl,-rpath,. > > won't help. In this case, pthread applications in 2.2 may fail > silently. I think we have to make sure versions in libc and > linuxthreads are the same for a function. It is bad when applications > linked against 2.2 may fail silently under 2.1. But it is even worse > when pthread applications in 2.2 fail silently. > Ooops. Here is a testcase. -- H.J. Lu (hjl@valinux.com) -------------- next part -------------- A non-text attachment was scrubbed... Name: sym2.tar.gz Type: application/x-gzip Size: 579 bytes Desc: not available URL: From drepper@redhat.com Thu Nov 9 17:39:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Thu, 09 Nov 2000 17:39:00 -0000 Subject: thanks! Message-ID: The announcement is out, the CVS sources currently get tagged. We're done for 2.2. Thanks a lot to everybody who helped making the release possible. Not everybody will be happy but there will always be a next release. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From hjl@valinux.com Thu Nov 9 17:43:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Thu, 09 Nov 2000 17:43:00 -0000 Subject: glibc 2.2 and versions in libc and linuxthreads Message-ID: <20001109174321.A25539@valinux.com> I'd like to resolve this: http://sources.redhat.com/ml/libc-hacker/2000-11/msg00057.html before it is too late. I think this bug may be unique to Linux. -- H.J. Lu (hjl@valinux.com) From drepper@redhat.com Thu Nov 9 17:59:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Thu, 09 Nov 2000 17:59:00 -0000 Subject: glibc 2.2 and versions in libc and linuxthreads References: <20001109174321.A25539@valinux.com> Message-ID: "H . J . Lu" writes: > I'd like to resolve this: > > http://sources.redhat.com/ml/libc-hacker/2000-11/msg00057.html > > before it is too late. I think this bug may be unique to Linux. All tries of you to handle this I've seen so far are wrong. There must not be any assumption being made on the version names in different DSOs. Initially we thought about using different names altogether but dropped the idea. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From hjl@valinux.com Thu Nov 9 18:09:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Thu, 09 Nov 2000 18:09:00 -0000 Subject: glibc 2.2 and versions in libc and linuxthreads References: <20001109174321.A25539@valinux.com> Message-ID: <20001109180920.B26521@valinux.com> On Thu, Nov 09, 2000 at 05:58:39PM -0800, Ulrich Drepper wrote: > "H . J . Lu" writes: > > > I'd like to resolve this: > > > > http://sources.redhat.com/ml/libc-hacker/2000-11/msg00057.html > > > > before it is too late. I think this bug may be unique to Linux. > > All tries of you to handle this I've seen so far are wrong. There Do you have any suggestions for my testcase? > must not be any assumption being made on the version names in > different DSOs. Initially we thought about using different names I disagree. If a definition from one library is designed to override the one from another library, I believe both name and version should match. Otherwise, we will see problems like my testcase. To take it further, assume one day we want GLIBC_2.2 for pread in libc and the one in linuxthreads has to be changed also, what do we do? > altogether but dropped the idea. > If we had done that, we might have seen thread applications failures long time ago. Why do we have both GLIBC_2_0 and GLIBC_2_1 for pthread_attr_init in libc? They are the same in libc. If the name doesn't matter, why bother with GLIBC_2_0 and GLIBC_2_1? -- H.J. Lu (hjl@valinux.com) From hjl@valinux.com Thu Nov 9 19:18:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Thu, 09 Nov 2000 19:18:00 -0000 Subject: lockf64 and GLIBC_2.1/GLIBC_2.1.1 Message-ID: <20001109191818.A7537@valinux.com> Why does lockf64 have both GLIBC_2.1 and GLIBC_2.1.1? In fact, only GLIBC_2.1 is really defined. I guess GLIBC_2.1 was mistake. But it is too late to change now. Here is a patch. -- H.J. Lu (hjl@valinux.com) --- 2000-11-09 H.J. Lu * io/Versions (GLIBC_2.1.1): Remove lockf64. Index: ./io/Versions =================================================================== RCS file: /work/cvs/gnu/glibc/io/Versions,v retrieving revision 1.1.1.2 diff -u -p -r1.1.1.2 Versions --- ./io/Versions 2000/11/09 19:29:10 1.1.1.2 +++ ./io/Versions 2000/11/10 03:15:56 @@ -83,10 +83,6 @@ libc { # s* statfs64; statvfs; statvfs64; } - GLIBC_2.1.1 { - # l* - lockf64; - } GLIBC_2.1.3 { # For the cancelation wrappers. __libc_open64; __libc_lseek64; From drepper@redhat.com Thu Nov 9 19:32:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Thu, 09 Nov 2000 19:32:00 -0000 Subject: lockf64 and GLIBC_2.1/GLIBC_2.1.1 References: <20001109191818.A7537@valinux.com> Message-ID: "H . J . Lu" writes: > Why does lockf64 have both GLIBC_2.1 and GLIBC_2.1.1? In fact, only > GLIBC_2.1 is really defined. I guess GLIBC_2.1 was mistake. But it > is too late to change now. Here is a patch. That's correct. But this is no problem, the binaries are created correctly. What isn't correct is probably that it was added to 2.1 in the first place and the consequence is that a binary linked against 2.1 might silently crash. But this cannot be changed anymore and apparently was no real problem. Thanks. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Thu Nov 9 19:35:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Thu, 09 Nov 2000 19:35:00 -0000 Subject: last call References: Message-ID: schwidefsky@de.ibm.com writes: > 2000-11-09 Martin Schwidefsky > > * sysdeps/unix/sysv/linux/s390/mmap.S: Use mmap2 if it is present. > * sysdeps/unix/sysv/linux/s390/mmap64.S: New file. The patch is now applied. Thanks, -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From hjl@valinux.com Thu Nov 9 19:53:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Thu, 09 Nov 2000 19:53:00 -0000 Subject: More problems like (Re: lockf64 and GLIBC_2.1/GLIBC_2.1.1) References: <20001109191818.A7537@valinux.com> Message-ID: <20001109195325.B7537@valinux.com> On Thu, Nov 09, 2000 at 07:31:57PM -0800, Ulrich Drepper wrote: > "H . J . Lu" writes: > > > Why does lockf64 have both GLIBC_2.1 and GLIBC_2.1.1? In fact, only > > GLIBC_2.1 is really defined. I guess GLIBC_2.1 was mistake. But it > > is too late to change now. Here is a patch. > > That's correct. But this is no problem, the binaries are created > correctly. What isn't correct is probably that it was added to 2.1 in > the first place and the consequence is that a binary linked against > 2.1 might silently crash. But this cannot be changed anymore and > apparently was no real problem. Thanks. > We may have more problems like that :-).. Here is a patch. H.J. ---- 2000-11-09 H.J. Lu * sunrpc/Versions (GLIBC_2.1): Remove xdr_cryptkeyarg, xdr_cryptkeyarg2, xdr_cryptkeyres, xdr_des_block, xdr_key_netstarg, xdr_key_netstres, xdr_keybuf and xdr_keystatus. * time/Versions (GLIBC_2.1): Remove getitimer. Index: sunrpc/Versions =================================================================== RCS file: /work/cvs/gnu/glibc/sunrpc/Versions,v retrieving revision 1.1.1.2 diff -u -p -r1.1.1.2 Versions --- sunrpc/Versions 2000/08/03 00:32:12 1.1.1.2 +++ sunrpc/Versions 2000/11/10 03:32:54 @@ -98,9 +98,8 @@ libc { # x* xdecrypt; xdr_authdes_cred; xdr_authdes_verf; - xdr_cryptkeyarg; xdr_cryptkeyarg2; xdr_cryptkeyres; xdr_des_block; - xdr_getcredres; xdr_int16_t; xdr_int32_t; xdr_int8_t; xdr_key_netstarg; - xdr_key_netstres; xdr_keybuf; xdr_keystatus; xdr_netnamestr; xdr_sizeof; + xdr_getcredres; xdr_int16_t; xdr_int32_t; xdr_int8_t; + xdr_netnamestr; xdr_sizeof; xdr_uint16_t; xdr_uint32_t; xdr_uint8_t; xdr_unixcred; } GLIBC_2.1.1 { Index: time/Versions =================================================================== RCS file: /work/cvs/gnu/glibc/time/Versions,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 Versions --- time/Versions 2000/05/21 21:12:03 1.1.1.1 +++ time/Versions 2000/11/10 03:31:26 @@ -44,7 +44,7 @@ libc { getdate_err; # g* - getdate; getdate_r; getitimer; + getdate; getdate_r; } GLIBC_2.2 { # w* From drepper@redhat.com Thu Nov 9 20:33:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Thu, 09 Nov 2000 20:33:00 -0000 Subject: More problems like (Re: lockf64 and GLIBC_2.1/GLIBC_2.1.1) References: <20001109191818.A7537@valinux.com> <20001109195325.B7537@valinux.com> Message-ID: "H . J . Lu" writes: > We may have more problems like that :-).. Here is a patch. Not quite. There are cases where the version definition is simply in the wrong file. E.g., the getitimer version is needed for Linux/Alpha and therefore belongs into the file sysdeps/unix/sysv/linux/alpha/Versions. Please check this before simply removing the definition. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From hjl@valinux.com Thu Nov 9 20:55:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Thu, 09 Nov 2000 20:55:00 -0000 Subject: More problems like (Re: lockf64 and GLIBC_2.1/GLIBC_2.1.1) References: <20001109191818.A7537@valinux.com> <20001109195325.B7537@valinux.com> Message-ID: <20001109205522.A11949@valinux.com> On Thu, Nov 09, 2000 at 08:33:25PM -0800, Ulrich Drepper wrote: > "H . J . Lu" writes: > > > We may have more problems like that :-).. Here is a patch. > > Not quite. There are cases where the version definition is simply in > the wrong file. E.g., the getitimer version is needed for Linux/Alpha > and therefore belongs into the file > sysdeps/unix/sysv/linux/alpha/Versions. Please check this before > simply removing the definition. > Here is the new patch. -- H.J. Lu (hjl@valinux.com) --- 2000-11-09 H.J. Lu * time/Versions (GLIBC_2.1): Move getitimer to ... * sysdeps/unix/sysv/linux/alpha/Versions (GLIBC_2.1): Here. Index: sysdeps/unix/sysv/linux/alpha/Versions =================================================================== RCS file: /work/cvs/gnu/glibc-2.1/sysdeps/unix/sysv/linux/alpha/Versions,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 Versions --- sysdeps/unix/sysv/linux/alpha/Versions 1998/07/15 00:23:42 1.1.1.1 +++ sysdeps/unix/sysv/linux/alpha/Versions 2000/11/10 04:52:15 @@ -32,7 +32,7 @@ libc { getrusage; # time type change - gettimeofday; + gettimeofday; getitimer; # i* ieee_get_fp_control; ieee_set_fp_control; Index: time/Versions =================================================================== RCS file: /work/cvs/gnu/glibc-2.1/time/Versions,v retrieving revision 1.1.1.2 diff -u -p -r1.1.1.2 Versions --- time/Versions 1999/01/30 00:03:09 1.1.1.2 +++ time/Versions 2000/11/10 03:30:40 @@ -44,6 +44,6 @@ libc { getdate_err; # g* - getdate; getdate_r; getitimer; + getdate; getdate_r; } } From drepper@redhat.com Thu Nov 9 21:05:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Thu, 09 Nov 2000 21:05:00 -0000 Subject: More problems like (Re: lockf64 and GLIBC_2.1/GLIBC_2.1.1) References: <20001109191818.A7537@valinux.com> <20001109195325.B7537@valinux.com> <20001109205522.A11949@valinux.com> Message-ID: "H . J . Lu" writes: > Here is the new patch. I've already made this change. Thanks, -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From hjl@valinux.com Thu Nov 9 22:09:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Thu, 09 Nov 2000 22:09:00 -0000 Subject: More problems like (Re: lockf64 and GLIBC_2.1/GLIBC_2.1.1) References: <20001109191818.A7537@valinux.com> <20001109195325.B7537@valinux.com> <20001109205522.A11949@valinux.com> Message-ID: <20001109220934.A16637@valinux.com> On Thu, Nov 09, 2000 at 09:05:01PM -0800, Ulrich Drepper wrote: > "H . J . Lu" writes: > > > Here is the new patch. > > I've already made this change. Thanks, > I saw the entries in ChangeLog for sunrpc/Versions and time/Versions, but no changes in sunrpc/Versions nor time/Versions. -- H.J. Lu (hjl@valinux.com) From drepper@redhat.com Thu Nov 9 22:25:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Thu, 09 Nov 2000 22:25:00 -0000 Subject: More problems like (Re: lockf64 and GLIBC_2.1/GLIBC_2.1.1) References: <20001109191818.A7537@valinux.com> <20001109195325.B7537@valinux.com> <20001109205522.A11949@valinux.com> <20001109220934.A16637@valinux.com> Message-ID: "H . J . Lu" writes: > I saw the entries in ChangeLog for sunrpc/Versions and time/Versions, > but no changes in sunrpc/Versions nor time/Versions. I got interrupted. It's all checked in now. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From aj@suse.de Thu Nov 9 23:27:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Thu, 09 Nov 2000 23:27:00 -0000 Subject: thanks! References: Message-ID: >>>>> Ulrich Drepper writes: > The announcement is out, the CVS sources currently get tagged. We're > done for 2.2. > Thanks a lot to everybody who helped making the release possible. Not > everybody will be happy but there will always be a next release. We should say a really big THANKS to you, Uli for the enormous effort you're putting into glibc! THANKS, Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From aj@suse.de Thu Nov 9 23:27:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Thu, 09 Nov 2000 23:27:00 -0000 Subject: 2.2 on ftp server References: Message-ID: >>>>> Ulrich Drepper writes: > Anybody with write access to ftp.gnu.org there? The release is > available on sourceware and I'll send out the announcement in a bit. I'm uploading the following files now: glibc-2.2.tar.gz glibc-linuxthreads-2.2.tar.gz nss_db-2.2.tar.gz Anything else? Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From aj@suse.de Thu Nov 9 23:42:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Thu, 09 Nov 2000 23:42:00 -0000 Subject: 2.2 on ftp server References: Message-ID: >>>>> Andreas Jaeger writes: >>>>> Ulrich Drepper writes: >> Anybody with write access to ftp.gnu.org there? The release is >> available on sourceware and I'll send out the announcement in a bit. > I'm uploading the following files now: > glibc-2.2.tar.gz > glibc-linuxthreads-2.2.tar.gz > nss_db-2.2.tar.gz > Anything else? I found it out myself;-) I'm uploading also: nss_lwres-0.91.tar.gz but it might take some minutes, the connection between sourceware and ftp.gnu.org seems to be very slow :-(. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From drepper@redhat.com Thu Nov 9 23:47:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Thu, 09 Nov 2000 23:47:00 -0000 Subject: 2.2 on ftp server References: Message-ID: Andreas Jaeger writes: > Anything else? nss_lwres. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Thu Nov 9 23:48:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Thu, 09 Nov 2000 23:48:00 -0000 Subject: 2.2 on ftp server References: Message-ID: Andreas Jaeger writes: > but it might take some minutes, the connection between sourceware and > ftp.gnu.org seems to be very slow :-(. Physically they are the enormous distance of perhaps 3-4km away. Thanks, Mae-West! Thanks for loading the files up. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From aj@suse.de Fri Nov 10 01:12:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Fri, 10 Nov 2000 01:12:00 -0000 Subject: 2.2 on ftp server References: Message-ID: >>>>> Ulrich Drepper writes: > Andreas Jaeger writes: >> but it might take some minutes, the connection between sourceware and >> ftp.gnu.org seems to be very slow :-(. > Physically they are the enormous distance of perhaps 3-4km away. > Thanks, Mae-West! > Thanks for loading the files up. Everything is uploaded to ftp.gnu.org - if anything is missing or wrong, please tell me asap. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From aj@suse.de Fri Nov 10 03:31:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Fri, 10 Nov 2000 03:31:00 -0000 Subject: possible AT_PLATFORMs? Message-ID: I just noticed that ldconfig doesn't handle AT_PLATFORM correctly, e.g. on my system /lib/i686 is not checked by ldconfig - but this is done by ld.so: 01300: search path=/lib/i686/mmx:/lib/i686:/lib/mmx:/lib:/usr/lib/i686/mmx:/usr/lib/i686:/usr/lib/mmx:/usr/lib (system search path) 01300: trying file=/lib/i686/mmx/libc.so.6 01300: trying file=/lib/i686/libc.so.6 01300: trying file=/lib/mmx/libc.so.6 01300: trying file=/lib/libc.so.6 LD_SHOW_AUXV gives you the platform: $ LD_SHOW_AUXV=1 ls AT_PHDR: 0x8048034 AT_PHNUM: 6 AT_PAGESZ: 4096 AT_BASE: 0x40000000 AT_ENTRY: 0x80490e0 AT_UID: 0 AT_EUID: 0 AT_GID: 0 AT_EGID: 0 AT_HWCAP: fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 22 mmx osfxsr 30 amd3d AT_PLATFORM: i686 Can the port maintainers please send me all possible AT_PLATFORM strings for their ports? I'd like to fix ldconfig to properly handle AT_PLATFORM. Thanks, Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From hjl@valinux.com Fri Nov 10 11:28:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Fri, 10 Nov 2000 11:28:00 -0000 Subject: glibc 2.2 and versions in libc and linuxthreads References: <20001109174321.A25539@valinux.com> <20001109180920.B26521@valinux.com> Message-ID: <20001110112828.A17808@valinux.com> On Thu, Nov 09, 2000 at 06:09:20PM -0800, H . J . Lu wrote: > On Thu, Nov 09, 2000 at 05:58:39PM -0800, Ulrich Drepper wrote: > > "H . J . Lu" writes: > > > > > I'd like to resolve this: > > > > > > http://sources.redhat.com/ml/libc-hacker/2000-11/msg00057.html > > > > > > before it is too late. I think this bug may be unique to Linux. > > > > All tries of you to handle this I've seen so far are wrong. There > > Do you have any suggestions for my testcase? > > > must not be any assumption being made on the version names in > > different DSOs. Initially we thought about using different names > > I disagree. If a definition from one library is designed to override > the one from another library, I believe both name and version should > match. Otherwise, we will see problems like my testcase. > > To take it further, assume one day we want GLIBC_2.2 for pread in libc > and the one in linuxthreads has to be changed also, what do we do? > > > altogether but dropped the idea. > > > > If we had done that, we might have seen thread applications failures > long time ago. Why do we have both GLIBC_2_0 and GLIBC_2_1 for > pthread_attr_init in libc? They are the same in libc. If the name > doesn't matter, why bother with GLIBC_2_0 and GLIBC_2_1? > Please also take a look at elf/Versions. We have made sure that symbols in ld.so overridden by libc.so have the same name and version. We simply cannot have different version names in different DSOs and expect one will always override the other. Here is my revised patch. If we don't want pthread applications linked against glibc 2.2 to fail silently under 2.1, we can drag in GLIBC_2_2 so that they will always fail. I think it is a small price to pay, comparing with some pthread applications fail silently under glibc 2.2. I hope this issue will be resolved before it is too late. -- H.J. Lu (hjl@valinux.com) --- 2000-11-10 H.J. Lu * linuxthreads/Versions (libpthread:GLIBC_2.2): Move pread, __pread64, pread64, pwrite, __pwrite64, pwrite64, lseek64 and open64 to ... (libpthread:GLIBC_2.1): Here. * csu/init.c (glibc_2_2): New. Drag in GLIBC_2.2 for pthread applications. Index: linuxthreads/Versions =================================================================== RCS file: /work/cvs/gnu/glibc/linuxthreads/Versions,v retrieving revision 1.1.1.5 diff -u -p -r1.1.1.5 Versions --- linuxthreads/Versions 2000/09/11 22:11:04 1.1.1.5 +++ linuxthreads/Versions 2000/11/10 17:14:26 @@ -113,6 +113,10 @@ libpthread { # helper functions __libc_current_sigrtmin; __libc_current_sigrtmax; __libc_allocate_rtsig; + + # For the cancelation wrappers. + pread; __pread64; pread64; pwrite; __pwrite64; pwrite64; lseek64; + open64; } GLIBC_2.1.1 { sem_close; sem_open; sem_unlink; @@ -123,8 +127,7 @@ libpthread { } GLIBC_2.2 { # For the cancelation wrappers. - pread; __pread64; pread64; pwrite; __pwrite64; pwrite64; lseek64; - open64; __open64; + __open64; __res_state; Index: csu/init.c =================================================================== RCS file: /work/cvs/gnu/glibc/csu/init.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 init.c --- csu/init.c 2000/05/21 21:10:57 1.1.1.1 +++ csu/init.c 2000/11/10 19:25:08 @@ -33,4 +33,12 @@ /* This records which stdio is linked against in the application. */ const int _IO_stdin_used = _G_IO_IO_FILE_VERSION; +/* Since we have to add pread, __pread64, pread64, pwrite, __pwrite64, + pwrite64, lseek64 and open64 to libpthread:GLIBC_2.1 in glibc 2.2, + we have to make sure pthread applications linked against glibc 2.2 + will fail to run under glibc 2.1 by dragging in GLIBC_2.2 for + pthread applications. */ +extern void __pthread_initialize_minimal (void) __attribute__ ((weak)); +static const void * const glibc_2_2 __attribute__ ((unused)) + = (void *) &__pthread_initialize_minimal; #endif From bmark@us.ibm.com Fri Nov 10 15:00:00 2000 From: bmark@us.ibm.com (Mark Brown) Date: Fri, 10 Nov 2000 15:00:00 -0000 Subject: announcement text References: Message-ID: <3A0C7E06.38DE6B2@us.ibm.com> Ulrich- Here is a diff of edits to the announce document; I can send you the edited text if need be (diif -e or whatever). I have mostly done syntax and other readability changes. cheers, Mark $diff announce.edited ANNOUNCE 56,62c56,61 < to damage one's system. Therefore persons who do not exactly know < what to do should consider using a binary distribution instead, when < they become available. We recommend that all Linux distributors < base their next release on glibc 2.2. < < The system requirements for building glibc from the source are another < reason to avoid using this method: on Intel platforms the full --- > to damage one's system. Therefore, persons who do not exactly know > what to do, should consider using a binary distribution instead, when > they become available. All major Linux distributors will hopefully > base their next release on glibc 2.2. Don't tell us you haven't been > warned. Another reason why not everybody should think about compiling > glibc is the disk and CPU requirements: on Intel platforms the full 65,67c64,66 < the compiler will need large amounts of virtual memory, on the order < of 100MB on Intel and 200MB on Alpha. If the `-j' option of make < is used, these numbers grow linearly. Building the complete --- > the compiler will need large amounts of virtual memory. We are > talking about 100MB on Intel and 200MB on Alpha. If using the `-j' > option of make these numbers grow linearly. Building the complete 69,71c68,70 < adds another 8 minutes. On slower or un-tuned systems the < times are very much higher and it can possibly take several days on < older systems. The use of the -j option for make is very --- > adds another 8 minutes. On not highly tuned and slower systems the > times are very much higher and it possibly takes several days on very > old and slow systems. The use of the -j option for make is very 74c73 < In case you decide to compile glibc yourself you should read the --- > In case you decide to compile glibc yourself you need to read the 76c75 < are necessary. The most important tool is the compiler: although --- > are necessary. The most important one is the compiler. Although 88,92c87,90 < If you wish to compile or work with glibc sources on architectures < which are newly supported, you most probably need some development < version of the tools. The requirements for MIPS are described in < the FAQ. For others contact the developers working on tools for < the specific architecture. --- > Architectiure which are supported for a short time only you most > probably need some development version of the tools. The requirements > for MIPS are described in the FAQ. For others contact the developers > working on tools for the specific architecture. 95c93 < On systems with newer Linux kernels the configure script has a new option --- > One Linux systems the configure script has a new option 97,102c95,101 < options allows you to strip out code for compatibility with older kernel < versions. This is of interest since configuring for a 2.4.0 kernel < reduces the libc size by about 1%. This is not a high percentage but all < the code size reduced is in the most often used functions. Performance < is enhanced with this option, at the expense of incompatibility with < older kernels. If you never expect to run kernel versions older than --- > options allows to strip out code for compatibility with older kernel > versions. This is interest since configuring for a 2.4.0 kernel > reduces the libc size by about 1%. This is no high percentage but all > the code gone is in the by far most often used functions. The > compatibility code is needed because of poor design decisions of the > kernel developers who constantly have to adjust the interface to new > requirements. If you never expect to run kernel versions older than 105c104 < older kernel applications won't even start and the whole system might be --- > older kernel program won't even start and the whole system might be 110,113c109,113 < releases. Application binaries built with glibc 2.1 and earlier should < run on systems using glibc 2.2. However, application binaries built using < glibc 2.2 will not run on systems using earlier version of glibc, and in < fact will not even load. --- > releases. All programs should continue to run. This does *not* mean > that programs compiled on a system running glibc 2.2 will run on > system only have glibc 2.1 available. Compatibility is always in one > direction. Systems with glibc 2.1 will not even attempt to run > binaries generated with glibc 2.2 so there is not much to worry about. END Mark From bmark@us.ibm.com Fri Nov 10 15:02:00 2000 From: bmark@us.ibm.com (Mark Brown) Date: Fri, 10 Nov 2000 15:02:00 -0000 Subject: thanks! References: Message-ID: <3A0C7E8D.99FE6EC9@us.ibm.com> Uli- I would like to second Andreas' thanks to Ulrich. Good Job. (and I'm sorry my edits for the announce were late. No damage done.) Mark -- Mark S. Brown bmark@us.ibm.com Senior Technical Staff Member 512.838.3926 T/L678.3926 IBM RS/6000 AIX System Architecture Mark Brown/Austin/IBM IBM Corporation, Austin, Texas From hjl@valinux.com Fri Nov 10 21:09:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Fri, 10 Nov 2000 21:09:00 -0000 Subject: A patch for sysdeps/ia64/fpu/libm-test-ulps Message-ID: <20001110210921.A5737@valinux.com> This patch is needed for math/libm-test.inc change made on 2000-10-26 by Jakub Jelinek . -- H.J. Lu (hjl@valinux.com) -- 2000-11-10 H.J. Lu * sysdeps/ia64/fpu/libm-test-ulps: Updated. Index: sysdeps/ia64/fpu/libm-test-ulps =================================================================== RCS file: /work/cvs/gnu/glibc/sysdeps/ia64/fpu/libm-test-ulps,v retrieving revision 1.1.1.3 diff -u -p -r1.1.1.3 libm-test-ulps --- sysdeps/ia64/fpu/libm-test-ulps 2000/11/07 01:29:42 1.1.1.3 +++ sysdeps/ia64/fpu/libm-test-ulps 2000/11/11 05:02:51 @@ -19,7 +19,7 @@ ifloat: 2 Test "asin (0.5) == pi/6": float: 2 ifloat: 2 -Test "asin (0.7) == 0.7753974966107530637": +Test "asin (0.7) == 0.77539749661075306374035335271498708": float: 2 ifloat: 2 double: 1 @@ -290,14 +290,14 @@ float: 1 ifloat: 1 ildouble: 18 ldouble: 18 -Test "Real part of: cexp (0.7 + 1.2 i) == 0.7296989091503236012 + 1.8768962328348102821 i": +Test "Real part of: cexp (0.7 + 1.2 i) == 0.72969890915032360123451688642930727 + 1.8768962328348102821139467908203072 i": float: 1 ifloat: 1 double: 1 idouble: 1 ildouble: 940 ldouble: 940 -Test "Imaginary part of: cexp (0.7 + 1.2 i) == 0.7296989091503236012 + 1.8768962328348102821 i": +Test "Imaginary part of: cexp (0.7 + 1.2 i) == 0.72969890915032360123451688642930727 + 1.8768962328348102821139467908203072 i": float: 1 ifloat: 1 ildouble: 1067 @@ -424,7 +424,7 @@ idouble: 1 ifloat: 1 # cos -Test "cos (0.7) == 0.7648421872844884262": +Test "cos (0.7) == 0.76484218728448842625585999019186495": float: 1 ifloat: 1 double: 1 @@ -629,7 +629,7 @@ double: 2 idouble: 2 ildouble: 818 ldouble: 818 -Test "exp10 (0.7) == 5.0118723362727228500": +Test "exp10 (0.7) == 5.0118723362727228500155418688494574": float: 1 ifloat: 1 double: 1 @@ -914,7 +914,7 @@ ldouble: 627 Test "sincos (0.7, &sin_res, &cos_res) puts 0.64421768723769105367 in sin_res": ildouble: 627 ldouble: 627 -Test "sincos (0.7, &sin_res, &cos_res) puts 0.76484218728448842626 in cos_res": +Test "sincos (0.7, &sin_res, &cos_res) puts 0.76484218728448842625585999019186495 in cos_res": float: 1 ifloat: 1 double: 1 @@ -926,7 +926,7 @@ double: 1 float: 0.5 idouble: 1 ifloat: 0.5 -Test "sincos (M_PI_6l*2.0, &sin_res, &cos_res) puts 0.866025403784438646764 in sin_res": +Test "sincos (M_PI_6l*2.0, &sin_res, &cos_res) puts 0.86602540378443864676372317075293616 in sin_res": double: 1 float: 1 idouble: 1 @@ -940,7 +940,7 @@ idouble: 0.2758 ifloat: 0.3667 ildouble: 0.25 ldouble: 0.25 -Test "sincos (pi/6, &sin_res, &cos_res) puts 0.866025403784438646764 in cos_res": +Test "sincos (pi/6, &sin_res, &cos_res) puts 0.86602540378443864676372317075293616 in cos_res": float: 1 ifloat: 1 From hjl@valinux.com Fri Nov 10 21:20:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Fri, 10 Nov 2000 21:20:00 -0000 Subject: Set LANGUAGE=C LC_ALL=C for make install Message-ID: <20001110212031.A6133@valinux.com> If LANGUAGE=C LC_ALL=C is recommended for make install, why not set them for make install in Makefile? Here is a patch. -- H.J. Lu (hjl@valinux.com) --- 2000-11-10 H.J. Lu * Makefile.in (install): Set LANGUAGE=C LC_ALL=C. Index: Makefile.in =================================================================== RCS file: /work/cvs/gnu/glibc/Makefile.in,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 Makefile.in --- Makefile.in 2000/05/21 21:10:56 1.1.1.1 +++ Makefile.in 2000/11/11 05:17:20 @@ -12,3 +12,7 @@ srcdir = @srcdir@ all .DEFAULT: $(MAKE) -r PARALLELMFLAGS="$(PARALLELMFLAGS)" CVSOPTS="$(CVSOPTS)" -C $(srcdir) objdir=`pwd` $@ + +install: + LANGUAGE=C LC_ALL=C; export LANGUAGE LC_ALL; \ + $(MAKE) -r PARALLELMFLAGS="$(PARALLELMFLAGS)" CVSOPTS="$(CVSOPTS)" -C $(srcdir) objdir=`pwd` $@ From aj@suse.de Sun Nov 12 01:08:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Sun, 12 Nov 2000 01:08:00 -0000 Subject: GNATS work Message-ID: Hi, I'm currently working together with the FSF folks to get GNATS working again. I can query the database when logged into one of the FSF machines but the Webinterface is still broken. I'll keep you updated about the progress. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From aj@suse.de Mon Nov 13 04:44:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Mon, 13 Nov 2000 04:44:00 -0000 Subject: Handle platforms Message-ID: The dynamic linker searches a platform specific directory first, e.g. on i686 before looking in /lib, /lib/i686 is searched. This wasn't implemented in ldconfig so far. Here's a patch to add this. I've used some unused bits of the hwcap entry. Andreas 2000-11-13 Andreas Jaeger * elf/cache.c (struct cache_entry): Use uint64_t for hwcap. (print_entry): Likewise. (add_to_cache): Likewise. * elf/ldconfig.h (add_to_cache): Change prototype for hwcap change. * elf/ldconfig.c (struct lib_entry): Use uint64_t for hwcap. (path_hwcap): Likewise. (search_dir): Likewise. * sysdeps/generic/dl-cache.c (HWCAP_CHECK): Handle platform. * elf/cache.c (add_to_cache): Handle 64 bit hwcap entry. * sysdeps/unix/sysv/linux/sparc/sparc32/dl-procinfo.h (_dl_platform_string): New. (_DL_HWCAP_PLATFORM): New. (_dl_string_platform): New. * sysdeps/unix/sysv/linux/sparc/sparc64/dl-procinfo.h: Likewise. * sysdeps/generic/dl-procinfo.h (_DL_HWCAP_COUNT): New. (_dl_string_platform): New. (_DL_HWCAP_PLATFORM): New. (_dl_platform_string): New. * sysdeps/unix/sysv/linux/i386/dl-procinfo.h: Added x86 platform recognition. (_DL_HWCAP_COUNT): New. (_dl_string_platform): New. (_DL_HWCAP_PLATFORM): New. (_dl_platform_string): New. ============================================================ Index: elf/cache.c --- elf/cache.c 2000/09/30 03:17:35 1.9 +++ elf/cache.c 2000/11/13 12:41:49 @@ -25,6 +25,7 @@ #include #include #include +#include #include #include #include @@ -38,7 +39,7 @@ char *lib; /* Library name. */ char *path; /* Path to find library. */ int flags; /* Flags to indicate kind of library. */ - unsigned long int hwcap; /* Important hardware capabilities. */ + uint64_t hwcap; /* Important hardware capabilities. */ int bits_hwcap; /* Number of bits set in hwcap. */ struct cache_entry *next; /* Next entry in list. */ }; @@ -51,7 +52,7 @@ /* Print a single entry. */ static void -print_entry (const char *lib, int flag, unsigned long int hwcap, const char *key) +print_entry (const char *lib, int flag, uint64_t hwcap, const char *key) { printf ("\t%s (", lib); switch (flag & FLAG_TYPE_MASK) @@ -83,7 +84,7 @@ break; } if (hwcap != 0) - printf (", hwcap: 0x%lx", hwcap); + printf (", hwcap: 0x%Lx", hwcap); printf (") => %s\n", key); } @@ -411,7 +412,7 @@ /* Add one library to the cache. */ void add_to_cache (const char *path, const char *lib, int flags, - unsigned long int hwcap) + uint64_t hwcap) { struct cache_entry *new_entry, *ptr, *prev; char *full_path; @@ -431,8 +432,8 @@ new_entry->bits_hwcap = 0; /* Count the number of bits set in the masked value. */ - for (i = 0; (~((1UL << i) - 1) & hwcap) != 0; ++i) - if ((hwcap & (1UL << i)) != 0) + for (i = 0; (~((1ULL << i) - 1) & hwcap) != 0; ++i) + if ((hwcap & (1ULL << i)) != 0) ++new_entry->bits_hwcap; ============================================================ Index: elf/ldconfig.h --- elf/ldconfig.h 2000/09/30 21:45:53 1.6 +++ elf/ldconfig.h 2000/11/13 12:41:49 @@ -39,7 +39,7 @@ extern void save_cache (const char *cache_name); extern void add_to_cache (const char *path, const char *lib, int flags, - unsigned long int hwcap); + uint64_t hwcap); /* Declared in readlib.c. */ extern int process_file (const char *real_file_name, const char *file_name, ============================================================ Index: elf/ldconfig.c --- elf/ldconfig.c 2000/11/10 14:06:06 1.12 +++ elf/ldconfig.c 2000/11/13 12:41:49 @@ -28,6 +28,7 @@ #include #include #include +#include #include #include #include @@ -53,7 +54,7 @@ struct lib_entry { int flags; - unsigned long int hwcap; + uint64_t hwcap; char *lib; char *path; }; @@ -148,25 +149,31 @@ options, parse_opt, NULL, doc, NULL, NULL, NULL }; -/* Check if string corresponds to an important hardware capability. */ +/* Check if string corresponds to an important hardware capability or + a platform. */ static int -is_hwcap (const char *name) +is_hwcap_platform (const char *name) { int hwcap_idx = _dl_string_hwcap (name); if (hwcap_idx != -1 && ((1 << hwcap_idx) & HWCAP_IMPORTANT)) return 1; + + hwcap_idx = _dl_string_platform (name); + if (hwcap_idx != -1) + return 1; + return 0; } -/* Get hwcap encoding of path. */ -static unsigned long int +/* Get hwcap (including platform) encoding of path. */ +static uint64_t path_hwcap (const char *path) { char *str = xstrdup (path); char *ptr; - unsigned long int hwcap = 0; - unsigned long int h; + uint64_t hwcap = 0; + uint64_t h; size_t len; @@ -182,11 +189,13 @@ if (ptr == NULL) break; - h = _dl_string_hwcap (ptr+1); + h = _dl_string_hwcap (ptr + 1); if (h == -1) + h = _dl_string_platform (ptr + 1); + if (h == -1) break; - hwcap += 1 << h; + hwcap += 1ULL << h; /* Search the next part of the path. */ *ptr = '\0'; @@ -576,7 +585,7 @@ struct dlib_entry *dlib_ptr; struct stat64 stat_buf; int is_link; - unsigned long int hwcap = path_hwcap (entry->path); + uint64_t hwcap = path_hwcap (entry->path); file_name_len = PATH_MAX; file_name = alloca (file_name_len); @@ -586,7 +595,7 @@ if (opt_verbose) { if (hwcap != 0) - printf ("%s: (hwcap: 0x%lx)\n", entry->path, hwcap); + printf ("%s: (hwcap: 0x%Lx)\n", entry->path, hwcap); else printf ("%s:\n", entry->path); } @@ -630,7 +639,7 @@ if (((strncmp (direntry->d_name, "lib", 3) != 0 && strncmp (direntry->d_name, "ld-", 3) != 0) || strstr (direntry->d_name, ".so") == NULL) - && !is_hwcap (direntry->d_name)) + && !is_hwcap_platform (direntry->d_name)) continue; len = strlen (entry->path) + strlen (direntry->d_name); if (len > file_name_len) @@ -662,7 +671,7 @@ continue; } - if (S_ISDIR (stat_buf.st_mode) && is_hwcap (direntry->d_name)) + if (S_ISDIR (stat_buf.st_mode) && is_hwcap_platform (direntry->d_name)) { /* Handle subdirectory later. */ struct dir_entry *new_entry; ============================================================ Index: sysdeps/generic/dl-cache.c --- sysdeps/generic/dl-cache.c 2000/11/07 00:15:04 1.26 +++ sysdeps/generic/dl-cache.c 2000/11/13 12:41:49 @@ -22,7 +22,9 @@ #include #include #include +#include +#include /* System-dependent function to read a file's whole contents in the most convenient manner available. */ @@ -30,6 +32,8 @@ size_t *filesize_ptr, int mmap_prot); +extern const char *_dl_platform; + /* This is the starting address and the size of the mmap()ed file. */ static struct cache_file *cache; static struct cache_file_new *cache_new; @@ -209,8 +213,9 @@ { /* This file ends in static libraries where we don't have a hwcap. */ unsigned long int *hwcap; + uint64_t platform; weak_extern (_dl_hwcap); - + /* This is where the strings start. */ cache_data = (const char *) cache_new; @@ -218,9 +223,49 @@ cache_data_size = (const char *) cache + cachesize - cache_data; hwcap = &_dl_hwcap; - -#define HWCAP_CHECK \ - if (hwcap && (cache_new->libs[middle].hwcap & *hwcap) > _dl_hwcap) \ + platform = _dl_string_platform (_dl_platform); + { + char buf[20]; + buf[sizeof buf - 1] = '\0'; + _dl_debug_message (1, "; platform = ", + _itoa_word (platform, + buf + sizeof buf - 1, 10, 0), + "\n\n", NULL); + } + if (platform != -1) + platform = 1ULL << platform; + { + char buf[20]; + buf[sizeof buf - 1] = '\0'; + _dl_debug_message (1, "; platform = ", + _itoa (platform, + buf + sizeof buf - 1, 16, 0), + "\n\n", NULL); + } + + /* Only accept hwcap if it's for the right platform. */ +#define HWCAP_CHECK \ + { \ + char buf[20]; \ + buf[sizeof buf - 1] = '\0'; \ + _dl_debug_message (1, "considering =", \ + cache_data + cache->libs[middle].value, \ + "; platform = ", \ + _itoa (platform, \ + buf + sizeof buf - 1, 16, 0), \ + "; hwcap = ", \ + _itoa (cache_new->libs[middle].hwcap, \ + buf + sizeof buf - 1, 16, 0), \ + "; _dl_platform = ", _dl_platform, \ + "\n\n", NULL); \ + } \ + if (_DL_PLATFORMS_COUNT && platform != -1 \ + && (cache_new->libs[middle].hwcap & _DL_HWCAP_PLATFORM) != 0 \ + && (cache_new->libs[middle].hwcap & _DL_HWCAP_PLATFORM) != platform) \ + continue; \ + if (hwcap \ + && ((cache_new->libs[middle].hwcap & *hwcap & ~_DL_HWCAP_PLATFORM) \ + > _dl_hwcap)) \ continue SEARCH_CACHE (cache_new); } ============================================================ Index: sysdeps/generic/dl-procinfo.h --- sysdeps/generic/dl-procinfo.h 2000/05/05 15:31:58 1.4 +++ sysdeps/generic/dl-procinfo.h 2000/11/13 12:41:49 @@ -27,12 +27,20 @@ /* There are no hardware capabilities defined. */ #define _dl_hwcap_string(idx) "" +/* There are no different platforms defined. */ +#define _dl_platform_string(idx) "" + /* By default there is no important hardware capability. */ #define HWCAP_IMPORTANT (0) +/* There're no platforms to filter out. */ +#define _DL_HWCAP_PLATFORM 0 + /* We don't have any hardware capabilities. */ #define _DL_HWCAP_COUNT 0 #define _dl_string_hwcap(str) (-1) + +#define _dl_string_platform(str) (-1) #endif /* dl-procinfo.h */ ============================================================ Index: sysdeps/unix/sysv/linux/sparc/sparc32/dl-procinfo.h --- sysdeps/unix/sysv/linux/sparc/sparc32/dl-procinfo.h 2000/05/05 15:31:59 1.2 +++ sysdeps/unix/sysv/linux/sparc/sparc32/dl-procinfo.h 2000/11/13 12:41:49 @@ -68,4 +68,12 @@ #define HWCAP_IMPORTANT (HWCAP_SPARC_V9) +/* There are no different platforms defined. */ +#define _dl_platform_string(idx) "" + +/* There're no platforms to filter out. */ +#define _DL_HWCAP_PLATFORM 0 + +#define _dl_string_platform(str) (-1) + #endif /* dl-procinfo.h */ ============================================================ Index: sysdeps/unix/sysv/linux/sparc/sparc64/dl-procinfo.h --- sysdeps/unix/sysv/linux/sparc/sparc64/dl-procinfo.h 2000/05/05 15:31:59 1.2 +++ sysdeps/unix/sysv/linux/sparc/sparc64/dl-procinfo.h 2000/11/13 12:41:49 @@ -69,4 +69,12 @@ #define HWCAP_IMPORTANT (0) +/* There are no different platforms defined. */ +#define _dl_platform_string(idx) "" + +/* There're no platforms to filter out. */ +#define _DL_HWCAP_PLATFORM 0 + +#define _dl_string_platform(str) (-1) + #endif /* dl-procinfo.h */ ============================================================ Index: sysdeps/unix/sysv/linux/i386/dl-procinfo.h --- sysdeps/unix/sysv/linux/i386/dl-procinfo.h 2000/06/07 23:43:18 1.7 +++ sysdeps/unix/sysv/linux/i386/dl-procinfo.h 2000/11/13 12:41:49 @@ -32,6 +32,18 @@ }; #define _DL_HWCAP_COUNT 32 +static const char x86_platforms[][5] = + { + "i386", "i486", "i586", "i686" + }; +#define _DL_PLATFORMS_COUNT 4 + +/* Start at 48 to reserve some space. */ +#define _DL_FIRST_PLATFORM 48 +/* Mask to filter out platforms. */ +#define _DL_HWCAP_PLATFORM (7ULL << _DL_FIRST_PLATFORM) + + static inline int __attribute__ ((unused)) _dl_procinfo (int word) @@ -58,6 +70,13 @@ return x86_cap_flags[idx]; }; +static inline const char * +__attribute__ ((unused)) +_dl_platform_string (int idx) +{ + return x86_platforms [idx - _DL_FIRST_PLATFORM]; +}; + enum { HWCAP_I386_FPU = 1 << 0, @@ -82,6 +101,7 @@ /* XXX Which others to add here? */ HWCAP_IMPORTANT = (HWCAP_I386_MMX) + }; static inline int @@ -94,6 +114,21 @@ { if (strcmp (str, x86_cap_flags[i]) == 0) return i; + } + return -1; +}; + + +static inline int +__attribute__ ((unused)) +_dl_string_platform (const char *str) +{ + int i; + + for (i = 0; i < _DL_PLATFORMS_COUNT; ++i) + { + if (strcmp (str, x86_platforms[i]) == 0) + return _DL_FIRST_PLATFORM + i; } return -1; }; -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From aj@suse.de Mon Nov 13 04:52:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Mon, 13 Nov 2000 04:52:00 -0000 Subject: Handle platforms References: Message-ID: Here's a new version without debugging output. Ok to commit? Andreas 2000-11-13 Andreas Jaeger * elf/cache.c (struct cache_entry): Use uint64_t for hwcap. (print_entry): Likewise. (add_to_cache): Likewise. * elf/ldconfig.h (add_to_cache): Change prototype for hwcap change. * elf/ldconfig.c (struct lib_entry): Use uint64_t for hwcap. (path_hwcap): Likewise. (search_dir): Likewise. * sysdeps/generic/dl-cache.c (HWCAP_CHECK): Handle platform. * elf/cache.c (add_to_cache): Handle 64 bit hwcap entry. * sysdeps/unix/sysv/linux/sparc/sparc32/dl-procinfo.h (_dl_platform_string): New. (_DL_HWCAP_PLATFORM): New. (_dl_string_platform): New. * sysdeps/unix/sysv/linux/sparc/sparc64/dl-procinfo.h: Likewise. * sysdeps/generic/dl-procinfo.h (_DL_HWCAP_COUNT): New. (_dl_string_platform): New. (_DL_HWCAP_PLATFORM): New. (_dl_platform_string): New. * sysdeps/unix/sysv/linux/i386/dl-procinfo.h: Added x86 platform recognition. (_DL_HWCAP_COUNT): New. (_dl_string_platform): New. (_DL_HWCAP_PLATFORM): New. (_dl_platform_string): New. ============================================================ Index: elf/cache.c --- elf/cache.c 2000/09/30 03:17:35 1.9 +++ elf/cache.c 2000/11/13 12:41:49 @@ -25,6 +25,7 @@ #include #include #include +#include #include #include #include @@ -38,7 +39,7 @@ char *lib; /* Library name. */ char *path; /* Path to find library. */ int flags; /* Flags to indicate kind of library. */ - unsigned long int hwcap; /* Important hardware capabilities. */ + uint64_t hwcap; /* Important hardware capabilities. */ int bits_hwcap; /* Number of bits set in hwcap. */ struct cache_entry *next; /* Next entry in list. */ }; @@ -51,7 +52,7 @@ /* Print a single entry. */ static void -print_entry (const char *lib, int flag, unsigned long int hwcap, const char *key) +print_entry (const char *lib, int flag, uint64_t hwcap, const char *key) { printf ("\t%s (", lib); switch (flag & FLAG_TYPE_MASK) @@ -83,7 +84,7 @@ break; } if (hwcap != 0) - printf (", hwcap: 0x%lx", hwcap); + printf (", hwcap: 0x%Lx", hwcap); printf (") => %s\n", key); } @@ -411,7 +412,7 @@ /* Add one library to the cache. */ void add_to_cache (const char *path, const char *lib, int flags, - unsigned long int hwcap) + uint64_t hwcap) { struct cache_entry *new_entry, *ptr, *prev; char *full_path; @@ -431,8 +432,8 @@ new_entry->bits_hwcap = 0; /* Count the number of bits set in the masked value. */ - for (i = 0; (~((1UL << i) - 1) & hwcap) != 0; ++i) - if ((hwcap & (1UL << i)) != 0) + for (i = 0; (~((1ULL << i) - 1) & hwcap) != 0; ++i) + if ((hwcap & (1ULL << i)) != 0) ++new_entry->bits_hwcap; ============================================================ Index: elf/ldconfig.h --- elf/ldconfig.h 2000/09/30 21:45:53 1.6 +++ elf/ldconfig.h 2000/11/13 12:41:49 @@ -39,7 +39,7 @@ extern void save_cache (const char *cache_name); extern void add_to_cache (const char *path, const char *lib, int flags, - unsigned long int hwcap); + uint64_t hwcap); /* Declared in readlib.c. */ extern int process_file (const char *real_file_name, const char *file_name, ============================================================ Index: elf/ldconfig.c --- elf/ldconfig.c 2000/11/10 14:06:06 1.12 +++ elf/ldconfig.c 2000/11/13 12:41:49 @@ -28,6 +28,7 @@ #include #include #include +#include #include #include #include @@ -53,7 +54,7 @@ struct lib_entry { int flags; - unsigned long int hwcap; + uint64_t hwcap; char *lib; char *path; }; @@ -148,25 +149,31 @@ options, parse_opt, NULL, doc, NULL, NULL, NULL }; -/* Check if string corresponds to an important hardware capability. */ +/* Check if string corresponds to an important hardware capability or + a platform. */ static int -is_hwcap (const char *name) +is_hwcap_platform (const char *name) { int hwcap_idx = _dl_string_hwcap (name); if (hwcap_idx != -1 && ((1 << hwcap_idx) & HWCAP_IMPORTANT)) return 1; + + hwcap_idx = _dl_string_platform (name); + if (hwcap_idx != -1) + return 1; + return 0; } -/* Get hwcap encoding of path. */ -static unsigned long int +/* Get hwcap (including platform) encoding of path. */ +static uint64_t path_hwcap (const char *path) { char *str = xstrdup (path); char *ptr; - unsigned long int hwcap = 0; - unsigned long int h; + uint64_t hwcap = 0; + uint64_t h; size_t len; @@ -182,11 +189,13 @@ if (ptr == NULL) break; - h = _dl_string_hwcap (ptr+1); + h = _dl_string_hwcap (ptr + 1); if (h == -1) + h = _dl_string_platform (ptr + 1); + if (h == -1) break; - hwcap += 1 << h; + hwcap += 1ULL << h; /* Search the next part of the path. */ *ptr = '\0'; @@ -576,7 +585,7 @@ struct dlib_entry *dlib_ptr; struct stat64 stat_buf; int is_link; - unsigned long int hwcap = path_hwcap (entry->path); + uint64_t hwcap = path_hwcap (entry->path); file_name_len = PATH_MAX; file_name = alloca (file_name_len); @@ -586,7 +595,7 @@ if (opt_verbose) { if (hwcap != 0) - printf ("%s: (hwcap: 0x%lx)\n", entry->path, hwcap); + printf ("%s: (hwcap: 0x%Lx)\n", entry->path, hwcap); else printf ("%s:\n", entry->path); } @@ -630,7 +639,7 @@ if (((strncmp (direntry->d_name, "lib", 3) != 0 && strncmp (direntry->d_name, "ld-", 3) != 0) || strstr (direntry->d_name, ".so") == NULL) - && !is_hwcap (direntry->d_name)) + && !is_hwcap_platform (direntry->d_name)) continue; len = strlen (entry->path) + strlen (direntry->d_name); if (len > file_name_len) @@ -662,7 +671,7 @@ continue; } - if (S_ISDIR (stat_buf.st_mode) && is_hwcap (direntry->d_name)) + if (S_ISDIR (stat_buf.st_mode) && is_hwcap_platform (direntry->d_name)) { /* Handle subdirectory later. */ struct dir_entry *new_entry; ============================================================ Index: sysdeps/generic/dl-cache.c --- sysdeps/generic/dl-cache.c 2000/11/07 00:15:04 1.26 +++ sysdeps/generic/dl-cache.c 2000/11/13 12:41:49 @@ -22,7 +22,9 @@ #include #include #include +#include +#include /* System-dependent function to read a file's whole contents in the most convenient manner available. */ @@ -30,6 +32,8 @@ size_t *filesize_ptr, int mmap_prot); +extern const char *_dl_platform; + /* This is the starting address and the size of the mmap()ed file. */ static struct cache_file *cache; static struct cache_file_new *cache_new; @@ -209,8 +213,9 @@ { /* This file ends in static libraries where we don't have a hwcap. */ unsigned long int *hwcap; + uint64_t platform; weak_extern (_dl_hwcap); - + /* This is where the strings start. */ cache_data = (const char *) cache_new; @@ -218,9 +223,49 @@ cache_data_size = (const char *) cache + cachesize - cache_data; hwcap = &_dl_hwcap; - -#define HWCAP_CHECK \ - if (hwcap && (cache_new->libs[middle].hwcap & *hwcap) > _dl_hwcap) \ + platform = _dl_string_platform (_dl_platform); + { + char buf[20]; + buf[sizeof buf - 1] = '\0'; + _dl_debug_message (1, "; platform = ", + _itoa_word (platform, + buf + sizeof buf - 1, 10, 0), + "\n\n", NULL); + } + if (platform != -1) + platform = 1ULL << platform; + { + char buf[20]; + buf[sizeof buf - 1] = '\0'; + _dl_debug_message (1, "; platform = ", + _itoa (platform, + buf + sizeof buf - 1, 16, 0), + "\n\n", NULL); + } + + /* Only accept hwcap if it's for the right platform. */ +#define HWCAP_CHECK \ + { \ + char buf[20]; \ + buf[sizeof buf - 1] = '\0'; \ + _dl_debug_message (1, "considering =", \ + cache_data + cache->libs[middle].value, \ + "; platform = ", \ + _itoa (platform, \ + buf + sizeof buf - 1, 16, 0), \ + "; hwcap = ", \ + _itoa (cache_new->libs[middle].hwcap, \ + buf + sizeof buf - 1, 16, 0), \ + "; _dl_platform = ", _dl_platform, \ + "\n\n", NULL); \ + } \ + if (_DL_PLATFORMS_COUNT && platform != -1 \ + && (cache_new->libs[middle].hwcap & _DL_HWCAP_PLATFORM) != 0 \ + && (cache_new->libs[middle].hwcap & _DL_HWCAP_PLATFORM) != platform) \ + continue; \ + if (hwcap \ + && ((cache_new->libs[middle].hwcap & *hwcap & ~_DL_HWCAP_PLATFORM) \ + > _dl_hwcap)) \ continue SEARCH_CACHE (cache_new); } ============================================================ Index: sysdeps/generic/dl-procinfo.h --- sysdeps/generic/dl-procinfo.h 2000/05/05 15:31:58 1.4 +++ sysdeps/generic/dl-procinfo.h 2000/11/13 12:41:49 @@ -27,12 +27,20 @@ /* There are no hardware capabilities defined. */ #define _dl_hwcap_string(idx) "" +/* There are no different platforms defined. */ +#define _dl_platform_string(idx) "" + /* By default there is no important hardware capability. */ #define HWCAP_IMPORTANT (0) +/* There're no platforms to filter out. */ +#define _DL_HWCAP_PLATFORM 0 + /* We don't have any hardware capabilities. */ #define _DL_HWCAP_COUNT 0 #define _dl_string_hwcap(str) (-1) + +#define _dl_string_platform(str) (-1) #endif /* dl-procinfo.h */ ============================================================ Index: sysdeps/unix/sysv/linux/sparc/sparc32/dl-procinfo.h --- sysdeps/unix/sysv/linux/sparc/sparc32/dl-procinfo.h 2000/05/05 15:31:59 1.2 +++ sysdeps/unix/sysv/linux/sparc/sparc32/dl-procinfo.h 2000/11/13 12:41:49 @@ -68,4 +68,12 @@ #define HWCAP_IMPORTANT (HWCAP_SPARC_V9) +/* There are no different platforms defined. */ +#define _dl_platform_string(idx) "" + +/* There're no platforms to filter out. */ +#define _DL_HWCAP_PLATFORM 0 + +#define _dl_string_platform(str) (-1) + #endif /* dl-procinfo.h */ ============================================================ Index: sysdeps/unix/sysv/linux/sparc/sparc64/dl-procinfo.h --- sysdeps/unix/sysv/linux/sparc/sparc64/dl-procinfo.h 2000/05/05 15:31:59 1.2 +++ sysdeps/unix/sysv/linux/sparc/sparc64/dl-procinfo.h 2000/11/13 12:41:49 @@ -69,4 +69,12 @@ #define HWCAP_IMPORTANT (0) +/* There are no different platforms defined. */ +#define _dl_platform_string(idx) "" + +/* There're no platforms to filter out. */ +#define _DL_HWCAP_PLATFORM 0 + +#define _dl_string_platform(str) (-1) + #endif /* dl-procinfo.h */ ============================================================ Index: sysdeps/unix/sysv/linux/i386/dl-procinfo.h --- sysdeps/unix/sysv/linux/i386/dl-procinfo.h 2000/06/07 23:43:18 1.7 +++ sysdeps/unix/sysv/linux/i386/dl-procinfo.h 2000/11/13 12:41:49 @@ -32,6 +32,18 @@ }; #define _DL_HWCAP_COUNT 32 +static const char x86_platforms[][5] = + { + "i386", "i486", "i586", "i686" + }; +#define _DL_PLATFORMS_COUNT 4 + +/* Start at 48 to reserve some space. */ +#define _DL_FIRST_PLATFORM 48 +/* Mask to filter out platforms. */ +#define _DL_HWCAP_PLATFORM (7ULL << _DL_FIRST_PLATFORM) + + static inline int __attribute__ ((unused)) _dl_procinfo (int word) @@ -58,6 +70,13 @@ return x86_cap_flags[idx]; }; +static inline const char * +__attribute__ ((unused)) +_dl_platform_string (int idx) +{ + return x86_platforms [idx - _DL_FIRST_PLATFORM]; +}; + enum { HWCAP_I386_FPU = 1 << 0, @@ -82,6 +101,7 @@ /* XXX Which others to add here? */ HWCAP_IMPORTANT = (HWCAP_I386_MMX) + }; static inline int @@ -94,6 +114,21 @@ { if (strcmp (str, x86_cap_flags[i]) == 0) return i; + } + return -1; +}; + + +static inline int +__attribute__ ((unused)) +_dl_string_platform (const char *str) +{ + int i; + + for (i = 0; i < _DL_PLATFORMS_COUNT; ++i) + { + if (strcmp (str, x86_platforms[i]) == 0) + return _DL_FIRST_PLATFORM + i; } return -1; }; -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From aj@suse.de Mon Nov 13 04:53:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Mon, 13 Nov 2000 04:53:00 -0000 Subject: Handle platforms [third try] References: Message-ID: Here comes the final;-) version, this time I really removed the debugging output. Andreas 2000-11-13 Andreas Jaeger * elf/cache.c (struct cache_entry): Use uint64_t for hwcap. (print_entry): Likewise. (add_to_cache): Likewise. * elf/ldconfig.h (add_to_cache): Change prototype for hwcap change. * elf/ldconfig.c (struct lib_entry): Use uint64_t for hwcap. (path_hwcap): Likewise. (search_dir): Likewise. * sysdeps/generic/dl-cache.c (HWCAP_CHECK): Handle platform. * elf/cache.c (add_to_cache): Handle 64 bit hwcap entry. * sysdeps/unix/sysv/linux/sparc/sparc32/dl-procinfo.h (_dl_platform_string): New. (_DL_HWCAP_PLATFORM): New. (_dl_string_platform): New. * sysdeps/unix/sysv/linux/sparc/sparc64/dl-procinfo.h: Likewise. * sysdeps/generic/dl-procinfo.h (_DL_HWCAP_COUNT): New. (_dl_string_platform): New. (_DL_HWCAP_PLATFORM): New. (_dl_platform_string): New. * sysdeps/unix/sysv/linux/i386/dl-procinfo.h: Added x86 platform recognition. (_DL_HWCAP_COUNT): New. (_dl_string_platform): New. (_DL_HWCAP_PLATFORM): New. (_dl_platform_string): New. ============================================================ Index: elf/cache.c --- elf/cache.c 2000/09/30 03:17:35 1.9 +++ elf/cache.c 2000/11/13 12:52:36 @@ -25,6 +25,7 @@ #include #include #include +#include #include #include #include @@ -38,7 +39,7 @@ char *lib; /* Library name. */ char *path; /* Path to find library. */ int flags; /* Flags to indicate kind of library. */ - unsigned long int hwcap; /* Important hardware capabilities. */ + uint64_t hwcap; /* Important hardware capabilities. */ int bits_hwcap; /* Number of bits set in hwcap. */ struct cache_entry *next; /* Next entry in list. */ }; @@ -51,7 +52,7 @@ /* Print a single entry. */ static void -print_entry (const char *lib, int flag, unsigned long int hwcap, const char *key) +print_entry (const char *lib, int flag, uint64_t hwcap, const char *key) { printf ("\t%s (", lib); switch (flag & FLAG_TYPE_MASK) @@ -83,7 +84,7 @@ break; } if (hwcap != 0) - printf (", hwcap: 0x%lx", hwcap); + printf (", hwcap: 0x%Lx", hwcap); printf (") => %s\n", key); } @@ -411,7 +412,7 @@ /* Add one library to the cache. */ void add_to_cache (const char *path, const char *lib, int flags, - unsigned long int hwcap) + uint64_t hwcap) { struct cache_entry *new_entry, *ptr, *prev; char *full_path; @@ -431,8 +432,8 @@ new_entry->bits_hwcap = 0; /* Count the number of bits set in the masked value. */ - for (i = 0; (~((1UL << i) - 1) & hwcap) != 0; ++i) - if ((hwcap & (1UL << i)) != 0) + for (i = 0; (~((1ULL << i) - 1) & hwcap) != 0; ++i) + if ((hwcap & (1ULL << i)) != 0) ++new_entry->bits_hwcap; ============================================================ Index: elf/ldconfig.h --- elf/ldconfig.h 2000/09/30 21:45:53 1.6 +++ elf/ldconfig.h 2000/11/13 12:52:36 @@ -39,7 +39,7 @@ extern void save_cache (const char *cache_name); extern void add_to_cache (const char *path, const char *lib, int flags, - unsigned long int hwcap); + uint64_t hwcap); /* Declared in readlib.c. */ extern int process_file (const char *real_file_name, const char *file_name, ============================================================ Index: elf/ldconfig.c --- elf/ldconfig.c 2000/11/10 14:06:06 1.12 +++ elf/ldconfig.c 2000/11/13 12:52:36 @@ -28,6 +28,7 @@ #include #include #include +#include #include #include #include @@ -53,7 +54,7 @@ struct lib_entry { int flags; - unsigned long int hwcap; + uint64_t hwcap; char *lib; char *path; }; @@ -148,25 +149,31 @@ options, parse_opt, NULL, doc, NULL, NULL, NULL }; -/* Check if string corresponds to an important hardware capability. */ +/* Check if string corresponds to an important hardware capability or + a platform. */ static int -is_hwcap (const char *name) +is_hwcap_platform (const char *name) { int hwcap_idx = _dl_string_hwcap (name); if (hwcap_idx != -1 && ((1 << hwcap_idx) & HWCAP_IMPORTANT)) return 1; + + hwcap_idx = _dl_string_platform (name); + if (hwcap_idx != -1) + return 1; + return 0; } -/* Get hwcap encoding of path. */ -static unsigned long int +/* Get hwcap (including platform) encoding of path. */ +static uint64_t path_hwcap (const char *path) { char *str = xstrdup (path); char *ptr; - unsigned long int hwcap = 0; - unsigned long int h; + uint64_t hwcap = 0; + uint64_t h; size_t len; @@ -182,11 +189,13 @@ if (ptr == NULL) break; - h = _dl_string_hwcap (ptr+1); + h = _dl_string_hwcap (ptr + 1); if (h == -1) + h = _dl_string_platform (ptr + 1); + if (h == -1) break; - hwcap += 1 << h; + hwcap += 1ULL << h; /* Search the next part of the path. */ *ptr = '\0'; @@ -576,7 +585,7 @@ struct dlib_entry *dlib_ptr; struct stat64 stat_buf; int is_link; - unsigned long int hwcap = path_hwcap (entry->path); + uint64_t hwcap = path_hwcap (entry->path); file_name_len = PATH_MAX; file_name = alloca (file_name_len); @@ -586,7 +595,7 @@ if (opt_verbose) { if (hwcap != 0) - printf ("%s: (hwcap: 0x%lx)\n", entry->path, hwcap); + printf ("%s: (hwcap: 0x%Lx)\n", entry->path, hwcap); else printf ("%s:\n", entry->path); } @@ -630,7 +639,7 @@ if (((strncmp (direntry->d_name, "lib", 3) != 0 && strncmp (direntry->d_name, "ld-", 3) != 0) || strstr (direntry->d_name, ".so") == NULL) - && !is_hwcap (direntry->d_name)) + && !is_hwcap_platform (direntry->d_name)) continue; len = strlen (entry->path) + strlen (direntry->d_name); if (len > file_name_len) @@ -662,7 +671,7 @@ continue; } - if (S_ISDIR (stat_buf.st_mode) && is_hwcap (direntry->d_name)) + if (S_ISDIR (stat_buf.st_mode) && is_hwcap_platform (direntry->d_name)) { /* Handle subdirectory later. */ struct dir_entry *new_entry; ============================================================ Index: sysdeps/generic/dl-cache.c --- sysdeps/generic/dl-cache.c 2000/11/07 00:15:04 1.26 +++ sysdeps/generic/dl-cache.c 2000/11/13 12:52:37 @@ -22,7 +22,9 @@ #include #include #include +#include +#include /* System-dependent function to read a file's whole contents in the most convenient manner available. */ @@ -30,6 +32,8 @@ size_t *filesize_ptr, int mmap_prot); +extern const char *_dl_platform; + /* This is the starting address and the size of the mmap()ed file. */ static struct cache_file *cache; static struct cache_file_new *cache_new; @@ -209,8 +213,9 @@ { /* This file ends in static libraries where we don't have a hwcap. */ unsigned long int *hwcap; + uint64_t platform; weak_extern (_dl_hwcap); - + /* This is where the strings start. */ cache_data = (const char *) cache_new; @@ -218,9 +223,19 @@ cache_data_size = (const char *) cache + cachesize - cache_data; hwcap = &_dl_hwcap; - -#define HWCAP_CHECK \ - if (hwcap && (cache_new->libs[middle].hwcap & *hwcap) > _dl_hwcap) \ + platform = _dl_string_platform (_dl_platform); + if (platform != -1) + platform = 1ULL << platform; + + /* Only accept hwcap if it's for the right platform. */ +#define HWCAP_CHECK \ + if (_DL_PLATFORMS_COUNT && platform != -1 \ + && (cache_new->libs[middle].hwcap & _DL_HWCAP_PLATFORM) != 0 \ + && (cache_new->libs[middle].hwcap & _DL_HWCAP_PLATFORM) != platform) \ + continue; \ + if (hwcap \ + && ((cache_new->libs[middle].hwcap & *hwcap & ~_DL_HWCAP_PLATFORM) \ + > _dl_hwcap)) \ continue SEARCH_CACHE (cache_new); } ============================================================ Index: sysdeps/generic/dl-procinfo.h --- sysdeps/generic/dl-procinfo.h 2000/05/05 15:31:58 1.4 +++ sysdeps/generic/dl-procinfo.h 2000/11/13 12:52:37 @@ -27,12 +27,20 @@ /* There are no hardware capabilities defined. */ #define _dl_hwcap_string(idx) "" +/* There are no different platforms defined. */ +#define _dl_platform_string(idx) "" + /* By default there is no important hardware capability. */ #define HWCAP_IMPORTANT (0) +/* There're no platforms to filter out. */ +#define _DL_HWCAP_PLATFORM 0 + /* We don't have any hardware capabilities. */ #define _DL_HWCAP_COUNT 0 #define _dl_string_hwcap(str) (-1) + +#define _dl_string_platform(str) (-1) #endif /* dl-procinfo.h */ ============================================================ Index: sysdeps/unix/sysv/linux/sparc/sparc32/dl-procinfo.h --- sysdeps/unix/sysv/linux/sparc/sparc32/dl-procinfo.h 2000/05/05 15:31:59 1.2 +++ sysdeps/unix/sysv/linux/sparc/sparc32/dl-procinfo.h 2000/11/13 12:52:37 @@ -68,4 +68,12 @@ #define HWCAP_IMPORTANT (HWCAP_SPARC_V9) +/* There are no different platforms defined. */ +#define _dl_platform_string(idx) "" + +/* There're no platforms to filter out. */ +#define _DL_HWCAP_PLATFORM 0 + +#define _dl_string_platform(str) (-1) + #endif /* dl-procinfo.h */ ============================================================ Index: sysdeps/unix/sysv/linux/sparc/sparc64/dl-procinfo.h --- sysdeps/unix/sysv/linux/sparc/sparc64/dl-procinfo.h 2000/05/05 15:31:59 1.2 +++ sysdeps/unix/sysv/linux/sparc/sparc64/dl-procinfo.h 2000/11/13 12:52:37 @@ -69,4 +69,12 @@ #define HWCAP_IMPORTANT (0) +/* There are no different platforms defined. */ +#define _dl_platform_string(idx) "" + +/* There're no platforms to filter out. */ +#define _DL_HWCAP_PLATFORM 0 + +#define _dl_string_platform(str) (-1) + #endif /* dl-procinfo.h */ ============================================================ Index: sysdeps/unix/sysv/linux/i386/dl-procinfo.h --- sysdeps/unix/sysv/linux/i386/dl-procinfo.h 2000/06/07 23:43:18 1.7 +++ sysdeps/unix/sysv/linux/i386/dl-procinfo.h 2000/11/13 12:52:37 @@ -32,6 +32,18 @@ }; #define _DL_HWCAP_COUNT 32 +static const char x86_platforms[][5] = + { + "i386", "i486", "i586", "i686" + }; +#define _DL_PLATFORMS_COUNT 4 + +/* Start at 48 to reserve some space. */ +#define _DL_FIRST_PLATFORM 48 +/* Mask to filter out platforms. */ +#define _DL_HWCAP_PLATFORM (7ULL << _DL_FIRST_PLATFORM) + + static inline int __attribute__ ((unused)) _dl_procinfo (int word) @@ -58,6 +70,13 @@ return x86_cap_flags[idx]; }; +static inline const char * +__attribute__ ((unused)) +_dl_platform_string (int idx) +{ + return x86_platforms [idx - _DL_FIRST_PLATFORM]; +}; + enum { HWCAP_I386_FPU = 1 << 0, @@ -82,6 +101,7 @@ /* XXX Which others to add here? */ HWCAP_IMPORTANT = (HWCAP_I386_MMX) + }; static inline int @@ -95,6 +115,22 @@ if (strcmp (str, x86_cap_flags[i]) == 0) return i; } + return -1; +}; + + +static inline int +__attribute__ ((unused)) +_dl_string_platform (const char *str) +{ + int i; + + if (str != NULL) + for (i = 0; i < _DL_PLATFORMS_COUNT; ++i) + { + if (strcmp (str, x86_platforms[i]) == 0) + return _DL_FIRST_PLATFORM + i; + } return -1; }; -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From aj@suse.de Mon Nov 13 08:02:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Mon, 13 Nov 2000 08:02:00 -0000 Subject: tst-gettext2: Better tests Message-ID: The output from tst-gettext2 doesn't look right, I've created a file with the expected output. What do you think of this? Shall I commit it? Andreas 2000-11-13 Andreas Jaeger * intl/tst-gettext2.sh: Check output against expected output. * intl/tst-gettext2.exp: New file. ============================================================ Index: intl/tst-gettext2.sh --- intl/tst-gettext2.sh 2000/10/31 03:08:09 1.1 +++ intl/tst-gettext2.sh 2000/11/13 16:00:50 @@ -50,5 +50,7 @@ ${common_objpfx}elf/ld.so --library-path $common_objpfx \ ${objpfx}tst-gettext2 > ${objpfx}tst-gettext2.out ${objpfx}domaindir +diff -q tst-gettext2.exp ${objpfx}tst-gettext2.out + exit $? ============================================================ Index: intl/tst-gettext2.exp --- intl/tst-gettext2.exp created +++ intl/tst-gettext2.exp Mon Nov 13 16:48:10 2000 1.1 @@ -0,0 +1,6 @@ +String1 - Lang1: 1st string +String2 - Lang1: 2nd string +String1 - Lang2: 1st string +String2 - Lang2: 2nd string +String1 - First string for testing. +String2 - Another string for testing. -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From jakub@redhat.com Mon Nov 13 08:45:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Mon, 13 Nov 2000 08:45:00 -0000 Subject: [PATCH] Alpha ulps update Message-ID: <20001113174805.B635@sunsite.ms.mff.cuni.cz> Hi! This makes math make check happy on Alpha. 2000-11-13 Jakub Jelinek * sysdeps/alpha/fpu/libm-test-ulps: Update. --- sysdeps/alpha/fpu/libm-test-ulps.jj Mon Oct 30 03:03:08 2000 +++ sysdeps/alpha/fpu/libm-test-ulps Mon Nov 13 10:05:58 2000 @@ -7,7 +7,7 @@ ifloat: 2 Test "asin (0.5) == pi/6": float: 2 ifloat: 2 -Test "asin (0.7) == 0.7753974966107530637": +Test "asin (0.7) == 0.77539749661075306374035335271498708": double: 1 float: 2 idouble: 1 @@ -164,12 +164,12 @@ idouble: 1 Test "Imaginary part of: cexp (-2.0 - 3.0 i) == -0.13398091492954261346140525546115575 - 0.019098516261135196432576240858800925 i": float: 1 ifloat: 1 -Test "Real part of: cexp (0.7 + 1.2 i) == 0.7296989091503236012 + 1.8768962328348102821 i": +Test "Real part of: cexp (0.7 + 1.2 i) == 0.72969890915032360123451688642930727 + 1.8768962328348102821139467908203072 i": double: 1 float: 1 idouble: 1 ifloat: 1 -Test "Imaginary part of: cexp (0.7 + 1.2 i) == 0.7296989091503236012 + 1.8768962328348102821 i": +Test "Imaginary part of: cexp (0.7 + 1.2 i) == 0.72969890915032360123451688642930727 + 1.8768962328348102821139467908203072 i": float: 1 ifloat: 1 @@ -238,7 +238,7 @@ float: 1 ifloat: 1 # cos -Test "cos (0.7) == 0.7648421872844884262": +Test "cos (0.7) == 0.76484218728448842625585999019186495": double: 1 float: 1 idouble: 1 @@ -363,7 +363,7 @@ double: 2 float: 1 idouble: 2 ifloat: 1 -Test "exp10 (0.7) == 5.0118723362727228500": +Test "exp10 (0.7) == 5.0118723362727228500155418688494574": float: 1 ifloat: 1 Test "exp10 (3) == 1000": @@ -552,7 +552,7 @@ idouble: 1 ifloat: 1 # sincos -Test "sincos (0.7, &sin_res, &cos_res) puts 0.76484218728448842626 in cos_res": +Test "sincos (0.7, &sin_res, &cos_res) puts 0.76484218728448842625585999019186495 in cos_res": double: 1 float: 1 idouble: 1 @@ -562,7 +562,7 @@ double: 1 float: 0.5 idouble: 1 ifloat: 0.5 -Test "sincos (M_PI_6l*2.0, &sin_res, &cos_res) puts 0.866025403784438646764 in sin_res": +Test "sincos (M_PI_6l*2.0, &sin_res, &cos_res) puts 0.86602540378443864676372317075293616 in sin_res": double: 1 float: 1 idouble: 1 @@ -572,7 +572,7 @@ double: 0.2758 float: 0.3667 idouble: 0.2758 ifloat: 0.3667 -Test "sincos (pi/6, &sin_res, &cos_res) puts 0.866025403784438646764 in cos_res": +Test "sincos (pi/6, &sin_res, &cos_res) puts 0.86602540378443864676372317075293616 in cos_res": float: 1 ifloat: 1 Jakub From jakub@redhat.com Mon Nov 13 08:48:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Mon, 13 Nov 2000 08:48:00 -0000 Subject: [PATCH] Build proper bits/syscall.h on sparc* (take 2) Message-ID: <20001113175034.C635@sunsite.ms.mff.cuni.cz> Hi! Below is a new version of my patch from Nov, 9th, because that one had a missing semicolon (in the rm command which was the only one added after testing it out). As mentioned some time ago, sparc*-*-linux* needs to do more work to build bits/syscall.h than most of the other ports, because although most of the syscalls are common to both platforms, some syscalls are 32bit and some syscalls are 64bit only. This patch was tested on sparc32 by full bootstrap/make check (passed) and on sparc64 (just did this by hand to see whether it works). It should work on all other arches since nothing else defines no_syscall_list_h. 2000-11-13 Jakub Jelinek * sysdeps/unix/sysv/linux/Makefile: Allow ports to override syscall-list.h goal. * sysdeps/unix/sysv/linux/sparc/Makefile: New. --- libc/sysdeps/unix/sysv/linux/sparc/Makefile.jj Thu Nov 9 10:51:46 2000 +++ libc/sysdeps/unix/sysv/linux/sparc/Makefile Thu Nov 9 11:26:57 2000 @@ -0,0 +1,44 @@ +ifeq ($(subdir),misc) + +no_syscall_list_h = 1 + +# Generate the list of SYS_* macros for the system calls (__NR_* macros). +$(objpfx)syscall-%.h $(objpfx)syscall-%.d: ../sysdeps/unix/sysv/linux/sys/syscall.h + rm -f $(@:.h=.d)-t + { \ + echo '/* Generated at libc build time from kernel syscall list. */';\ + echo ''; \ + echo '#ifndef _SYSCALL_H'; \ + echo '# error "Never use directly; include instead."'; \ + echo '#endif'; \ + echo ''; \ + SUNPRO_DEPENDENCIES='$(@:.h=.d)-t $@' \ + $(CC) -E -x c $(sysincludes) $< -U__sparc_v9__ -U__arch64__ -D_LIBC -dM | \ + sed -n 's@^#define __NR_\([^ ]*\) .*$$@#define SYS_\1 __NR_\1@p' | \ + LC_ALL=C sort > $(@:.d=.h).new32; \ + SUNPRO_DEPENDENCIES='$(@:.h=.d)-t $@' \ + $(CC) -E -x c $(sysincludes) $< -D__sparc_v9__ -D__arch64__ -D_LIBC -dM | \ + sed -n 's@^#define __NR_\([^ ]*\) .*$$@#define SYS_\1 __NR_\1@p' | \ + LC_ALL=C sort > $(@:.d=.h).new64; \ + if cmp -s $(@:.d=.h).new32 $(@:.d=.h).new64; then \ + cat $(@:.d=.h).new32; \ + else \ + echo '#include '; \ + echo ''; \ + comm -12 $(@:.d=.h).new32 $(@:.d=.h).new64; \ + echo '#if __WORDSIZE == 64'; \ + comm -13 $(@:.d=.h).new32 $(@:.d=.h).new64; \ + echo '#else'; \ + comm -23 $(@:.d=.h).new32 $(@:.d=.h).new64; \ + echo '#endif'; \ + fi; \ + rm -f $(@:.d=.h).new32 $(@:.d=.h).new64; \ + } > $(@:.d=.h).new + mv -f $(@:.d=.h).new $(@:.d=.h) + sed < $(@:.h=.d)-t > $(@:.h=.d)-t2 \ + -e 's,$(subst .,\.,$@),$(patsubst $(objpfx)%,$$(objpfx)%,\ + $(@:.d=.h) $(@:.h=.d)),' + rm -f $(@:.h=.d)-t + mv -f $(@:.h=.d)-t2 $(@:.h=.d) + +endif --- libc/sysdeps/unix/sysv/linux/Makefile.jj Tue Oct 17 07:18:13 2000 +++ libc/sysdeps/unix/sysv/linux/Makefile Thu Nov 9 10:50:08 2000 @@ -25,6 +25,7 @@ sysdep_headers += sys/mount.h sys/acct.h install-others += $(inst_includedir)/bits/syscall.h +ifndef no_syscall_list_h # Generate the list of SYS_* macros for the system calls (__NR_* macros). $(objpfx)syscall-%.h $(objpfx)syscall-%.d: ../sysdeps/unix/sysv/linux/sys/syscall.h rm -f $(@:.h=.d)-t @@ -45,6 +46,7 @@ $(objpfx)syscall-%.h $(objpfx)syscall-%. $(@:.d=.h) $(@:.h=.d)),' rm -f $(@:.h=.d)-t mv -f $(@:.h=.d)-t2 $(@:.h=.d) +endif $(inst_includedir)/bits/syscall.h: $(objpfx)syscall-list.h $(+force) $(make-target-directory) Jakub From aj@suse.de Mon Nov 13 08:50:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Mon, 13 Nov 2000 08:50:00 -0000 Subject: [PATCH] Alpha ulps update References: <20001113174805.B635@sunsite.ms.mff.cuni.cz> Message-ID: Thanks, I'll commit this now, Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From aj@suse.de Mon Nov 13 08:51:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Mon, 13 Nov 2000 08:51:00 -0000 Subject: [PATCH] Alpha ulps update References: <20001113174805.B635@sunsite.ms.mff.cuni.cz> Message-ID: Jakub, Do you have now a compiler that works on Alpha? Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From aj@suse.de Mon Nov 13 08:52:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Mon, 13 Nov 2000 08:52:00 -0000 Subject: A patch for sysdeps/ia64/fpu/libm-test-ulps References: <20001110210921.A5737@valinux.com> Message-ID: Thanks, I've committed it now, Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From ralf@uni-koblenz.de Mon Nov 13 14:11:00 2000 From: ralf@uni-koblenz.de (Ralf Baechle) Date: Mon, 13 Nov 2000 14:11:00 -0000 Subject: glibc-2.2 and libgd References: <200010201725.TAA21606@lxplus015.cern.ch> Message-ID: <20001113181742.B8230@bacchus.dhis.org> On Fri, Oct 20, 2000 at 07:25:44PM +0200, Jes Sorensen wrote: > There seem to be a problem with glibc-2.2-current and libgd > compilation. If I configure glibc in a seperate directory it still finds > the gd.h header files I have installed in /usr/include but then fails to > compile the binary because at compile time it cannot find the headers. > > There seems to be something iffy with the configure.in scripts for it, > the --with-gd option doesn't work properly, if I say --without-gd or > --with-gd=no it still finds it, I have to say --with-gd=/dev/null for it > to not find it. > > My knowledge about autoconf is really limited so I'd rather have someone > who knows just how to fix this in a jiffy look at it. Here is another variant of a libgd problem: gcc memusagestat.c -c -O -Wall -Winline -Wstrict-prototypes -Wwrite-strings -g -I../include -I. -I.. -I../libio -I../sysdeps/mips/elf -I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread -I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix -I../linuxthreads/sysdeps/mips -I../sysdeps/unix/sysv/linux/mips -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix/mips -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/mips/fpu -I../sysdeps/mips -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -nostdinc -isystem /usr/lib/gcc-lib/mips-linux/2.96/include -isystem /usr/src/linux-2.4/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h -DPIC -o memusagestat.o memusagestat.c:36:16: gd.h: No such file or directory memusagestat.c:37:21: gdfontl.h: No such file or directory memusagestat.c:38:21: gdfonts.h: No such file or directory make: *** [memusagestat.o] Error 1 These three files do exist in /usr/include/ but thanks to -nostdinc we're not even searching there. These options are used due to the configure option --with-headers=/usr/ src/linux-2.4/include. Configure doesn't use the same options when searching for libgd so it finds the libraries in /usr/include or in // include/ for crosscompilers. In that context I noticed that this configure help: --with-headers=PATH location of system headers to use [e.g. /usr/src/linux/include] [default=compiler default] may be missunderstood. The example seems to indicate that only kernel headers will be searched there. So I'm somewhat unsure about the original intentsion how all this was supposed to work and therefore don't know how exactly to fix this. Ralf From drepper@redhat.com Mon Nov 13 14:21:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Mon, 13 Nov 2000 14:21:00 -0000 Subject: glibc-2.2 and libgd References: <200010201725.TAA21606@lxplus015.cern.ch> <20001113181742.B8230@bacchus.dhis.org> Message-ID: Ralf Baechle writes: > These options are used due to the configure option --with-headers=/usr/ > src/linux-2.4/include. Configure doesn't use the same options when searching > for libgd so it finds the libraries in /usr/include or in // > include/ for crosscompilers. I have no problems with completely disabling the memusagestate use of sysinclude is given. > --with-headers=PATH location of system headers to use > [e.g. /usr/src/linux/include] > [default=compiler default] > > may be missunderstood. The example seems to indicate that only kernel > headers will be searched there. This is the real intention since normally no other header must be used. We have meanwhile relaxed this a bit and have not removed the -nostdinc. This option is only a security measure in case not all headers are found in the mentioned place. I have no preferences which way to fix this. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From aj@suse.de Tue Nov 14 06:56:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Tue, 14 Nov 2000 06:56:00 -0000 Subject: Fix for dl-cache.c committed Message-ID: With a static build, I got a segmentation fault since _dl_hwcap was referenced. The appended patch fixes this, Andreas 2000-11-14 Andreas Jaeger * sysdeps/generic/dl-cache.c (HWCAP_CHECK): Fix access to _dl_hwcap. ============================================================ Index: sysdeps/generic/dl-cache.c --- sysdeps/generic/dl-cache.c 2000/11/07 00:15:04 1.26 +++ sysdeps/generic/dl-cache.c 2000/11/14 14:54:33 @@ -220,7 +220,7 @@ hwcap = &_dl_hwcap; #define HWCAP_CHECK \ - if (hwcap && (cache_new->libs[middle].hwcap & *hwcap) > _dl_hwcap) \ + if (hwcap && (cache_new->libs[middle].hwcap & *hwcap) > *hwcap) \ continue SEARCH_CACHE (cache_new); } -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From jes@linuxcare.com Tue Nov 14 11:27:00 2000 From: jes@linuxcare.com (Jes Sorensen) Date: Tue, 14 Nov 2000 11:27:00 -0000 Subject: struct gmon_cg_arc_record Message-ID: <200011141926.UAA20529@lxplus015.cern.ch> Hi Playing with profiling under Linux/ia64 I noticed that struct gmon_cg_arc_record looks like this: struct gmon_cg_arc_record { char from_pc[sizeof (char *)]; /* address within caller's body */ char self_pc[sizeof (char *)]; /* address within callee's body */ char count[4]; /* number of arc traversals */ }; And the use of this struct within gmon/gmon.c:write_call_graph() is to declare it like this: struct gmon_cg_arc_record raw_arc[NARCS_PER_WRITEV] __attribute__ ((aligned (__alignof__ (char*)))); This means that when write_call_graph() fills the graph entries it causes misaligned stores on 64 bit architectures such as the ia64 and Alpha. I understand that gprof relies on this binary format, but my question is whether this is ABI specified or just glibc/gcc/gprof convention? If not, wouldn't it make sense to change the format for the ia64 and Alpha to pack data differently? Either by padding the struct or by making it look something like this: struct gmon_cg_arc_record { char from_pc1[sizeof (char *)]; /* address within caller's body */ char self_pc1[sizeof (char *)]; /* address within callee's body */ char count1[4]; /* number of arc traversals */ char count2[4]; /* number of arc traversals */ char from_pc2[sizeof (char *)]; /* address within caller's body */ char self_pc2[sizeof (char *)]; /* address within callee's body */ }; Comments, oppinions? Jes From jes@linuxcare.com Tue Nov 14 11:33:00 2000 From: jes@linuxcare.com (Jes Sorensen) Date: Tue, 14 Nov 2000 11:33:00 -0000 Subject: ia64 profile fixes Message-ID: <200011141932.UAA21062@lxplus015.cern.ch> Hi With this patch profiling works again on the ia64. Jes 2000-11-14 Jes Sorensen * NEWS: Update compile instructions for Linux/ia64. * sysdeps/ia64/_mcount.S: Call __mcount instead of __mcount_internal. * sysdeps/ia64/Makefile: Compile _mcount.S in subdir gmon as _mcount is required by profiled binaries. * sysdeps/unix/sysv/linux/ia64/machine-gmon.h: Moved to... * sysdeps/ia64/machine-gmon.h diff -urN --exclude=CVS --exclude=manual --exclude=*~ --exclude=*.orig --exclude=*.rej --exclude=core --exclude=*.mo --exclude=testdata /home/jes/cygnus/libc-2.2/NEWS libc-2.2/NEWS --- /home/jes/cygnus/libc-2.2/NEWS Sun Nov 5 18:41:07 2000 +++ libc-2.2/NEWS Tue Nov 14 14:10:17 2000 @@ -104,7 +104,8 @@ least the following versions of the GNU tools (the : * The Cygnus toolchain snapshot for the ia64 as of August 4 - including the provided set of patches. + including the provided set of patches. It is however recommend + you use the October 24 toolchain snapshot or a more recent version. OR alternatively you can try the following (the Cygnus toolchain is the recommended solution): @@ -117,11 +118,11 @@ ================================================= The library requires Linux kernel version 2.4.0-test4-000728 or -later to funtion properly. Besides that it currently does not have -support for debug and profiling libraries. Hence the following options +later to funtion properly. Besides that it support for debug libraries +is currently untested. Hence the following options are required for configuring the library: - --disable-debug --disable-profile --enable-kernel=2.4.0 + --disable-debug --enable-kernel=2.4.0 It is also important that you make sure the library picks up the appropriate kernel header files, if you do not have recent enough @@ -132,7 +133,6 @@ the library: --disable-debug - --disable-profile --disable-cvs --enable-kernel=2.4.0 --host=ia64-linux @@ -144,7 +144,7 @@ Good luck Jes Sorensen , -August 28th, 2000 +November 14th, 2000 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Version 2.1.3 diff -urN --exclude=CVS --exclude=manual --exclude=*~ --exclude=*.orig --exclude=*.rej --exclude=core --exclude=*.mo --exclude=testdata /home/jes/cygnus/libc-2.2/sysdeps/ia64/Makefile libc-2.2/sysdeps/ia64/Makefile --- /home/jes/cygnus/libc-2.2/sysdeps/ia64/Makefile Tue Sep 26 15:01:28 2000 +++ libc-2.2/sysdeps/ia64/Makefile Tue Nov 14 13:12:02 2000 @@ -1,6 +1,10 @@ # The ia64 `long double' is a distinct type we support. long-double-fcts = yes +ifeq ($(subdir),gmon) +sysdep_routines += _mcount +endif + ifeq ($(subdir), csu) CPPFLAGS-start.S = -D__ASSEMBLY__ endif diff -urN --exclude=CVS --exclude=manual --exclude=*~ --exclude=*.orig --exclude=*.rej --exclude=core --exclude=*.mo --exclude=testdata /home/jes/cygnus/libc-2.2/sysdeps/ia64/_mcount.S libc-2.2/sysdeps/ia64/_mcount.S --- /home/jes/cygnus/libc-2.2/sysdeps/ia64/_mcount.S Mon Jul 31 23:14:43 2000 +++ libc-2.2/sysdeps/ia64/_mcount.S Tue Nov 14 13:21:01 2000 @@ -60,7 +60,7 @@ mov loc3 = r15 // gcc uses r15 to pass the static link to nested functions mov out0 = in2 mov out1 = rp - br.call.sptk.few rp = __mcount_internal + br.call.sptk.few rp = __mcount ;; .here: { diff -urN --exclude=CVS --exclude=manual --exclude=*~ --exclude=*.orig --exclude=*.rej --exclude=core --exclude=*.mo --exclude=testdata /home/jes/cygnus/libc-2.2/sysdeps/ia64/machine-gmon.h libc-2.2/sysdeps/ia64/machine-gmon.h --- /home/jes/cygnus/libc-2.2/sysdeps/ia64/machine-gmon.h Wed Dec 31 19:00:00 1969 +++ libc-2.2/sysdeps/ia64/machine-gmon.h Wed Jun 21 09:46:14 2000 @@ -0,0 +1,26 @@ +/* Machine-specific calling sequence for `mcount' profiling function. IA-64. + Copyright (C) 1995, 1996, 1997, 2000 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Library General Public License as + published by the Free Software Foundation; either version 2 of the + License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Library General Public License for more details. + + You should have received a copy of the GNU Library General Public + License along with the GNU C Library; see the file COPYING.LIB. If not, + write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, + Boston, MA 02111-1307, USA. */ + +#define _MCOUNT_DECL(from, self) \ + void __mcount (u_long from, u_long self) + +/* Call __mcount with our the return PC for our caller, and the return + PC our caller will return to. Empty since we use an assembly stub + instead. */ +#define MCOUNT diff -urN --exclude=CVS --exclude=manual --exclude=*~ --exclude=*.orig --exclude=*.rej --exclude=core --exclude=*.mo --exclude=testdata /home/jes/cygnus/libc-2.2/sysdeps/unix/sysv/linux/ia64/machine-gmon.h libc-2.2/sysdeps/unix/sysv/linux/ia64/machine-gmon.h --- /home/jes/cygnus/libc-2.2/sysdeps/unix/sysv/linux/ia64/machine-gmon.h Wed Jun 21 00:18:38 2000 +++ libc-2.2/sysdeps/unix/sysv/linux/ia64/machine-gmon.h Wed Dec 31 19:00:00 1969 @@ -1,26 +0,0 @@ -/* Machine-specific calling sequence for `mcount' profiling function. IA-64. - Copyright (C) 1995, 1996, 1997, 2000 Free Software Foundation, Inc. - This file is part of the GNU C Library. - - The GNU C Library is free software; you can redistribute it and/or - modify it under the terms of the GNU Library General Public License as - published by the Free Software Foundation; either version 2 of the - License, or (at your option) any later version. - - The GNU C Library is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - Library General Public License for more details. - - You should have received a copy of the GNU Library General Public - License along with the GNU C Library; see the file COPYING.LIB. If not, - write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, - Boston, MA 02111-1307, USA. */ - -#define _MCOUNT_DECL(from, self) \ - void __mcount (u_long from, u_long self) - -/* Call __mcount with our the return PC for our caller, and the return - PC our caller will return to. Empty since we use an assembly stub - instead. */ -#define MCOUNT From drepper@redhat.com Tue Nov 14 11:54:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Tue, 14 Nov 2000 11:54:00 -0000 Subject: struct gmon_cg_arc_record References: <200011141926.UAA20529@lxplus015.cern.ch> Message-ID: Jes Sorensen writes: > Comments, oppinions? I've no opinion. What are Alpha people doing today. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From jes@linuxcare.com Tue Nov 14 12:14:00 2000 From: jes@linuxcare.com (Jes Sorensen) Date: Tue, 14 Nov 2000 12:14:00 -0000 Subject: struct gmon_cg_arc_record References: <200011141926.UAA20529@lxplus015.cern.ch> Message-ID: >>>>> "Ulrich" == Ulrich Drepper writes: Ulrich> Jes Sorensen writes: >> Comments, oppinions? Ulrich> I've no opinion. What are Alpha people doing today. I think they take the hit right now. Though profiling doesn't seem to work on the Alpha I have here. One alternative would be to change the following two contructs to use memcpy() instead: *(char **) raw_arc[nfilled].from_pc = (char *) frompc; *(char **) raw_arc[nfilled].self_pc = (char *)_gmonparam.tos[to_index].selfpc; That way we preserve the binary format and I don't think the overhead is noticable on other architectures presuming gcc will catch the fixed sized memcpy's. If thats ok with you, I'll cook up a patch straight away. Jes From drepper@redhat.com Tue Nov 14 12:37:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Tue, 14 Nov 2000 12:37:00 -0000 Subject: struct gmon_cg_arc_record References: <200011141926.UAA20529@lxplus015.cern.ch> Message-ID: Jes Sorensen writes: > If thats ok with you, I'll cook up a patch straight away. I have no problem changing this for IA-64. For Alpha rth should say whether he think this is a problem. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From jes@linuxcare.com Tue Nov 14 12:43:00 2000 From: jes@linuxcare.com (Jes Sorensen) Date: Tue, 14 Nov 2000 12:43:00 -0000 Subject: struct gmon_cg_arc_record References: <200011141926.UAA20529@lxplus015.cern.ch> Message-ID: >>>>> "Ulrich" == Ulrich Drepper writes: Ulrich> Jes Sorensen writes: >> If thats ok with you, I'll cook up a patch straight away. Ulrich> I have no problem changing this for IA-64. For Alpha rth Ulrich> should say whether he think this is a problem. My idea for a patch would solve the problem by changing the assignments in gmon/gmon.c - it touches generic code but I doubt it's too expensive. I tried it out and it seems to work, can you accept a change like this? Jes 2000-11-14 Jes Sorensen * gmon/gmon.c (write_call_graph): Use memcpy() to store pointer entries in gmon_cg_arc_record array to avoid misaligned stores on 64 bit architectures. --- /home/jes/cygnus/libc-2.2/gmon/gmon.c Tue Apr 18 22:39:11 2000 +++ libc-2.2/gmon/gmon.c Tue Nov 14 15:23:54 2000 @@ -236,9 +236,9 @@ to_index != 0; to_index = _gmonparam.tos[to_index].link) { - *(char **) raw_arc[nfilled].from_pc = (char *) frompc; - *(char **) raw_arc[nfilled].self_pc = - (char *)_gmonparam.tos[to_index].selfpc; + memcpy (&raw_arc[nfilled].from_pc, &frompc, sizeof (u_long)); + memcpy (&raw_arc[nfilled].self_pc, &_gmonparam.tos[to_index].selfpc, + sizeof (u_long)); *(int *) raw_arc[nfilled].count = _gmonparam.tos[to_index].count; if (++nfilled == NARCS_PER_WRITEV) From drepper@redhat.com Tue Nov 14 12:56:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Tue, 14 Nov 2000 12:56:00 -0000 Subject: struct gmon_cg_arc_record References: <200011141926.UAA20529@lxplus015.cern.ch> Message-ID: Jes Sorensen writes: > My idea for a patch would solve the problem by changing the > assignments in gmon/gmon.c - it touches generic code but I doubt it's > too expensive. Hum, for new 64-bit architecture I'd suggest changing the on-disk format. There is no reason to make things slower than necessary. For Alpha, I'd also go with a new format if rth thinks this is OK. The [4] in the data structure definition clearly is motivated by the use in 32-bit architecture. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From jes@linuxcare.com Tue Nov 14 13:14:00 2000 From: jes@linuxcare.com (Jes Sorensen) Date: Tue, 14 Nov 2000 13:14:00 -0000 Subject: struct gmon_cg_arc_record References: <200011141926.UAA20529@lxplus015.cern.ch> Message-ID: 64 bit port maintainers please read! >>>>> "Ulrich" == Ulrich Drepper writes: Ulrich> Hum, for new 64-bit architecture I'd suggest changing the Ulrich> on-disk format. There is no reason to make things slower than Ulrich> necessary. Ok Ulrich> For Alpha, I'd also go with a new format if rth thinks this is Ulrich> OK. Ulrich> The [4] in the data structure definition clearly is motivated Ulrich> by the use in 32-bit architecture. Hmmm something is certainly fishy here, comparing glibc-2.2 with the difinitions found in gprof it looks like we should update glibc to match gprof. Ie. the arc structure in gprof looks like this: struct raw_arc { /* FIXME: Checking a host compiler define means that we can't use a cross gprof to the alpha. */ #ifdef __alpha__ char from_pc[8]; char self_pc[8]; char count[8]; #else char from_pc[4]; char self_pc[4]; char count[4]; #endif }; We also have a mismatch in gmon_list_hdr: in glibc it looks like this: struct gmon_hist_hdr { char low_pc[sizeof (char *)]; /* base pc address of sample buffer */ char high_pc[sizeof (char *)]; /* max pc address of sampled buffer */ char hist_size[4]; /* size of sample buffer */ char prof_rate[4]; /* profiling clock rate */ char dimen[15]; /* phys. dim., usually "seconds" */ char dimen_abbrev; /* usually 's' for "seconds" */ }; For gprof it looks like this - note the extra version field: struct raw_phdr { /* FIXME: Checking a host compiler define means that we can't use a cross gprof to the alpha. */ #ifdef __alpha__ char low_pc[8]; /* base pc address of sample buffer */ char high_pc[8]; /* max pc address of sampled buffer */ #else char low_pc[4]; /* base pc address of sample buffer */ char high_pc[4]; /* max pc address of sampled buffer */ #endif char ncnt[4]; /* size of sample buffer (plus this header) */ char version[4]; /* version number */ char profrate[4]; /* profiling clock rate */ char spare[3*4]; /* reserved */ }; My suggestion would be that we change count in gmon_cg_arc_record to sizeof(char *) like it is in gprof and introduce the version field as well. Two questions, how will the latter affect architectures like the x86? Second what about Sparc64/MIPS64/PPC64? Do you guys have profile support running already that will break from this? Jes From jakub@redhat.com Tue Nov 14 13:25:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Tue, 14 Nov 2000 13:25:00 -0000 Subject: struct gmon_cg_arc_record References: <200011141926.UAA20529@lxplus015.cern.ch> Message-ID: <20001114222838.I635@sunsite.ms.mff.cuni.cz> On Tue, Nov 14, 2000 at 10:14:04PM +0100, Jes Sorensen wrote: > Two questions, how will the latter affect architectures like the x86? > Second what about Sparc64/MIPS64/PPC64? Do you guys have profile > support running already that will break from this? Nobody uses profiling on sparc64 yet (well, libc_p.a builds on it but I haven't ever tried to profile a 64bit sparc app yet and I doubt Ben Collins did). And I think mips64 and ppc64 have still more to go than sparc64. Jakub From drepper@redhat.com Tue Nov 14 13:28:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Tue, 14 Nov 2000 13:28:00 -0000 Subject: struct gmon_cg_arc_record References: <200011141926.UAA20529@lxplus015.cern.ch> Message-ID: Jes Sorensen writes: > struct raw_arc > { > /* FIXME: Checking a host compiler define means that we can't use > a cross gprof to the alpha. */ > #ifdef __alpha__ > char from_pc[8]; > char self_pc[8]; > char count[8]; > #else > char from_pc[4]; > char self_pc[4]; > char count[4]; > #endif > }; Doesn't this mean profiling on Alpha doesn't work at all? THen of course we should change it. > struct gmon_hist_hdr > { > char low_pc[sizeof (char *)]; /* base pc address of sample buffer */ > char high_pc[sizeof (char *)]; /* max pc address of sampled buffer */ > char hist_size[4]; /* size of sample buffer */ > char prof_rate[4]; /* profiling clock rate */ > char dimen[15]; /* phys. dim., usually "seconds" */ > char dimen_abbrev; /* usually 's' for "seconds" */ > }; > > For gprof it looks like this - note the extra version field: > > struct raw_phdr > { > /* FIXME: Checking a host compiler define means that we can't use > a cross gprof to the alpha. */ > #ifdef __alpha__ > char low_pc[8]; /* base pc address of sample buffer */ > char high_pc[8]; /* max pc address of sampled buffer */ > #else > char low_pc[4]; /* base pc address of sample buffer */ > char high_pc[4]; /* max pc address of sampled buffer */ > #endif > char ncnt[4]; /* size of sample buffer (plus this header) */ > > char version[4]; /* version number */ > char profrate[4]; /* profiling clock rate */ > char spare[3*4]; /* reserved */ > }; No, you misread the definition. The hist_size field corresponds to ncnt. The prof_rate rate to version. The dimen and dimen_abbrev field correspond to the profrate and spare field. So we cannot simply add a new field, we would have to reorder them. The question is: was it always like this? Profiling certainly worked for x86. > Two questions, how will the latter affect architectures like the x86? See above. The history has to be investigated. > Second what about Sparc64/MIPS64/PPC64? Do you guys have profile > support running already that will break from this? I wouldn't worry, only SPARC64 is at a stage where they can run something and I guess they still don't mind breaking something non-essential as this. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From jes@linuxcare.com Tue Nov 14 14:24:00 2000 From: jes@linuxcare.com (Jes Sorensen) Date: Tue, 14 Nov 2000 14:24:00 -0000 Subject: struct gmon_cg_arc_record References: <200011141926.UAA20529@lxplus015.cern.ch> Message-ID: Hi I am Cc'ing the binutils list on this. To those of you on this list who do not read libc-hacker, let me just give a brief description of the problem: Basically it looks like gprof was written with 32 bit architectures in mind and the on disk format of gmon.out quite shows this. When generating this format in memory on a machine like the ia64 we get misaligned stores so it seemed like a good idea to change the format at least for Linux/ia64. However it is not quite obvious whether profile support actually works under Linux/Alpha at the moment since there seems to be some inconsistency in the defines of the structures gmon_cg_arc_record vs and raw_arc. Thus I have attached a patch that cleans up the special casing of the struct formats for 64 bit architestures as well as declare 'count' as a long under Linux. I didn't dare to change this for OSF/1 etc. >>>>> "Ulrich" == Ulrich Drepper writes: Ulrich> Jes Sorensen writes: >> struct raw_arc { /* FIXME: Checking a host compiler define means >> that we can't use a cross gprof to the alpha. */ #ifdef __alpha__ >> char from_pc[8]; char self_pc[8]; char count[8]; #else char >> from_pc[4]; char self_pc[4]; char count[4]; #endif }; Ulrich> Doesn't this mean profiling on Alpha doesn't work at all? Ulrich> THen of course we should change it. Hmmm that was the impression I got at first, however looking a bit more at the gprof source I see that they operate on two formats, a binary and a run time format. Ie. for the Alpha they expect a count of 4 on the disk but it is moved to a count of 8 internally. Grmbl grmbl grmbl. gprof clearly tries to work on OSF/1 as well, however I can't find a definition of the structures on the OSF/1 box I searched on so I cannot verify what it expects. Ulrich> No, you misread the definition. The hist_size field Ulrich> corresponds to ncnt. The prof_rate rate to version. The Ulrich> dimen and dimen_abbrev field correspond to the profrate and Ulrich> spare field. Ulrich> So we cannot simply add a new field, we would have to reorder Ulrich> them. The question is: was it always like this? Profiling Ulrich> certainly worked for x86. Whoops, need to go study this some more I guess. Anyway my conclusion would be to recommend that we change the binary format for 64 bit arcitectures under Linux as you also recommended. It sounds like Jakub agrees as well. I have attached a patch for gprof for those who wants to play with it and a patch for glibc. Jes 2000-11-14 Jes Sorensen * gmon.h: Make definitions of low_pc, high_pc, from_pc, self_pc sizeof(char *) to work on 64 bit architectures and not just the Alpha which was special cased. * gmon_out.h (struct gmon_cg_arc_record): count element should be 64 bit on 64 bit architectures under Linux to match glibc-2.2. --- gprof/gmong.h-old Sun Apr 4 16:42:59 1999 +++ gprof/gmon.h Tue Nov 14 17:04:31 2000 @@ -37,15 +37,8 @@ struct raw_phdr { - /* FIXME: Checking a host compiler define means that we can't use - a cross gprof to the alpha. */ -#ifdef __alpha__ - char low_pc[8]; /* base pc address of sample buffer */ - char high_pc[8]; /* max pc address of sampled buffer */ -#else - char low_pc[4]; /* base pc address of sample buffer */ - char high_pc[4]; /* max pc address of sampled buffer */ -#endif + char low_pc[sizeof (char *)]; /* base pc address of sample buffer */ + char high_pc[sizeof (char *)]; /* max pc address of sampled buffer */ char ncnt[4]; /* size of sample buffer (plus this header) */ char version[4]; /* version number */ @@ -57,15 +50,8 @@ struct old_raw_phdr { - /* FIXME: Checking a host compiler define means that we can't use - a cross gprof to the alpha. */ -#ifdef __alpha__ - char low_pc[8]; /* base pc address of sample buffer */ - char high_pc[8]; /* max pc address of sampled buffer */ -#else - char low_pc[4]; /* base pc address of sample buffer */ - char high_pc[4]; /* max pc address of sampled buffer */ -#endif + char low_pc[sizeof (char *)]; /* base pc address of sample buffer */ + char high_pc[sizeof (char *)]; /* max pc address of sampled buffer */ char ncnt[4]; /* size of sample buffer (plus this header) */ /* FIXME: Checking host compiler defines here means that we can't @@ -134,15 +120,11 @@ */ struct raw_arc { - /* FIXME: Checking a host compiler define means that we can't use - a cross gprof to the alpha. */ -#ifdef __alpha__ - char from_pc[8]; - char self_pc[8]; - char count[8]; + char from_pc[sizeof (char *)]; + char self_pc[sizeof (char *)]; +#ifdef linux + char count[sizeof (char *)]; #else - char from_pc[4]; - char self_pc[4]; char count[4]; #endif }; --- gprof/gmon_out.h-old Tue Nov 14 16:46:44 2000 +++ gprof/gmon_out.h Tue Nov 14 17:01:14 2000 @@ -45,7 +45,11 @@ { char from_pc[sizeof (char*)]; /* address within caller's body */ char self_pc[sizeof (char*)]; /* address within callee's body */ +#ifdef linux + char count[sizeof (char*)]; /* number of arc traversals */ +#else char count[4]; /* number of arc traversals */ +#endif }; #endif /* gmon_out_h */ ---------------- For glibc: 2000-11-14 Jes Sorensen * gmon/sys/gmon_out.h (struct gmon_cg_arc_record): Change size of count element to sizeof (char *). * gmon/gmon.c (write_call_graph): --- /home/jes/cygnus/libc-2.2/gmon/sys/gmon_out.h Sun Aug 10 13:02:27 1997 +++ libc-2.2/gmon/sys/gmon_out.h Tue Nov 14 17:06:10 2000 @@ -72,7 +72,7 @@ { char from_pc[sizeof (char *)]; /* address within caller's body */ char self_pc[sizeof (char *)]; /* address within callee's body */ - char count[4]; /* number of arc traversals */ + char count[sizeof (char *)]; /* number of arc traversals */ }; __END_DECLS --- /home/jes/cygnus/libc-2.2/gmon/gmon.c Tue Apr 18 22:39:11 2000 +++ libc-2.2/gmon/gmon.c Tue Nov 14 17:23:55 2000 @@ -239,7 +239,7 @@ *(char **) raw_arc[nfilled].from_pc = (char *) frompc; *(char **) raw_arc[nfilled].self_pc = (char *)_gmonparam.tos[to_index].selfpc; - *(int *) raw_arc[nfilled].count = _gmonparam.tos[to_index].count; + *(long *) raw_arc[nfilled].count = _gmonparam.tos[to_index].count; if (++nfilled == NARCS_PER_WRITEV) { From ian@zembu.com Tue Nov 14 21:15:00 2000 From: ian@zembu.com (Ian Lance Taylor) Date: Tue, 14 Nov 2000 21:15:00 -0000 Subject: struct gmon_cg_arc_record References: <200011141926.UAA20529@lxplus015.cern.ch> Message-ID: <20001115042349.15398.qmail@daffy.airs.com> From: Jes Sorensen Date: 14 Nov 2000 23:24:22 +0100 - /* FIXME: Checking a host compiler define means that we can't use - a cross gprof to the alpha. */ -#ifdef __alpha__ - char low_pc[8]; /* base pc address of sample buffer */ - char high_pc[8]; /* max pc address of sampled buffer */ -#else - char low_pc[4]; /* base pc address of sample buffer */ - char high_pc[4]; /* max pc address of sampled buffer */ -#endif + char low_pc[sizeof (char *)]; /* base pc address of sample buffer */ + char high_pc[sizeof (char *)]; /* max pc address of sampled buffer */ Yuck. If we're going to touch this, can't we avoid sizeof(char*)? It prevents cross-configurations, and there is no particular reason to believe that it is correct on any given system. At the very least make it something which can be configured for a particular system, rather than trusting that the compiler and the C library agree on this size. Ian From wmglo@dent.med.uni-muenchen.de Wed Nov 15 01:51:00 2000 From: wmglo@dent.med.uni-muenchen.de (Wolfram Gloger) Date: Wed, 15 Nov 2000 01:51:00 -0000 Subject: LinuxThreads' stacks can collide with malloc Message-ID: <20001115095133.8242.qmail@md.dent.med.uni-muenchen.de> Hello, I've seen strange crashes in multi-threaded applications that almost completely fill up the available address space (with malloc or anonymous mmap()) on i586. I am confident now that the problems are caused by LinuxThreads' use of mmap(... MAP_FIXED) to allocate the thread stacks. The stacks are unmapped at thread exit time, so if a stack region is later occupied by e.g. malloc, and still later another thread is started, it may corrupt the heap due to the use of MAP_FIXED to re-claim the stack region. Therefore, I propose to not unmap the stacks but to only remap them as PROT_NONE in the !FLOATING_STACKS case, effectively reserving the region. This doesn't completely solve the problem but should be an improvement. Patch appended below. I noticed that FLOATING_STACKS can only be enabled on i686. Wouldn't the ldt tricks work on i586, too? Regards, Wolfram. 2000-11-15 Wolfram Gloger * manager.c (pthread_free()) [!FLOATING_STACKS]: Only remap the stack to PROT_NONE, don't unmap it, avoiding collisions with malloc. --- manager.c 2000/11/14 17:30:27 1.1 +++ manager.c 2000/11/15 09:45:57 @@ -418,7 +418,7 @@ new_thread_bottom = (char *) map_addr + guardsize; new_thread = ((pthread_descr) (new_thread_bottom + stacksize)) - 1; -# else +# else /* !FLOATING_STACKS */ if (attr != NULL) { guardsize = page_roundup (attr->__guardsize, granularity); @@ -696,23 +696,24 @@ { size_t guardsize = th->p_guardsize; /* Free the stack and thread descriptor area */ -#ifdef NEED_SEPARATE_REGISTER_STACK char *guardaddr = th->p_guardaddr; - /* We unmap exactly what we mapped, in case there was something - else in the same region. Guardaddr is always set, eve if - guardsize is 0. This allows us to compute everything else. */ + /* Guardaddr is always set, even if guardsize is 0. This allows + us to compute everything else. */ size_t stacksize = (char *)(th+1) - guardaddr - guardsize; - /* Unmap the register stack, which is below guardaddr. */ - munmap((caddr_t)(guardaddr-stacksize), - 2 * stacksize + th->p_guardsize); +#ifdef NEED_SEPARATE_REGISTER_STACK + /* Take account of the register stack, which is below guardaddr. */ + guardaddr -= stacksize; + stacksize *= 2; +#endif +#if FLOATING_STACKS + /* Can unmap safely. */ + munmap(guardaddr, stacksize + guardsize); #else - char *guardaddr = th->p_guardaddr; - /* We unmap exactly what we mapped, in case there was something - else in the same region. Guardaddr is always set, eve if - guardsize is 0. This allows us to compute everything else. */ - size_t stacksize = (char *)(th+1) - guardaddr - guardsize; - - munmap (guardaddr, stacksize + guardsize); + /* Only remap to PROT_NONE, so that the region is reserved in + case we map the stack again later. Avoid collision with + other mmap()s, in particular by malloc(). */ + mmap(guardaddr, stacksize + guardsize, PROT_NONE, + MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, -1, 0); #endif } } From jakub@redhat.com Wed Nov 15 05:28:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Wed, 15 Nov 2000 05:28:00 -0000 Subject: [PATCH] Fix _dl_argv on alpha and sparc, fix tests-static Message-ID: <20001115143131.J635@sunsite.ms.mff.cuni.cz> Hi! This patch fixes two things: the test for whether run-program-prefix should be empty cannot be done using ifeq, because that's at the parsing time while we need to do the test at invocation time, because otherwise we call the program through ld.so even if it is in tests-static. The other issue is the reason why tst-mtrace is failing on alpha: when alpha/sparc32/sparc64 copy down argv/envp/aux arrays, they don't update _dl_argv, so it point usually somewhere into environment and mtrace is using dladdr to print where the allocation comes from (and in the alpha case it contained some spaces which mtrace program was confused about). I think ia64 does it right. I found also a bug in sparc64 dl-machine.h, where if there were some aux entries, it looped back to copying environment, not aux data, so it could copy more than it should. 2000-11-15 Jakub Jelinek * Makeconfig (run-program-prefix): Move test-static test into the variable. * sysdeps/alpha/dl-machine.h (RTLD_START): Update _dl_argv. * sysdeps/sparc/sparc32/dl-machine.h (RTLD_START): Likewise, schedule instructions. * sysdeps/sparc/sparc64/dl-machine.h (RTLD_START): Likewise, schedule instructions, fix a bug in copying auxiliary data. --- libc/Makeconfig.jj Thu Nov 2 17:08:05 2000 +++ libc/Makeconfig Wed Nov 15 13:56:05 2000 @@ -495,12 +495,9 @@ sysdep-library-path = \ $(subst $(empty) ,:,$(strip $(patsubst -Wl$(comma)-rpath-link=%, %,\ $(filter -Wl$(comma)-rpath-link=%,\ $(sysdep-LDFLAGS))))) -ifeq (,$(findstring $(notdir $(built-program-file)), $(tests-static))) -run-program-prefix = $(elf-objpfx)$(rtld-installed-name) \ - --library-path $(rpath-link)$(patsubst %,:%,$(sysdep-library-path)) -else -run-program-prefix = -endif +run-program-prefix = $(if $(findstring $(notdir $(built-program-file)), $(tests-static)),, \ + $(elf-objpfx)$(rtld-installed-name) \ + --library-path $(rpath-link)$(patsubst %,:%,$(sysdep-library-path))) else run-program-prefix = endif --- libc/sysdeps/alpha/dl-machine.h.jj Wed Oct 25 11:14:38 2000 +++ libc/sysdeps/alpha/dl-machine.h Wed Nov 15 11:25:49 2000 @@ -314,10 +314,14 @@ $fixup_stack: involves copying everything down, since the stack pointer must always be 16-byte aligned. */ ldq $2, 0($sp) + ldq $5, _dl_argv + subq $31, $1, $6 subq $2, $1, $2 + s8addq $6, $5, $5 mov $sp, $4 s8addq $1, $sp, $3 stq $2, 0($sp) + stq $5, _dl_argv /* Copy down argv. */ 0: ldq $5, 8($3) addq $4, 8, $4 --- libc/sysdeps/sparc/sparc32/dl-machine.h.jj Wed Oct 25 11:14:48 2000 +++ libc/sysdeps/sparc/sparc32/dl-machine.h Wed Nov 15 10:57:59 2000 @@ -224,23 +224,29 @@ _dl_start_user: sethi %hi(__libc_stack_end), %g2 or %g2, %lo(__libc_stack_end), %g2 ld [%l7 + %g2], %l1 + sethi %hi(_dl_skip_args), %g2 add %sp, 6*4, %l2 + or %g2, %lo(_dl_skip_args), %g2 st %l2, [%l1] /* See if we were run as a command with the executable file name as an extra leading argument. If so, adjust the contents of the stack. */ - sethi %hi(_dl_skip_args), %g2 - or %g2, %lo(_dl_skip_args), %g2 ld [%l7+%g2], %i0 ld [%i0], %i0 tst %i0 beq 3f ld [%sp+22*4], %i5 /* load argc */ /* Find out how far to shift. */ + sethi %hi(_dl_argv), %l3 + or %l3, %lo(_dl_argv), %l3 + ld [%l7+%l3], %l3 sub %i5, %i0, %i5 + ld [%l3], %l4 sll %i0, 2, %i2 st %i5, [%sp+22*4] + sub %l4, %i2, %l4 add %sp, 23*4, %i1 add %i1, %i2, %i2 + st %l4, [%l3] /* Copy down argv */ 21: ld [%i2], %i3 add %i2, 4, %i2 --- libc/sysdeps/sparc/sparc64/dl-machine.h.jj Wed Oct 25 11:14:48 2000 +++ libc/sysdeps/sparc/sparc64/dl-machine.h Wed Nov 15 11:06:14 2000 @@ -544,38 +544,43 @@ _start: _dl_start_user: /* Load the GOT register. */ 1: call 11f - sethi %hi(_GLOBAL_OFFSET_TABLE_-(1b-.)),%l7 -11: or %l7,%lo(_GLOBAL_OFFSET_TABLE_-(1b-.)),%l7 - add %l7,%o7,%l7 - /* Save the user entry point address in %l0. */ - mov %o0,%l0 + sethi %hi(_GLOBAL_OFFSET_TABLE_-(1b-.)), %l7 +11: or %l7, %lo(_GLOBAL_OFFSET_TABLE_-(1b-.)), %l7 /* Store the highest stack address. */ sethi %hi(__libc_stack_end), %g5 + add %l7, %o7, %l7 or %g5, %lo(__libc_stack_end), %g5 + /* Save the user entry point address in %l0. */ + mov %o0, %l0 ldx [%l7 + %g5], %l1 + sethi %hi(_dl_skip_args), %g5 add %sp, 6*8, %l2 - stx %l2, [%l1] /* See if we were run as a command with the executable file name as an extra leading argument. If so, we must shift things around since we must keep the stack doubleword aligned. */ - sethi %hi(_dl_skip_args), %g5 or %g5, %lo(_dl_skip_args), %g5 - ldx [%l7+%g5], %i0 + stx %l2, [%l1] + ldx [%l7 + %g5], %i0 ld [%i0], %i0 brz,pt %i0, 2f - ldx [%sp+" __S(STACK_BIAS) "+22*8], %i5 + ldx [%sp + " __S(STACK_BIAS) " + 22*8], %i5 /* Find out how far to shift. */ + sethi %hi(_dl_argv), %l4 sub %i5, %i0, %i5 - sllx %i0, 3, %i2 - stx %i5, [%sp+" __S(STACK_BIAS) "+22*8] - add %sp, " __S(STACK_BIAS) "+23*8, %i1 - add %i1, %i2, %i2 + or %l4, %lo(_dl_argv), %l4 + sllx %i0, 3, %l6 + ldx [%l7 + %l4], %l4 + stx %i5, [%sp + " __S(STACK_BIAS) " + 22*8] + add %sp, " __S(STACK_BIAS) " + 23*8, %i1 + add %i1, %l6, %i2 + ldx [%l4], %l5 /* Copy down argv. */ 12: ldx [%i2], %i3 add %i2, 8, %i2 stx %i3, [%i1] brnz,pt %i3, 12b add %i1, 8, %i1 + sub %l5, %l6, %l5 /* Copy down envp. */ 13: ldx [%i2], %i3 add %i2, 8, %i2 @@ -584,18 +589,19 @@ _dl_start_user: add %i1, 8, %i1 /* Copy down auxiliary table. */ 14: ldx [%i2], %i3 - ldx [%i2+8], %i4 + ldx [%i2 + 8], %i4 add %i2, 16, %i2 stx %i3, [%i1] - stx %i4, [%i1+8] - brnz,pt %i3, 13b + stx %i4, [%i1 + 8] + brnz,pt %i3, 14b add %i1, 16, %i1 + stx %l5, [%l4] /* %o0 = _dl_loaded, %o1 = argc, %o2 = argv, %o3 = envp. */ 2: sethi %hi(_dl_loaded), %o0 - add %sp, " __S(STACK_BIAS) "+23*8, %o2 + add %sp, " __S(STACK_BIAS) " + 23*8, %o2 orcc %o0, %lo(_dl_loaded), %o0 sllx %i5, 3, %o3 - ldx [%l7+%o0], %o0 + ldx [%l7 + %o0], %o0 add %o3, 8, %o3 mov %i5, %o1 add %o2, %o3, %o3 @@ -604,7 +610,7 @@ _dl_start_user: /* Pass our finalizer function to the user in %g1. */ sethi %hi(_dl_fini), %g1 or %g1, %lo(_dl_fini), %g1 - ldx [%l7+%g1], %g1 + ldx [%l7 + %g1], %g1 /* Jump to the user's entry point and deallocate the extra stack we got. */ jmp %l0 add %sp, 6*8, %sp Jakub From jakub@redhat.com Wed Nov 15 05:44:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Wed, 15 Nov 2000 05:44:00 -0000 Subject: [PATCH] Testcase for dladdr Message-ID: <20001115144739.K635@sunsite.ms.mff.cuni.cz> Hi! This patch adds a testcase whether _dl_argv is setup properly. 2000-11-15 Jakub Jelinek * dlfcn/default.c (main): Add test for dladdr of main returning argv[0] in dli_fname field. --- libc/dlfcn/default.c.jj Sat Sep 16 11:05:17 2000 +++ libc/dlfcn/default.c Wed Nov 15 14:19:57 2000 @@ -1,5 +1,6 @@ #include #include +#include extern int test_in_mod1 (void *); @@ -12,7 +13,22 @@ main (int argc, char *argv[]) int (*ifp) (void); void *p; int result = 0; - + Dl_info info; + + dladdr(main, &info); + if (info.dli_fname == NULL) + { + printf ("%s: dladdr returns NULL dli_fname\n", __FILE__); + result = 1; + } + else if (strcmp (info.dli_fname, argv[0])) + { + printf ("%s: dladdr returned '%s' as dli_fname\n", __FILE__, info.dli_fname); + result = 1; + } + else + printf ("%s: dladdr returned correct dli_fname\n", __FILE__); + /* Find function `main'. */ p = dlsym (RTLD_DEFAULT, "main"); if (p == NULL) Jakub From jes@linuxcare.com Wed Nov 15 08:07:00 2000 From: jes@linuxcare.com (Jes Sorensen) Date: Wed, 15 Nov 2000 08:07:00 -0000 Subject: struct gmon_cg_arc_record References: <200011141926.UAA20529@lxplus015.cern.ch> <20001115042349.15398.qmail@daffy.airs.com> Message-ID: >>>>> "Ian" == Ian Lance Taylor writes: Ian> Yuck. If we're going to touch this, can't we avoid Ian> sizeof(char*)? It prevents cross-configurations, and there is no Ian> particular reason to believe that it is correct on any given Ian> system. At the very least make it something which can be Ian> configured for a particular system, rather than trusting that the Ian> compiler and the C library agree on this size. I wasn't aware of these cross compiler issues hence the reason why I used the char * approach. How do you recommend we fix this then, sizeof(unsigned long), new data type, use the glibc provided headers if available? Jes From ian@zembu.com Wed Nov 15 08:51:00 2000 From: ian@zembu.com (Ian Lance Taylor) Date: Wed, 15 Nov 2000 08:51:00 -0000 Subject: struct gmon_cg_arc_record References: <200011141926.UAA20529@lxplus015.cern.ch> <20001115042349.15398.qmail@daffy.airs.com> Message-ID: <20001115164922.17501.qmail@daffy.airs.com> From: Jes Sorensen Date: 15 Nov 2000 17:07:12 +0100 >>>>> "Ian" == Ian Lance Taylor writes: Ian> Yuck. If we're going to touch this, can't we avoid Ian> sizeof(char*)? It prevents cross-configurations, and there is no Ian> particular reason to believe that it is correct on any given Ian> system. At the very least make it something which can be Ian> configured for a particular system, rather than trusting that the Ian> compiler and the C library agree on this size. I wasn't aware of these cross compiler issues hence the reason why I used the char * approach. How do you recommend we fix this then, sizeof(unsigned long), new data type, use the glibc provided headers if available? I recommend making the size of the fields a value substituted by configure. That will permit us to set the size based on the configuration target. Use the current defaults. If glibc has header files which define the appropriate size, or something, then we can use them if available when configured for a native system. Ian From drepper@redhat.com Wed Nov 15 09:38:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Wed, 15 Nov 2000 09:38:00 -0000 Subject: LinuxThreads' stacks can collide with malloc References: <20001115095133.8242.qmail@md.dent.med.uni-muenchen.de> Message-ID: Wolfram Gloger writes: > The stacks are unmapped at thread exit time, so if a stack region is > later occupied by e.g. malloc, and still later another thread is > started, it may corrupt the heap due to the use of MAP_FIXED to > re-claim the stack region. You mean the kernel allows to mmap() with MAP_FIXED in a place below the sbrk? This sounds like a kernel bug. > I noticed that FLOATING_STACKS can only be enabled on i686. Wouldn't > the ldt tricks work on i586, too? It does. Most people only build i386 and i686 versions. I wanted to have a way to get the version without LDT use and one with. In addition, I've never looked at the performance of the ldt use on anything but i686. I think these usages were improved in modern CPUs since M$ is using this method, too. On older versions it's dog slow. We can of course change it to use this also for i586 but I want some evidence that this is really wanted. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From wmglo@dent.med.uni-muenchen.de Wed Nov 15 10:09:00 2000 From: wmglo@dent.med.uni-muenchen.de (Wolfram Gloger) Date: Wed, 15 Nov 2000 10:09:00 -0000 Subject: LinuxThreads' stacks can collide with malloc References: <20001115095133.8242.qmail@md.dent.med.uni-muenchen.de> Message-ID: <20001115180916.10201.qmail@md.dent.med.uni-muenchen.de> > > The stacks are unmapped at thread exit time, so if a stack region is > > later occupied by e.g. malloc, and still later another thread is > > started, it may corrupt the heap due to the use of MAP_FIXED to > > re-claim the stack region. > > You mean the kernel allows to mmap() with MAP_FIXED in a place below > the sbrk? This sounds like a kernel bug. No, when the address space gets nearly full malloc() can allocate chunks using mmap() (w/o MAP_FIXED) so high that they collide with the fixed regions used by LinuxThreads for the stacks. But anyway, MAP_FIXED definitely works below sbrk, too. When you use MAP_FIXED, you really must know what you're doing. The real problem IMHO is that it's impossible in Unix to probe whether an address range is available for mapping with MAP_FIXED. That would require an additional MAP_ONLY_IF_FREE flag or something. > > I noticed that FLOATING_STACKS can only be enabled on i686. Wouldn't > > the ldt tricks work on i586, too? > > It does. Most people only build i386 and i686 versions. I wanted to > have a way to get the version without LDT use and one with. OK. > In > addition, I've never looked at the performance of the ldt use on > anything but i686. I think these usages were improved in modern CPUs > since M$ is using this method, too. On older versions it's dog slow. Right, I'll do a performance check and let you know. > We can of course change it to use this also for i586 but I want some > evidence that this is really wanted. I for one would really appreciate any change that lets us avoid MAP_FIXED. Regards, Wolfram. From drepper@redhat.com Wed Nov 15 10:26:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Wed, 15 Nov 2000 10:26:00 -0000 Subject: LinuxThreads' stacks can collide with malloc References: <20001115095133.8242.qmail@md.dent.med.uni-muenchen.de> <20001115180916.10201.qmail@md.dent.med.uni-muenchen.de> Message-ID: Wolfram Gloger writes: > I for one would really appreciate any change that lets us avoid > MAP_FIXED. glibc 2.3 will have this (probably with the exception of a few architecture like m68k) since we'll have everywhere a thread register. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Wed Nov 15 15:03:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Wed, 15 Nov 2000 15:03:00 -0000 Subject: Set LANGUAGE=C LC_ALL=C for make install References: <20001110212031.A6133@valinux.com> Message-ID: "H . J . Lu" writes: > If LANGUAGE=C LC_ALL=C is recommended for make install, why not set > them for make install in Makefile? Here is a patch. OK. I've applied it. Thanks, -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Wed Nov 15 15:12:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Wed, 15 Nov 2000 15:12:00 -0000 Subject: tst-gettext2: Better tests References: Message-ID: Andreas Jaeger writes: > The output from tst-gettext2 doesn't look right, I've created a file > with the expected output. What do you think of this? Shall I commit > it? I agree that something looks strange. But I want to look at it first. No reason to break builds because of this. The change can go in once the problem is fixed. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Wed Nov 15 15:19:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Wed, 15 Nov 2000 15:19:00 -0000 Subject: tst-gettext2: Better tests References: Message-ID: Andreas Jaeger writes: > The output from tst-gettext2 doesn't look right, I've created a file > with the expected output. What do you think of this? Shall I commit > it? I know what's wrong (should have looked right away). You are creating the locale directories but don't populate them. The patch which went in along with this test made the domain selecting dependent on the selected locale. But if there is no locale data you cannot select the locale. The tst-gettext2.sh script must generate (or better: copy) locale data for the lang1 and lang2 domains. And LOCPATH must be set to ${objpfx}domaindir and not ${common_objpfx}localedata. I'll be checking in patches shortly. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Wed Nov 15 17:48:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Wed, 15 Nov 2000 17:48:00 -0000 Subject: [PATCH] Build proper bits/syscall.h on sparc* (take 2) References: <20001113175034.C635@sunsite.ms.mff.cuni.cz> Message-ID: Jakub Jelinek writes: > Below is a new version of my patch from Nov, 9th, because that one had a > missing semicolon (in the rm command which was the only one added after > testing it out). I've applied the patch now. Thanks, -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Wed Nov 15 18:08:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Wed, 15 Nov 2000 18:08:00 -0000 Subject: [PATCH] Fix _dl_argv on alpha and sparc, fix tests-static References: <20001115143131.J635@sunsite.ms.mff.cuni.cz> Message-ID: Jakub Jelinek writes: > 2000-11-15 Jakub Jelinek > > * Makeconfig (run-program-prefix): Move test-static test into the > variable. > > * sysdeps/alpha/dl-machine.h (RTLD_START): Update _dl_argv. > * sysdeps/sparc/sparc32/dl-machine.h (RTLD_START): Likewise, > schedule instructions. > * sysdeps/sparc/sparc64/dl-machine.h (RTLD_START): Likewise, > schedule instructions, fix a bug in copying auxiliary data. I've applied the patch now. Thanks, -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Wed Nov 15 18:14:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Wed, 15 Nov 2000 18:14:00 -0000 Subject: [PATCH] Testcase for dladdr References: <20001115144739.K635@sunsite.ms.mff.cuni.cz> Message-ID: Jakub Jelinek writes: > This patch adds a testcase whether _dl_argv is setup properly. Thanks, I've added it. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From jakub@redhat.com Thu Nov 16 03:33:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Thu, 16 Nov 2000 03:33:00 -0000 Subject: [PATCH] Fix printf_fphex Message-ID: <20001116123648.Q635@sunsite.ms.mff.cuni.cz> Hi! No wonder why printf_fphex did not work properly on alpha, it is wonder why it works on other platforms though... 2000-11-16 Jakub Jelinek * sysdeps/generic/printf_fphex.c (__printf_fphex): Compute correctly end of wexpbuf buffer. --- libc/sysdeps/generic/printf_fphex.c.jj Mon Oct 16 16:19:42 2000 +++ libc/sysdeps/generic/printf_fphex.c Thu Nov 16 06:08:39 2000 @@ -422,7 +422,8 @@ __printf_fphex (FILE *fp, /* Now we can compute the exponent string. */ expstr = _itoa_word (exponent, expbuf + sizeof expbuf, 10, 0); - wexpstr = _itowa_word (exponent, wexpbuf + sizeof wexpbuf, 10, 0); + wexpstr = _itowa_word (exponent, + wexpbuf + sizeof wexpbuf / sizeof (wchar_t), 10, 0); /* Now we have all information to compute the size. */ width -= ((negative || info->showsign || info->space) Jakub From aj@suse.de Thu Nov 16 03:53:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Thu, 16 Nov 2000 03:53:00 -0000 Subject: [PATCH] Fix printf_fphex References: <20001116123648.Q635@sunsite.ms.mff.cuni.cz> Message-ID: Thanks a lot for tracking this down and fixing it finally (I didn't try it yet but I trust you ;-). Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From aj@suse.de Thu Nov 16 05:42:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Thu, 16 Nov 2000 05:42:00 -0000 Subject: FYI: Fixed PPC bits/fcntl.h Message-ID: I've committed the following patch to CVS, Andreas 2000-11-16 Andreas Jaeger * sysdeps/unix/sysv/linux/powerpc/bits/fcntl.h: Remove duplicate definition of F_GETLK, F_SETLK, F_SETLKW. ============================================================ Index: sysdeps/unix/sysv/linux/powerpc/bits/fcntl.h --- sysdeps/unix/sysv/linux/powerpc/bits/fcntl.h 2000/09/29 20:24:31 1.4 +++ sysdeps/unix/sysv/linux/powerpc/bits/fcntl.h 2000/11/16 13:41:35 @@ -64,9 +64,6 @@ #define F_SETFD 2 /* Set file descriptor flags. */ #define F_GETFL 3 /* Get file status flags. */ #define F_SETFL 4 /* Set file status flags. */ -#define F_GETLK 5 /* Get record locking info. */ -#define F_SETLK 6 /* Set record locking info (non-blocking). */ -#define F_SETLKW 7 /* Set record locking info (blocking). */ #ifndef __USE_FILE_OFFSET64 # define F_GETLK 5 /* Get record locking info. */ -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From drepper@redhat.com Thu Nov 16 10:05:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Thu, 16 Nov 2000 10:05:00 -0000 Subject: [PATCH] Fix printf_fphex References: <20001116123648.Q635@sunsite.ms.mff.cuni.cz> Message-ID: Jakub Jelinek writes: > No wonder why printf_fphex did not work properly on alpha, it is wonder why > it works on other platforms though... Dunno. Thanks for the patch, it's in now. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Mon Nov 20 01:20:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Mon, 20 Nov 2000 01:20:00 -0000 Subject: last batch of changes Message-ID: I've started working on removing more warnings. The configparms file I'm currently using is CFLAGS = -march=pentiumpro -mcpu=i686 -O3 -g -D__USE_STRING_INLINES -fssa -freorder-blocks -Wall -Wcast-qual -Wbad-function-cast -Wmissing-noreturn -Wmissing-prototypes -Wmissing-declarations -Wcomment -Wcomments -Wtrigraphs -Wsign-compare -Wfloat-equal -Wmultichar and I'll try to remove as many warnings as possible. There are some warnings which cannot be removed without effecting code generation in a negative way (e.g., removing const from a global variable) and everything which doesn't change or improves code generation should be done. Don't know whether anybody has interest in joining me to do this. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From jakub@redhat.com Mon Nov 20 04:12:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Mon, 20 Nov 2000 04:12:00 -0000 Subject: linuxthreads/ex11 issues Message-ID: <20001120131659.U635@sunsite.ms.mff.cuni.cz> Hi! Examples/ex11.c seems to get stuck on alphaev6, alpha and i686 (all of them 4 CPU boxes) from time to time. E.g. if I cut'n'paste the ex11 invocation command from make check into shell and run it 100 times, it locks up on i686 after some 40 invocations, on alpha it gets stuck every ~ 5 invocations or so. Anybody else can reproduce it? E.g. on alpha I see: * 3 Thread 7176 (LWP 31955) 0x20000010154 in __pthread_rwlock_timedwrlock (rwlock=0x120100fa0, abstime=0x3ffff1ff970) at restart.h:34 2 Thread 2049 (LWP 31948) 0x20000337c4c in __poll (fds=0x20001126d00, nfds=1, timeout=2000) at ../sysdeps/unix/sysv/linux/poll.c:63 1 Thread 1024 (LWP 31947) __sigsuspend () at ../sysdeps/unix/sysv/linux/alpha/sigsuspend.S:42 and from the output of the program it is clear that thread 3 (writer thread 6) has succeeded just once, then tried again once and never succeeded again. Yet (gdb) bt #0 __sigsuspend () at ../sysdeps/unix/sysv/linux/alpha/sigsuspend.S:42 #1 0x2000000bc50 in __pthread_wait_for_restart_signal (self=0x3ffff1ffa60) at pthread.c:898 #2 0x20000010154 in __pthread_rwlock_timedwrlock (rwlock=0x120100fa0, abstime=0x3ffff1ff970) at restart.h:34 #3 0x120000c74 in reader_thread (nr=0x6) at Examples/ex11.c:112 #4 0x20000009b88 in pthread_start_thread (arg=0x0) at manager.c:274 (gdb) p *rwlock $6 = {__rw_lock = {__status = 0, __spinlock = 736}, __rw_readers = 0, __rw_writer = 0x0, __rw_read_waiting = 0x0, __rw_write_waiting = 0x0, __rw_kind = 2, __rw_pshared = 0} I think it is in int was_on_queue; __pthread_lock (&rwlock->__rw_lock, self); was_on_queue = remove_from_queue (&rwlock->__rw_read_waiting, self); __pthread_unlock (&rwlock->__rw_lock); if (was_on_queue) { __pthread_set_own_extricate_if (self, 0); return ETIMEDOUT; } /* Eat the outstanding restart() from the signaller */ suspend (self); ^^^ here and for some reason was_on_queue was 0. All other reader/writer threads have finished successfully at that point, the other threads above are manager thread and main(). On i686, something different happens: There are all but one thread sleeping, one thread is running at 100% of one CPUs time spinning forever in __pthread_unlock (gdb) bt #0 0x4000b5b3 in __pthread_unlock (lock=0x8049bc0) at spinlock.c:179 #1 0x4000cea3 in __pthread_rwlock_timedwrlock (rwlock=0x8049bc0, abstime=0xbe3ffb0c) at rwlock.c:468 #2 0x804890e in writer_thread (nr=0xa) at Examples/ex11.c:64 #3 0x4000782d in pthread_start_thread (arg=0xbe3ffc00) at manager.c:274 (gdb) p/x *lock $89 = {__status = 0xbd5ffc01, __spinlock = 0xca0} (gdb) p ((pthread_descr)0xbd5ffc00)->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock $81 = 0xbd3ffc00 (gdb) p ((pthread_descr)0xbd5ffc00)->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock $82 = 0xbdfffc00 (gdb) p ((pthread_descr)0xbd5ffc00)->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock $83 = 0xbe5ffc00 (gdb) p ((pthread_descr)0xbd5ffc00)->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock->p_nextlock $84 = 0xbdfffc00 because there is for some reason a loop in the p_nextlock chain (0xbdfffc00 -> 0xbe5ffc00 and 0xbe5ffc00 -> 0xbdfffc00). The relevant thread backtraces are: (gdb) thread 10 [Switching to thread 10 (Thread 10251 (LWP 16945))] #0 0x40055e05 in __sigsuspend (set=0xbe5ff9ec) at ../sysdeps/unix/sysv/linux/sigsuspend.c:45 45 return INLINE_SYSCALL (rt_sigsuspend, 2, CHECK_SIGSET (set), _NSIG / 8); (gdb) bt #0 0x40055e05 in __sigsuspend (set=0xbe5ff9ec) at ../sysdeps/unix/sysv/linux/sigsuspend.c:45 #1 0x40009799 in __pthread_wait_for_restart_signal (self=0xbe5ffc00) at pthread.c:898 #2 0x4000b49c in __pthread_lock (lock=0x8049bc0, self=0xbe5ffc00) at spinlock.c:126 #3 0x4000cec0 in __pthread_rwlock_timedwrlock (rwlock=0x8049bc0, abstime=0xbe5ffb0c) at rwlock.c:474 #4 0x804890e in writer_thread (nr=0x9) at Examples/ex11.c:64 #5 0x4000782d in pthread_start_thread (arg=0xbe5ffc00) at manager.c:274 (gdb) thread 13 [Switching to thread 13 (Thread 13326 (LWP 16948))] #0 0x40055e05 in __sigsuspend (set=0xbdfff9ec) at ../sysdeps/unix/sysv/linux/sigsuspend.c:45 45 return INLINE_SYSCALL (rt_sigsuspend, 2, CHECK_SIGSET (set), _NSIG / 8); (gdb) bt #0 0x40055e05 in __sigsuspend (set=0xbdfff9ec) at ../sysdeps/unix/sysv/linux/sigsuspend.c:45 #1 0x40009799 in __pthread_wait_for_restart_signal (self=0xbdfffc00) at pthread.c:898 #2 0x4000b49c in __pthread_lock (lock=0x8049bc0, self=0xbdfffc00) at spinlock.c:126 #3 0x4000cec0 in __pthread_rwlock_timedwrlock (rwlock=0x8049bc0, abstime=0xbdfffb0c) at rwlock.c:474 #4 0x804890e in writer_thread (nr=0xc) at Examples/ex11.c:64 #5 0x4000782d in pthread_start_thread (arg=0xbdfffc00) at manager.c:274 Jakub From aj@suse.de Mon Nov 20 04:29:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Mon, 20 Nov 2000 04:29:00 -0000 Subject: Some warnings fixes Message-ID: Uli, here're some patches to remove a few warnings I noticed. Ok to commit? Andreas 2000-11-20 Andreas Jaeger * nscd/nscd.h (termination_handler): Add noreturn attribute. (receiv_print_stats): Likewise. * elf/ldconfig.c (path_hwcap): Cast -1 for proper comparison. ============================================================ Index: nscd/nscd.h --- nscd/nscd.h 2000/04/30 04:29:52 1.5 +++ nscd/nscd.h 2000/11/20 12:25:31 @@ -102,7 +102,7 @@ /* Prototypes for global functions. */ /* nscd.c */ -extern void termination_handler (int signum); +extern void termination_handler (int signum) __attribute__ ((__noreturn__)); extern int nscd_open_socket (void); /* connections.c */ @@ -115,7 +115,7 @@ /* nscd_stat.c */ extern void send_stats (int fd, struct database dbs[lastdb]); -extern int receive_print_stats (void); +extern int receive_print_stats (void) __attribute__ ((__noreturn__)); /* cache.c */ extern struct hashentry *cache_search (int type, void *key, size_t len, ============================================================ Index: elf/ldconfig.c --- elf/ldconfig.c 2000/11/15 08:43:39 1.13 +++ elf/ldconfig.c 2000/11/20 12:25:32 @@ -191,9 +191,9 @@ h = _dl_string_hwcap (ptr + 1); - if (h == -1) + if (h == (uint64_t)-1) h = _dl_string_platform (ptr + 1); - if (h == -1) + if (h == (uint64_t)-1) break; hwcap += 1ULL << h; -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From jakub@redhat.com Mon Nov 20 06:37:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Mon, 20 Nov 2000 06:37:00 -0000 Subject: [PATCH] Avoid some warnings in make check Message-ID: <20001120154138.X635@sunsite.ms.mff.cuni.cz> Hi! This patch kills quite a few warnings during make check (seen on sparc64). Notes: - What format string modifier should be used for wint_t type arguments? Some archs define it as unsigned long int, some as unsigned int... This causes most of the warnings not fixed by this patch. - We should avoid direct casts between void * and int, because at least sparc64 gcc warns about those casts. Casting to long in between makes it go away. - Is gcc right in emitting: test.c: long long x = -9223372036854775808LL; test.c:1: warning: decimal constant is so large that it is unsigned warning? All of egcs 1.1.2, gcc 2.95, RH gcc 2.96 and CVS gcc 2.97 emit it, but it looks pretty bogus to me, I know what would need to change but I'm not sure if gcc is not for some reason right about it. 2000-11-20 Jakub Jelinek * iconvdata/bug-iconv2.c (main): Use %zd in format string. * io/test-lfs.c (do_test): Cast statbuf.st_size to long long. * malloc/tst-valloc.c (main): Cast valloc return value to long. * malloc/tst-obstack.c (verbose_malloc): Use %zd in format string. * math/test-fpucw.c (main): Use %lx in format string, cast control words to long. * stdio-common/tst-fmemopen.c (main): Use %td in format strings. * stdlib/tst-strtol.c (tests): Avoid (bogus?) decimal constant is so large that it is unsigned warning. * sysdeps/unix/sysv/linux/sparc/bits/types.h (__ssize_t): Changing it to long on sparc64. linuxthreads: * Examples/ex3.c (main): Cast int to long before casting to void *. (search): Cast void * to long, not int. * Examples/ex8.c (main, thread): Similarly. * Examples/ex11.c (main): Similarly. * Examples/ex14.c (worker, do_test): Similarly. * ecmutex.c (worker, do_test): Similarly. (nlocks): Cast to int. --- libc/iconvdata/bug-iconv2.c.jj Tue Aug 29 23:11:06 2000 +++ libc/iconvdata/bug-iconv2.c Mon Nov 20 13:55:57 2000 @@ -38,7 +38,7 @@ main (void) exit (1); puts ("This used to crash"); - printf ("%d\n", iconv (cd_a, &from, &from_left, &to, &to_left)); + printf ("%zd\n", iconv (cd_a, &from, &from_left, &to, &to_left)); iconv_close (cd_a); puts ("works now"); --- libc/io/test-lfs.c.jj Thu Nov 2 08:51:41 2000 +++ libc/io/test-lfs.c Mon Nov 20 15:14:06 2000 @@ -124,7 +124,7 @@ do_test (int argc, char *argv[]) error (EXIT_FAILURE, errno, "cannot stat file `%s'", name); else if (statbuf.st_size != (TWO_GB+100+5)) error (EXIT_FAILURE, 0, "stat reported size %lld instead of %lld.", - statbuf.st_size, (TWO_GB+100+5)); + (long long int) statbuf.st_size, (TWO_GB+100+5)); return 0; } --- libc/linuxthreads/Examples/ex3.c.jj Sun Dec 13 19:01:50 1998 +++ libc/linuxthreads/Examples/ex3.c Mon Nov 20 15:21:38 2000 @@ -35,7 +35,7 @@ int main(int argc, char ** argv) /* Create the searching threads */ for (started=0; started %p\n", size, buf); + printf ("malloc (%zu) => %p\n", size, buf); return buf; } --- libc/math/test-fpucw.c.jj Wed Aug 2 21:36:29 2000 +++ libc/math/test-fpucw.c Mon Nov 20 14:11:22 2000 @@ -32,8 +32,8 @@ main (void) cw &= ~_FPU_RESERVED; if (cw != (_FPU_DEFAULT & ~_FPU_RESERVED)) - printf ("control word is 0x%x but should be 0x%x.\n", - cw, (_FPU_DEFAULT & ~_FPU_RESERVED)); + printf ("control word is 0x%lx but should be 0x%lx.\n", + (long int) cw, (long int) (_FPU_DEFAULT & ~_FPU_RESERVED)); return cw != (_FPU_DEFAULT & ~_FPU_RESERVED); --- libc/stdio-common/tst-fmemopen.c.jj Tue Oct 31 06:17:06 2000 +++ libc/stdio-common/tst-fmemopen.c Mon Nov 20 15:08:09 2000 @@ -34,7 +34,7 @@ main (void) fputc (ch, stdout); if (ch != *cp) { - printf ("\ncharacter %d: '%c' instead of '%c'\n", + printf ("\ncharacter %td: '%c' instead of '%c'\n", cp - blah, ch, *cp); exit (1); } @@ -79,7 +79,7 @@ main (void) fputc (ch, stdout); if (ch != *cp) { - printf ("%d character: '%c' instead of '%c'\n", + printf ("%td character: '%c' instead of '%c'\n", cp - blah, ch, *cp); exit (1); } --- libc/stdlib/tst-limits.c.jj Sat Sep 16 03:28:25 2000 +++ libc/stdlib/tst-limits.c Mon Nov 20 14:52:51 2000 @@ -62,8 +62,8 @@ main (void) TEST (PAGE_SIZE, "d", getpagesize ()); #endif - TEST (WORD_BIT, "d", sizeof (int) * CHAR_BIT); - TEST (LONG_BIT, "d", sizeof (long int) * CHAR_BIT); + TEST (WORD_BIT, "zd", sizeof (int) * CHAR_BIT); + TEST (LONG_BIT, "zd", sizeof (long int) * CHAR_BIT); return result; } --- libc/stdlib/tst-strtol.c.jj Tue Aug 22 10:12:59 2000 +++ libc/stdlib/tst-strtol.c Mon Nov 20 14:49:13 2000 @@ -70,8 +70,8 @@ static const struct ltest tests[] = {"922337203685477580777", 9223372036854775807, 0, 0, ERANGE}, {"9223372036854775810", 9223372036854775807, 0, 0, ERANGE}, {"-2147483648", -2147483648, 0, 0, 0}, - {"-9223372036854775808", -9223372036854775808, 0, 0, 0}, - {"-9223372036854775809", -9223372036854775808, 0, 0, ERANGE}, + {"-9223372036854775808", 0x8000000000000000, 0, 0, 0}, + {"-9223372036854775809", 0x8000000000000000, 0, 0, ERANGE}, {"0x112233445566778899z", 9223372036854775807, 16, 'z', ERANGE}, {"0xFFFFFFFFFFFF00FF" , 9223372036854775807, 0, 0, ERANGE}, #endif --- libc/sysdeps/unix/sysv/linux/sparc/bits/types.h.jj Mon Aug 14 07:08:25 2000 +++ libc/sysdeps/unix/sysv/linux/sparc/bits/types.h Mon Nov 20 14:59:44 2000 @@ -81,7 +81,7 @@ typedef __quad_t __off64_t; /* "" (LF typedef __quad_t __loff_t; /* Type of file sizes and offsets. */ typedef int __pid_t; /* Type of process identifications. */ #if __WORDSIZE == 64 -typedef long long int __ssize_t; /* Type of a byte count, or error. */ +typedef long int __ssize_t; /* Type of a byte count, or error. */ #else typedef int __ssize_t; /* Type of a byte count, or error. */ #endif Jakub From jakub@redhat.com Mon Nov 20 06:58:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Mon, 20 Nov 2000 06:58:00 -0000 Subject: [PATCH] Avoid some warnings in make check References: <20001120154138.X635@sunsite.ms.mff.cuni.cz> Message-ID: <20001120160253.Y635@sunsite.ms.mff.cuni.cz> On Mon, Nov 20, 2000 at 03:41:39PM +0100, Jakub Jelinek wrote: > - Is gcc right in emitting: > test.c: > long long x = -9223372036854775808LL; > test.c:1: warning: decimal constant is so large that it is unsigned > warning? All of egcs 1.1.2, gcc 2.95, RH gcc 2.96 and CVS gcc 2.97 emit it, > but it looks pretty bogus to me, I know what would need to change but I'm > not sure if gcc is not for some reason right about it. Apparently it is right from reading C standard, either the change to 0x8000...0 or -9223372036854775807-1 could do the trick. Sorry. > * stdlib/tst-strtol.c (tests): Avoid (bogus?) decimal constant is so So the (bogus?) is inappropriate there. Jakub From jes@linuxcare.com Mon Nov 20 07:44:00 2000 From: jes@linuxcare.com (Jes Sorensen) Date: Mon, 20 Nov 2000 07:44:00 -0000 Subject: linuxthreads/ex11 issues References: <20001120131659.U635@sunsite.ms.mff.cuni.cz> Message-ID: >>>>> "Jakub" == Jakub Jelinek writes: Jakub> Hi! Examples/ex11.c seems to get stuck on alphaev6, alpha and Jakub> i686 (all of them 4 CPU boxes) from time to time. E.g. if I Jakub> cut'n'paste the ex11 invocation command from make check into Jakub> shell and run it 100 times, it locks up on i686 after some 40 Jakub> invocations, on alpha it gets stuck every ~ 5 invocations or Jakub> so. Jakub> Anybody else can reproduce it? I think I have seen one of them (not sure whether it was ex10 or ex11) get stuck occasionally on my dual CPU ia64. Jes From drepper@redhat.com Mon Nov 20 09:27:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Mon, 20 Nov 2000 09:27:00 -0000 Subject: Some warnings fixes References: Message-ID: Andreas Jaeger writes: > Uli, here're some patches to remove a few warnings I noticed. > > Ok to commit? I've done this now. Thanks, -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Mon Nov 20 09:41:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Mon, 20 Nov 2000 09:41:00 -0000 Subject: [PATCH] Avoid some warnings in make check References: <20001120154138.X635@sunsite.ms.mff.cuni.cz> Message-ID: Jakub Jelinek writes: > This patch kills quite a few warnings during make check (seen on sparc64). Thanks, I've applied it. > - What format string modifier should be used for wint_t type arguments? > Some archs define it as unsigned long int, some as unsigned int... > This causes most of the warnings not fixed by this patch. Since this will always be inconsistent we should use %ld and explicitly cast the parameter to (long int). > - We should avoid direct casts between void * and int, because at least > sparc64 gcc warns about those casts. Casting to long in between makes it > go away. Same is true for all 64 bit targets. It was always intended to do this. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Mon Nov 20 09:54:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Mon, 20 Nov 2000 09:54:00 -0000 Subject: [nls 00248] gencat References: Message-ID: Hi, > We also realized that gencat could not handle multi-byte characters > approprietly if the chacters include \x5c (back slash), which is the case > where the input source files are in Shift-JIS, for example. (as you know > more than us, many Japanese characters in SJIS include \x5c in the sencond > byte.) Yeah, this is a problem. I don't know yet how to solve it. Something like the proposed patch seems to be required but it is really unfortunate since this means it'll not anymore possible to compile all message catalogs without major preparations. Currently programs like rpm simply compile all catalogs in a loop. This will be impossible since a specific locale for each catalog has to be set. One alternative would be to require the catalogs with known problems (like the SJIS encoded catalogs) to contain a comment line specifying the charset. E.g., require the first line to contain $ charset=SJIS If no such line is found the C locale data is used. Otherwise we'll convert the whole input file using iconv() to UCS-4, work on it, and convert back before writing it out. Does this sound acceptable? -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From schwab@suse.de Mon Nov 20 11:31:00 2000 From: schwab@suse.de (Andreas Schwab) Date: Mon, 20 Nov 2000 11:31:00 -0000 Subject: __setjmp Message-ID: <200011201931.eAKJViW03129@hawking.suse.de> Many setjmp implementations define __setjmp as some kind of binary compatibility entry point, but this is never exported. Should this be removed? Andreas. -- Andreas Schwab "And now for something SuSE Labs completely different." Andreas.Schwab@suse.de SuSE GmbH, Schanz????ckerstr. 10, D-90443 N????rnberg From drepper@redhat.com Mon Nov 20 12:01:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Mon, 20 Nov 2000 12:01:00 -0000 Subject: __setjmp References: <200011201931.eAKJViW03129@hawking.suse.de> Message-ID: Andreas Schwab writes: > Many setjmp implementations define __setjmp as some kind of binary > compatibility entry point, but this is never exported. Should this be > removed? Probably. It's not usable and therefore not needed. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From hjl@valinux.com Mon Nov 20 17:00:00 2000 From: hjl@valinux.com (H . J . Lu) Date: Mon, 20 Nov 2000 17:00:00 -0000 Subject: linuxthreads/ex11 issues References: <20001120131659.U635@sunsite.ms.mff.cuni.cz> Message-ID: <20001120170046.A18157@valinux.com> On Mon, Nov 20, 2000 at 01:16:59PM +0100, Jakub Jelinek wrote: > Hi! > > Examples/ex11.c seems to get stuck on alphaev6, alpha and i686 (all of them 4 > CPU boxes) from time to time. I see problems with tests in linuxthreads from time to time. But I can never reproduce them reliably. H.J. From drepper@redhat.com Mon Nov 20 17:38:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Mon, 20 Nov 2000 17:38:00 -0000 Subject: [nls 00250] Re: gencat References: Message-ID: "Yoshito Kawada" writes: > Thank you for consideration. That sounds good, but there is a drawback that > all the existing message catalog files written in SJIS and some others must > be edited. In addition, the portability of message catalog among different > operating systems can be lost. Portability is not lost. Using $ charset=... Is handled by all gencat programs since it is just a comment for all others. > I would prefer to introduce a new compiler option. My idea is: > If the user specify the compiler option to gencat, say, "--multibyte" ( > sorry, I do not have good sense of naming), then gencat takes the wide > character logic, that refers to the current locale. *Default behavior of > gencat is kept as it is.* This would be very difficult to use. It would mean that no package by default will come with Japanese SJIS encoded catalogs since the package author cannot assume that an appropriate locale or iconv module is available. Also, a new option really makes this approach unportable. You would have to have different installation rules for Linux and all other systems. This is not the case if the $ charset comment is required. What would be the argument to --multibyte? A locale name? A charset name? Would you use mbsrtowcs() or iconv()? What do other systems do? They must have the same problem. How would a makefile look like in such a case? You would have to have different rules for each catalog. This is much more error prone than having the necessary information in one place, namely the catalog itself. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Mon Nov 20 22:56:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Mon, 20 Nov 2000 22:56:00 -0000 Subject: [nls 00252] Re: gencat References: Message-ID: "Yoshito Kawada" writes: > ( I am not sure if I understood this portion correctly. "package" means run > time application ? ) Package means the sources or binaries (.tar.gz, rpm, ...) which are installed. The message catalogs come in source form and are compiled for the appropriate target at installation time. This will not be possible for those catalogs which require special locales or conversions since they cannot be assumed to be available. > Of course, on the environment on which gencat runs, the > corresponding locale and iconv modules must be installed, but glibc > has all of them by default, doesn't it?... First, packages are targetting more than Linux. Second, not everything must be available. People are free to remove conversion modules, for instance, they don't need. > No argument is required to this option. Instead, gencat users have to set > LANG environment variable that corresponds to the charset of the message > catalog. In other words, this option allows gencat to switch between the > original gencat logic and Mr. Hanataka's logic which depends on > multibyte-wide character conversion, which in turn requires LANG > environment variable appropriately set. Well, this is a blow against every package maintainers efforts to make her package usable by many. It would require individual rules for the installation of every single catalog. You have to select the appropriate locale. Currently the installation happens most probably in a loop like CATALOGS = ja de for f in $CATALOGS; do gencat $f.cat $f.msg cp $f.cat /usr/lib/locale/$f/LC_MESSAGES done Support for a new language means adding to the CATALOGS variable. If you force people to write special rules for each catalogs all you'll achieve is that languages which require this special behavior are not supported. > As far as our gencat is concerned, they rely on LANG environment value just > the same way I said above. Therefore, makefiles of the applications have to > include the statement to set the LANG prior to gencat. Well, look around at the packages which use catgets. > Yes, that's right. The person who creates makefile must know the encodings > of each message catalog, which could be error-prone. You also must not make the mistake of believing that the package maintainers know anything about these issues. These are the same questions we took into account when creating the gettext framework. Maintainers most of the time have no clue about internationalization and if you want them to at least distribute the work contributors provide you have to make the maintainer's job easy. Very easy, like adding an entry to a variable. > All in all, I completely agree that your method is smarter. However, my > only concern is that there exists tons of message catalogs created in the > past without "$ charset= ..." naturally, and it takes tremendous effort to > insert "$ charset= " to each one of these. No, it doesn't take much of an effort. Simply run sed '1 {i\ $ charset=sjis }' over all the catalogs you want to mark with SJIS. If the name of the charset is encoded in the catalog file or path name it is even possible to automate the whole process for all charsets. > Compared with that effort, editing makefile would be smaller in > workload. This is where you are wrong. You are thinking with the mindset of a corporation programmer where there are people who's job it is to do this and who know what to do. This won't work for free software packages where you sometimes have to beg maintainers to care about internationalization enough to distribute message catalogs. If they are required to do more than keeping track of the files they won't do it (correctly). We've done extensive studies when designing the gettext model to reach this conclusion. I'm more than ever convinced it should be up to the translator to provide the information since s/he is the only one who knows the issues involved for sure. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From schwab@suse.de Tue Nov 21 07:19:00 2000 From: schwab@suse.de (Andreas Schwab) Date: Tue, 21 Nov 2000 07:19:00 -0000 Subject: __setjmp References: <200011201931.eAKJViW03129@hawking.suse.de> Message-ID: <200011211519.eALFJEu07316@hawking.suse.de> Ulrich Drepper writes: |> Andreas Schwab writes: |> |> > Many setjmp implementations define __setjmp as some kind of binary |> > compatibility entry point, but this is never exported. Should this be |> > removed? |> |> Probably. It's not usable and therefore not needed. OK, here is a patch. OK to commit? Andreas. 2000-11-21 Andreas Schwab * sysdeps/alpha/setjmp.S: Remove __setjmp entry point. * sysdeps/arm/setjmp.S: Likewise. * sysdeps/arm/fpu/setjmp.S: Likewise. * sysdeps/i386/setjmp.S: Likewise. * sysdeps/i386/elf/setjmp.S: Likewise. * sysdeps/s390/setjmp.S: Likewise. * sysdeps/s390/elf/setjmp.S: Likewise. * sysdeps/sh/sh3/setjmp.S: Likewise. * sysdeps/sh/sh4/setjmp.S: Likewise. * sysdeps/sparc/sparc32/setjmp.S: Likewise. * sysdeps/unix/sysv/linux/ia64/setjmp.S: Likewise. * sysdeps/unix/sysv/linux/sparc/sparc64/setjmp.S: Likewise. * sysdeps/unix/sysv/linux/m68k/setjmp.c: Removed. From drepper@redhat.com Tue Nov 21 08:21:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Tue, 21 Nov 2000 08:21:00 -0000 Subject: __setjmp References: <200011201931.eAKJViW03129@hawking.suse.de> <200011211519.eALFJEu07316@hawking.suse.de> Message-ID: Andreas Schwab writes: > OK, here is a patch. OK to commit? Yes. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From schwab@suse.de Wed Nov 22 07:42:00 2000 From: schwab@suse.de (Andreas Schwab) Date: Wed, 22 Nov 2000 07:42:00 -0000 Subject: pivot_root Message-ID: <200011221542.eAMFgqF19936@hawking.suse.de> This patch adds the pivot_root syscall. Andreas. 2000-11-22 Andreas Schwab * sysdeps/unix/sysv/linux/syscalls.list: Add pivot_root. * sysdeps/unix/sysv/linux/Versions: Add pivot_root at GLIBC_2.2.1. --- sysdeps/unix/sysv/linux/Versions.~1.12.~ Wed Jul 19 14:29:55 2000 +++ sysdeps/unix/sysv/linux/Versions Wed Nov 22 16:38:48 2000 @@ -90,4 +90,8 @@ # ipc ctl interface change. semctl; shmctl; msgctl; } + GLIBC_2.2.1 { + # p* + pivot_root + } } --- sysdeps/unix/sysv/linux/syscalls.list.~1.81.~ Mon Sep 11 09:43:52 2000 +++ sysdeps/unix/sysv/linux/syscalls.list Wed Nov 22 16:37:30 2000 @@ -35,6 +35,7 @@ pause - pause i: __libc_pause pause personality init-first personality i:i __personality personality pipe - pipe i:f __pipe pipe +pivot_root EXTRA pivot_root i:iss pivot_root prctl EXTRA prctl i:iiiii prctl query_module EXTRA query_module i:sipip query_module quotactl EXTRA quotactl i:isip quotactl -- Andreas Schwab "And now for something SuSE Labs completely different." Andreas.Schwab@suse.de SuSE GmbH, Schanz????ckerstr. 10, D-90443 N????rnberg From schwab@suse.de Wed Nov 22 07:48:00 2000 From: schwab@suse.de (Andreas Schwab) Date: Wed, 22 Nov 2000 07:48:00 -0000 Subject: pivot_root again Message-ID: <200011221548.eAMFmCt20013@hawking.suse.de> This patch adds the pivot_root syscall. The last patch had a typo, sorry. Andreas. 2000-11-22 Andreas Schwab * sysdeps/unix/sysv/linux/syscalls.list: Add pivot_root. * sysdeps/unix/sysv/linux/Versions: Add pivot_root at GLIBC_2.2.1. --- sysdeps/unix/sysv/linux/Versions.~1.12.~ Wed Jul 19 14:29:55 2000 +++ sysdeps/unix/sysv/linux/Versions Wed Nov 22 16:38:48 2000 @@ -90,4 +90,8 @@ # ipc ctl interface change. semctl; shmctl; msgctl; } + GLIBC_2.2.1 { + # p* + pivot_root + } } --- sysdeps/unix/sysv/linux/syscalls.list.~1.81.~ Mon Sep 11 09:43:52 2000 +++ sysdeps/unix/sysv/linux/syscalls.list Wed Nov 22 16:37:30 2000 @@ -35,6 +35,7 @@ pause - pause i: __libc_pause pause personality init-first personality i:i __personality personality pipe - pipe i:f __pipe pipe +pivot_root EXTRA pivot_root i:ss pivot_root prctl EXTRA prctl i:iiiii prctl query_module EXTRA query_module i:sipip query_module quotactl EXTRA quotactl i:isip quotactl -- Andreas Schwab "And now for something SuSE Labs completely different." Andreas.Schwab@suse.de SuSE GmbH, Schanz????ckerstr. 10, D-90443 N????rnberg From drepper@redhat.com Wed Nov 22 23:53:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Wed, 22 Nov 2000 23:53:00 -0000 Subject: pivot_root again References: <200011221548.eAMFmCt20013@hawking.suse.de> Message-ID: Andreas Schwab writes: > This patch adds the pivot_root syscall. The last patch had a typo, sorry. OK, I've added it. Together with the missing change to Versions.def. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From jakub@redhat.com Thu Nov 23 05:29:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Thu, 23 Nov 2000 05:29:00 -0000 Subject: [PATCH] Remove unneeded relocation handling for sparc RTLD_BOOTSTRAP Message-ID: <20001123143130.B14738@sunsite.ms.mff.cuni.cz> Hi! We only need R_SPARC_GLOB_DAT, R_SPARC_JMP_SLOT, R_SPARC_RELATIVE and perhaps R_SPARC_NONE for ld.so, so we can ifdef out the rest of the rela handling... 2000-11-23 Jakub Jelinek * sysdeps/sparc/sparc32/dl-machine.h: Ifdef out handling for relocs which never occur during bootstrap. * sysdeps/sparc/sparc64/dl-machine.h: Likewise. --- libc/sysdeps/sparc/sparc32/dl-machine.h.jj Mon Nov 20 13:48:40 2000 +++ libc/sysdeps/sparc/sparc32/dl-machine.h Thu Nov 23 13:48:14 2000 @@ -377,6 +377,7 @@ elf_machine_rela (struct link_map *map, switch (ELF32_R_TYPE (reloc->r_info)) { +#ifndef RTLD_BOOTSTRAP case R_SPARC_COPY: if (sym == NULL) /* This can happen in trace mode if an object could not be @@ -397,6 +398,7 @@ elf_machine_rela (struct link_map *map, memcpy (reloc_addr, (void *) value, MIN (sym->st_size, refsym->st_size)); break; +#endif case R_SPARC_GLOB_DAT: case R_SPARC_32: *reloc_addr = value; @@ -404,6 +406,7 @@ elf_machine_rela (struct link_map *map, case R_SPARC_JMP_SLOT: elf_machine_fixup_plt(map, 0, reloc, reloc_addr, value); break; +#ifndef RTLD_BOOTSTRAP case R_SPARC_8: *(char *) reloc_addr = value; break; @@ -429,11 +432,14 @@ elf_machine_rela (struct link_map *map, case R_SPARC_HI22: *reloc_addr = (*reloc_addr & 0xffc00000) | (value >> 10); break; +#endif case R_SPARC_NONE: /* Alright, Wilbur. */ break; +#if !defined RTLD_BOOTSTRAP || defined _NDEBUG default: _dl_reloc_bad_type (map, ELFW(R_TYPE) (reloc->r_info), 0); break; +#endif } } } --- libc/sysdeps/sparc/sparc64/dl-machine.h.jj Mon Nov 20 13:48:40 2000 +++ libc/sysdeps/sparc/sparc64/dl-machine.h Thu Nov 23 13:55:35 2000 @@ -212,6 +212,7 @@ elf_machine_rela (struct link_map *map, switch (ELF64_R_TYPE_ID (reloc->r_info)) { +#ifndef RTLD_BOOTSTRAP case R_SPARC_COPY: if (sym == NULL) /* This can happen in trace mode if an object could not be @@ -232,11 +233,12 @@ elf_machine_rela (struct link_map *map, memcpy (reloc_addr, (void *) value, MIN (sym->st_size, refsym->st_size)); break; - +#endif case R_SPARC_64: case R_SPARC_GLOB_DAT: *reloc_addr = value; break; +#ifndef RTLD_BOOTSTRAP case R_SPARC_8: *(char *) reloc_addr = value; break; @@ -311,11 +313,11 @@ elf_machine_rela (struct link_map *map, ((*(unsigned int *)reloc_addr & 0xffc00000) | ((value >> 10) & 0x003fffff)); break; - +#endif case R_SPARC_JMP_SLOT: elf_machine_fixup_plt(map, 0, reloc, reloc_addr, value); break; - +#ifndef RTLD_BOOTSTRAP case R_SPARC_UA64: if (! ((long) reloc_addr & 3)) { @@ -333,10 +335,12 @@ elf_machine_rela (struct link_map *map, ((unsigned char *) reloc_addr) [6] = value >> 8; ((unsigned char *) reloc_addr) [7] = value; break; - +#endif +#if !defined RTLD_BOOTSTRAP || defined _NDEBUG default: _dl_reloc_bad_type (map, ELFW(R_TYPE) (reloc->r_info), 0); break; +#endif } } } Jakub From aj@suse.de Thu Nov 23 08:15:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Thu, 23 Nov 2000 08:15:00 -0000 Subject: Remove _nss_files_getipnodebyname_r Message-ID: We don't have getipnodebyname_r anymore, I've committed the appended patches. Andreas 2000-11-23 Andreas Jaeger * nss/nss_files/files-hosts.c: Remove getipnodebyname. * nss/Versions: Remove _nss_files_getipnodebyname_r. ============================================================ Index: nss/Versions --- nss/Versions 2000/08/17 21:04:10 1.4 +++ nss/Versions 2000/11/23 16:09:15 @@ -83,7 +83,4 @@ _nss_files_getpublickey; _nss_files_getsecretkey; } - GLIBC_2.2 { - _nss_files_getipnodebyname_r; - } } ============================================================ Index: nss/nss_files/files-hosts.c --- nss/nss_files/files-hosts.c 2000/09/03 16:57:49 1.17 +++ nss/nss_files/files-hosts.c 2000/11/23 16:14:08 @@ -279,11 +279,3 @@ && ! memcmp (addr, result->h_addr_list[0], len)) break; }, const void *addr, socklen_t len, int af) - -#undef EXTRA_ARGS_VALUE -#define EXTRA_ARGS_VALUE \ - , af, flags -HOST_DB_LOOKUP (ipnodebyname, ,, - { - LOOKUP_NAME_CASE (h_name, h_aliases) - }, const char *name, int af, int flags) -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From drepper@redhat.com Thu Nov 23 09:26:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Thu, 23 Nov 2000 09:26:00 -0000 Subject: [PATCH] Remove unneeded relocation handling for sparc RTLD_BOOTSTRAP References: <20001123143130.B14738@sunsite.ms.mff.cuni.cz> Message-ID: Jakub Jelinek writes: > We only need R_SPARC_GLOB_DAT, R_SPARC_JMP_SLOT, R_SPARC_RELATIVE and > perhaps R_SPARC_NONE for ld.so, so we can ifdef out the rest of the rela > handling... OK, I've applied it. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From aj@suse.de Mon Nov 27 08:45:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Mon, 27 Nov 2000 08:45:00 -0000 Subject: 2 warnings less... Message-ID: I've committed the appended patch, Andreas 2000-11-27 Andreas Jaeger * login/programs/pt_chown.c (do_pt_chown): Mark function as static to avoid warning. * login/programs/utmpdump.c (print_entry): Likewise. ============================================================ Index: login/programs/pt_chown.c --- login/programs/pt_chown.c 1999/08/25 17:55:43 1.9 +++ login/programs/pt_chown.c 2000/11/27 16:17:36 @@ -94,7 +94,7 @@ return (char *) text; } -int +static int do_pt_chown (void) { char *pty; ============================================================ Index: login/programs/utmpdump.c --- login/programs/utmpdump.c 1997/08/10 17:10:00 1.2 +++ login/programs/utmpdump.c 2000/11/27 16:17:36 @@ -26,7 +26,7 @@ #include #include -void +static void print_entry (struct utmp *up) { #if _HAVE_UT_TV - 0 -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From aj@suse.de Mon Nov 27 23:45:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Mon, 27 Nov 2000 23:45:00 -0000 Subject: More __flexarrs Message-ID: These two files are the only other places in exported include files that use [0]. Shall I commit this? Andreas 2000-11-28 Andreas Jaeger * sysdeps/unix/sysv/linux/bits/socket.h (struct cmsghdr): Use __flexarr. * sysdeps/unix/sysv/linux/mips/bits/socket.h (struct cmsghdr): Likewise. -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From drepper@redhat.com Mon Nov 27 23:58:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Mon, 27 Nov 2000 23:58:00 -0000 Subject: More __flexarrs References: Message-ID: Andreas Jaeger writes: > These two files are the only other places in exported > include files that use [0]. > > Shall I commit this? Yes. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From jakub@redhat.com Thu Nov 30 05:39:00 2000 From: jakub@redhat.com (Jakub Jelinek) Date: Thu, 30 Nov 2000 05:39:00 -0000 Subject: [PATCH] Fix setlocale bug Message-ID: <20001130143256.C681@sunsite.ms.mff.cuni.cz> Hi! Current setlocale implementation only stores copy of user provided string if it is setting LC_ALL, otherwise it would store into _nl_current_names second argument of setlocale directly (unless it was converted into _nl_C_name). But user is allowed to do anything with that pointer after return from setlocale, including freeing it, so we must make a copy. Example of code which is fixed by this patch: #include #include int main() { char q[10]; setlocale(LC_ALL, ""); strcpy(q, "de_DE"); setlocale(LC_NUMERIC, q); strcpy(q, "xx_XX"); printf ("%s\n", setlocale(LC_NUMERIC, NULL)); exit (0); } Without this patch it prints xx_XX while with this patch it correctly prints de_DE. 2000-11-30 Jakub Jelinek * setlocale.c (setname): Free for all categories, not just LC_ALL. (setlocale): Store a copy of string passed by user, not the string itself. --- libc/setlocale.c.jj Mon Nov 20 13:48:11 2000 +++ libc/setlocale.c Thu Nov 30 13:57:06 2000 @@ -194,7 +194,7 @@ setname (int category, const char *name) if (_nl_current_names[category] == name) return; - if (category == LC_ALL && _nl_current_names[category] != _nl_C_name) + if (_nl_current_names[category] != _nl_C_name) free ((char *) _nl_current_names[category]); _nl_current_names[category] = name; @@ -322,6 +322,14 @@ setlocale (int category, const char *loc control over the usage. So we mark it as un-deletable. */ if (newdata[category]->usage_count != UNDELETABLE) newdata[category]->usage_count = UNDELETABLE; + + /* Make a copy of locale name. */ + if (newnames[category] != _nl_C_name) + { + newnames[category] = strdup (newnames[category]); + if (newnames[category] == NULL) + break; + } } /* Create new composite name. */ @@ -342,6 +350,10 @@ setlocale (int category, const char *loc functions know about this. */ ++_nl_msg_cat_cntr; } + else + for (++category; category < __LC_LAST; ++category) + if (category != LC_ALL && newnames[category] != _nl_C_name) + free ((char *) newnames[category]); /* Critical section left. */ __libc_lock_unlock (__libc_setlocale_lock); @@ -376,10 +388,21 @@ setlocale (int category, const char *loc newdata->usage_count = UNDELETABLE; } + /* Make a copy of locale name. */ + if (newname[0] != _nl_C_name) + { + newname[0] = strdup (newname[0]); + if (newname[0] == NULL) + goto abort_single; + } + /* Create new composite name. */ composite = new_composite_name (category, newname); if (composite == NULL) { + if (newname[0] != _nl_C_name) + free ((char *) newname[0]); + /* Say that we don't have any data loaded. */ abort_single: newname[0] = NULL; Jakub From aj@suse.de Thu Nov 30 09:10:00 2000 From: aj@suse.de (Andreas Jaeger) Date: Thu, 30 Nov 2000 09:10:00 -0000 Subject: Another warning less Message-ID: On Alpha I noticed: ../sysdeps/unix/sysv/linux/getdents.c:121: warning: implicit declaration of function `__syscall_getdents64' The appended patch fixes this. Please note that I changed the third parameter to match the kernel in fs/readdir.c Ok to commit? Andreas 2000-11-28 Andreas Jaeger * sysdeps/unix/sysv/linux/getdents.c: Add _syscall_getdents64 declaration, adjust declaration of __syscall_getdents to match kernel. ============================================================ Index: sysdeps/unix/sysv/linux/getdents.c --- sysdeps/unix/sysv/linux/getdents.c 2000/09/13 07:29:13 1.14 +++ sysdeps/unix/sysv/linux/getdents.c 2000/11/28 13:26:28 @@ -48,7 +48,8 @@ #define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER) -extern int __syscall_getdents (int fd, char *__unbounded buf, size_t nbytes); +extern int __syscall_getdents (int fd, char *__unbounded buf, unsigned int nbytes); +extern int __syscall_getdents64 (int fd, char *__unbounded buf, unsigned int nbytes); /* For Linux we need a special version of this file since the definition of `struct dirent' is not the same for the kernel and -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From drepper@redhat.com Thu Nov 30 09:39:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Thu, 30 Nov 2000 09:39:00 -0000 Subject: Another warning less References: Message-ID: Andreas Jaeger writes: > Ok to commit? Yes. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ From drepper@redhat.com Thu Nov 30 16:17:00 2000 From: drepper@redhat.com (Ulrich Drepper) Date: Thu, 30 Nov 2000 16:17:00 -0000 Subject: [PATCH] Fix setlocale bug References: <20001130143256.C681@sunsite.ms.mff.cuni.cz> Message-ID: Jakub Jelinek writes: > Current setlocale implementation only stores copy of user provided > string if it is setting LC_ALL, otherwise it would store into > _nl_current_names second argument of setlocale directly (unless it > was converted into _nl_C_name). Thanks, the patch looks fine. I've applied it and checked the test case in. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------