Re: [bug #17647] glibc: GCC 4.1
Hello!
On Sun, Nov 26, 2006 at 11:27:58PM +0100, I wrote:
The patch for glibc follows:
Here is an updated version, ready for inclusion as far as I'm concerned.
2007-07-22 Thomas Schwinge [EMAIL PROTECTED]
* sysdeps/mach/hurd/i386/init-first.c: Undo parts of Roland's `r 1.43'
to `r 1.44' changes.
(_hurd_stack_setup): Take a ``void *'' argument. Save the caller into
CALLER and pass that one on.
(init): Avoid an ugly typecast.
Revert Roland patch. (Part of `r 1.44' to 'r 1.43').
#v+
Index: sysdeps/mach/hurd/i386/init-first.c
===
RCS file: /cvs/glibc/libc/sysdeps/mach/hurd/i386/init-first.c,v
retrieving revision 1.43.4.1
diff -u -p -r1.43.4.1 init-first.c
--- sysdeps/mach/hurd/i386/init-first.c 23 Oct 2005 01:00:09 - 1.43.4.1
+++ sysdeps/mach/hurd/i386/init-first.c 20 Nov 2006 11:05:47 -
@@ -320,11 +320,11 @@ first_init (void)
stack set up just as the user will see it, so it can switch stacks. */
void
-_dl_init_first (void)
+_dl_init_first (int argc, ...)
{
first_init ();
- init ((int *) __builtin_frame_address (0) + 2);
+ init (argc);
}
#endif
@@ -351,23 +351,21 @@ strong_alias (posixland_init, __libc_ini
This poorly-named function is called by static-start.S,
which should not exist at all. */
void
-_hurd_stack_setup (void)
+_hurd_stack_setup (volatile int argc, ...)
{
- intptr_t caller = (intptr_t) __builtin_return_address (0);
-
void doinit (intptr_t *data)
{
/* This function gets called with the argument data at TOS. */
- void doinit1 (void)
+ void doinit1 (volatile int argc, ...)
{
- init ((int *) __builtin_frame_address (0) + 2);
+ init ((int *) argc);
}
/* Push the user return address after the argument data, and then
jump to `doinit1' (above), so it is as if __libc_init_first's
caller had called `doinit1' with the argument data already on the
stack. */
- *--data = caller;
+ *--data = (argc)[-1];
asm volatile (movl %0, %%esp\n /* Switch to new outermost stack. */
movl $0, %%ebp\n /* Clear outermost frame pointer. */
jmp *%1 : : r (data), r (doinit1) : sp);
@@ -376,7 +374,7 @@ _hurd_stack_setup (void)
first_init ();
- _hurd_startup ((void **) __builtin_frame_address (0) + 2, doinit);
+ _hurd_startup ((void **) argc, doinit);
}
#endif
#v-
Make the code work with GCC 4.1. This is essentially what Roland had done --
moving the resolution of the return address out of the nested subfunction --
but this time without replacing it with `__builtin_return_address'.
#v+
--- sysdeps/mach/hurd/i386/init-first.c 2007-07-22 16:50:03.0 +0200
+++ sysdeps/mach/hurd/i386/init-first.c 2007-07-22 18:33:45.54000 +0200
@@ -350,8 +351,10 @@
This poorly-named function is called by static-start.S,
which should not exist at all. */
void
-_hurd_stack_setup (volatile int argc, ...)
+_hurd_stack_setup (void *arg, ...)
{
+ void *caller = (arg)[-1];
+
void doinit (intptr_t *data)
{
/* This function gets called with the argument data at TOS. */
@@ -364,7 +367,7 @@
jump to `doinit1' (above), so it is as if __libc_init_first's
caller had called `doinit1' with the argument data already on the
stack. */
- *--data = (argc)[-1];
+ *--data = (intptr_t) caller;
asm volatile (movl %0, %%esp\n /* Switch to new outermost stack. */
movl $0, %%ebp\n /* Clear outermost frame pointer. */
jmp *%1 : : r (data), r (doinit1) : sp);
@@ -373,7 +376,7 @@
first_init ();
- _hurd_startup ((void **) argc, doinit);
+ _hurd_startup (arg, doinit);
}
#endif
#v-
Cosmetical and documentation fixes.
#v+
Index: sysdeps/mach/hurd/i386/init-first.c
===
RCS file: /cvs/glibc/libc/sysdeps/mach/hurd/i386/init-first.c,v
retrieving revision 1.43.4.1
diff -u -p -r1.43.4.1 init-first.c
--- sysdeps/mach/hurd/i386/init-first.c 23 Oct 2005 01:00:09 - 1.43.4.1
+++ sysdeps/mach/hurd/i386/init-first.c 20 Nov 2006 11:05:47 -
@@ -1,6 +1,7 @@
/* Initialization code run first thing by the ELF startup code. For i386/Hurd.
- Copyright (C) 1995,96,97,98,99,2000,01,02,03,04,05
- Free Software Foundation, Inc.
+ Copyright (C) 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004,
+ 2005, 2007 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
@@ -243,8 +243,8 @@ init (int *data)
be the return address for `init1'; we will jump there with NEWSP
as the stack pointer. */
*--newsp = data[-1];
- ((void **) data)[-1] = switch_stacks;
- /* Force NEWSP into %ecx and init1 into %eax, which are not
Re: [bug #17647] glibc: GCC 4.1
Hello! On Sun, Nov 26, 2006 at 11:27:58PM +0100, I wrote: [Building glibc with GCC 4.1.] And in fact also glibc-proper code is affected: #v+ [EMAIL PROTECTED]:/var/tmp/glibc-GCC4.1-without_Roland_patches/glibc-2.3.6.ds1/build-tree/hurd-i386-libc $ LD_LIBRARY_PATH=. gdb --args locale/localedef --help GNU gdb 6.5-debian [...] This GDB was configured as i486-gnu... (gdb) r Starting program: /var/tmp/glibc-GCC4.1-without_Roland_patches/glibc-2.3.6.ds1/build-tree/hurd-i386-libc/locale/localedef --help Usage: localedef [OPTION...] NAME or: localedef [OPTION...] [--add-to-archive|--delete-from-archive] FILE... or: localedef [OPTION...] --list-archive [FILE] Compile locale specification Input Files: -f, --charmap=FILE Symbolic character names defined in FILE -i, --inputfile=FILE Source definitions are found in FILE Program received signal SIGSEGV, Segmentation fault. 0x011389a8 in __argp_fmtstream_update (fs=0x8098158) at argp-fmtstream.c:232 232 while (p = buf !isblank (*p)) (gdb) print p $1 = 0x80981e9 values\n\n Input Files:\n -f, e] FILE...\n, '\223' repeats 88 times, ??? (gdb) print *p $2 = 118 'v' (gdb) bt #0 0x011389a8 in __argp_fmtstream_update (fs=0x8098158) at argp-fmtstream.c:232 #1 0x0113cc74 in _help (argp=0x1019ab0, state=0x1019ba4, stream=0x1188be0, flags=value optimized out, name=0x101a05e localedef) at argp-fmtstream.h:255 #2 0x0113d31e in __argp_state_help (state=0x1019ba4, stream=0x80981e9, flags=634) at argp-help.c:1730 #3 0x0113d7a8 in argp_default_parser (key=63, arg=0x0, state=0x1019ba4) at argp-parse.c:119 #4 0x0113d595 in group_parse (group=0x8097efc, state=0x1019ba4, key=63, arg=0x0) at argp-parse.c:257 #5 0x0113df93 in __argp_parse (argp=0x1019ab0, argc=2, argv=0x1019db4, flags=0, end_index=0x1019d58, input=0x0) at argp-parse.c:755 #6 0x0804a854 in main (argc=2, argv=0x1019db4) at programs/localedef.c:206 #v- Any offhand guesses what's going on there? I would expect nothing in the argp code to be Hurd specific and I'm not aware of any Linux system having such a problem. I can add another bit of information here: pay attention to `LC_ALL'. #v+ [EMAIL PROTECTED]:/var/tmp/glibc-GCC4.1-without_Roland_patches/glibc-2.3.6.ds1/build-tree/hurd-i386-libc $ LC_ALL=unknown LD_LIBRARY_PATH=. locale/localedef --help Usage: localedef [OPTION...] NAME or: localedef [OPTION...] [--add-to-archive|--delete-from-archive] FILE... or: localedef [OPTION...] --list-archive [FILE] Compile locale specification Input Files: -f, --charmap=FILE Symbolic character names defined in FILE -i, --inputfile=FILE Source definitions are found in FILE -u, --repertoire-map=FILE FILE contains mapping from symbolic names to UCS4 [...] [EMAIL PROTECTED]:/var/tmp/glibc-GCC4.1-without_Roland_patches/glibc-2.3.6.ds1/build-tree/hurd-i386-libc $ LC_ALL=de_DE.UTF-8 LD_LIBRARY_PATH=. lo cale/localedef --help Aufruf: localedef [Option...] NAME oder: localedef [Option...] [--add-to-archive|--delete-from-archive] Datei... oder: localedef [Option...] --list-archive [Datei] Umwandeln der Lokale-Spezifikation Eingabedateien: -f, --charmap=FILE Symbolische Namen f??r Zeichen sind DATEI definiert -i, --inputfile=FILE Die Quell-Definitionen stehen in DATEI -u, --repertoire-map=FILE DATEI enth??lt Zuordnungen von symbolischen Namen [...] [EMAIL PROTECTED]:/var/tmp/glibc-GCC4.1-without_Roland_patches/glibc-2.3.6.ds1/build-tree/hurd-i386-libc $ LC_ALL=C LD_LIBRARY_PATH=. locale/localedef --help Usage: localedef [OPTION...] NAME or: localedef [OPTION...] [--add-to-archive|--delete-from-archive] FILE... or: localedef [OPTION...] --list-archive [FILE] Compile locale specification Input Files: -f, --charmap=FILE Symbolic character names defined in FILE -i, --inputfile=FILE Source definitions are found in FILE Segmentation fault #v- I.e. invalid values for `LC_ALL' work, as well as localized ones, only the `C' one makes it segfault. Due to the situation with glibc HEAD being unbuildable at the moment, I can't test that. Any ideas? Regards, Thomas signature.asc Description: Digital signature ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: [bug #17647] glibc: GCC 4.1
Hello!
On Mon, Nov 20, 2006 at 03:40:03PM +0100, Samuel Thibault wrote:
Thomas Schwinge, le Sun 19 Nov 2006 22:59:29 +, a ?crit :
| #v+
| [...]
| void
| -_dl_init_first (int argc, ...)
| +_dl_init_first (void)
| {
| first_init ();
|
| - init (argc);
| + init ((int *) __builtin_frame_address (0) + 2);
| }
| [...]
| #v-
The old version looks much more safe to me.
And in fact, applying the following patch which reverts those changes
from above and then adds another one, makes the GCC 4.1 built glibc
mostly work (see below for what doesn't work) and rebuilding the current
Debian hurd package against that glibc it also works -- especially
ext2fs.static was interesting to test. But it also works only with the
limitation of what is described below.
The patch for glibc follows:
Revert Roland patch. (Part of `-r 1.44' to '-r 1.43').
Index: sysdeps/mach/hurd/i386/init-first.c
===
RCS file: /cvs/glibc/libc/sysdeps/mach/hurd/i386/init-first.c,v
retrieving revision 1.43.4.1
diff -u -p -r1.43.4.1 init-first.c
--- sysdeps/mach/hurd/i386/init-first.c 23 Oct 2005 01:00:09 - 1.43.4.1
+++ sysdeps/mach/hurd/i386/init-first.c 20 Nov 2006 11:05:47 -
@@ -320,11 +320,11 @@ first_init (void)
stack set up just as the user will see it, so it can switch stacks. */
void
-_dl_init_first (void)
+_dl_init_first (int argc, ...)
{
first_init ();
- init ((int *) __builtin_frame_address (0) + 2);
+ init (argc);
}
#endif
@@ -351,23 +351,21 @@ strong_alias (posixland_init, __libc_ini
This poorly-named function is called by static-start.S,
which should not exist at all. */
void
-_hurd_stack_setup (void)
+_hurd_stack_setup (volatile int argc, ...)
{
- intptr_t caller = (intptr_t) __builtin_return_address (0);
-
void doinit (intptr_t *data)
{
/* This function gets called with the argument data at TOS. */
- void doinit1 (void)
+ void doinit1 (volatile int argc, ...)
{
- init ((int *) __builtin_frame_address (0) + 2);
+ init ((int *) argc);
}
/* Push the user return address after the argument data, and then
jump to `doinit1' (above), so it is as if __libc_init_first's
caller had called `doinit1' with the argument data already on the
stack. */
- *--data = caller;
+ *--data = (argc)[-1];
asm volatile (movl %0, %%esp\n /* Switch to new outermost stack. */
movl $0, %%ebp\n /* Clear outermost frame pointer. */
jmp *%1 : : r (data), r (doinit1) : sp);
@@ -376,7 +374,7 @@ _hurd_stack_setup (void)
first_init ();
- _hurd_startup ((void **) __builtin_frame_address (0) + 2, doinit);
+ _hurd_startup ((void **) argc, doinit);
}
#endif
Make the code work with GCC 4.1. This is essentially what Roland had
done -- moving the resolution of the return address out of the nested
subfunction -- but this time without replacing it with
`__builtin_return_address'.
Index: sysdeps/mach/hurd/i386/init-first.c
===
RCS file: /cvs/glibc/libc/sysdeps/mach/hurd/i386/init-first.c,v
retrieving revision 1.43.4.1
diff -u -p -r1.43.4.1 init-first.c
--- sysdeps/mach/hurd/i386/init-first.c 23 Oct 2005 01:00:09 - 1.43.4.1
+++ sysdeps/mach/hurd/i386/init-first.c 20 Nov 2006 11:05:47 -
@@ -353,6 +355,8 @@
void
_hurd_stack_setup (volatile int argc, ...)
{
+ intptr_t caller = (argc)[-1];
+
void doinit (intptr_t *data)
{
/* This function gets called with the argument data at TOS. */
@@ -365,7 +369,7 @@
jump to `doinit1' (above), so it is as if __libc_init_first's
caller had called `doinit1' with the argument data already on the
stack. */
- *--data = (argc)[-1];
+ *--data = caller;
asm volatile (movl %0, %%esp\n /* Switch to new outermost stack. */
movl $0, %%ebp\n /* Clear outermost frame pointer. */
jmp *%1 : : r (data), r (doinit1) : sp);
Cosmetical and documentation fixes.
Index: sysdeps/mach/hurd/i386/init-first.c
===
RCS file: /cvs/glibc/libc/sysdeps/mach/hurd/i386/init-first.c,v
retrieving revision 1.43.4.1
diff -u -p -r1.43.4.1 init-first.c
--- sysdeps/mach/hurd/i386/init-first.c 23 Oct 2005 01:00:09 - 1.43.4.1
+++ sysdeps/mach/hurd/i386/init-first.c 20 Nov 2006 11:05:47 -
@@ -1,6 +1,8 @@
/* Initialization code run first thing by the ELF startup code. For i386/Hurd.
- Copyright (C) 1995,96,97,98,99,2000,01,02,03,04,05
- Free Software Foundation, Inc.
+
+ Copyright (C) 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004,
+ 2005, 2006 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
@@
Re: [bug #17647] glibc: GCC 4.1
Thomas Schwinge, le Sun 19 Nov 2006 22:59:29 +, a écrit :
| #v+
| [...]
| void
| -_dl_init_first (int argc, ...)
| +_dl_init_first (void)
| {
| first_init ();
|
| - init (argc);
| + init ((int *) __builtin_frame_address (0) + 2);
| }
| [...]
| #v-
So, how can this be explained?
The old version looks much more safe to me.
Samuel
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: [bug #17647] glibc: GCC 4.1
Thomas Schwinge, le Sun 19 Nov 2006 22:33:46 +, a écrit : printf (%s:fa[0] = %u\tfa[1] = %u\tra = %u\n, __func__, fa[0], fa[1], $ gcc-4.0 test.c ./a.out main:fa = 3216472808fa[1] = 3084724428 ra = 3084724428 func:fa[0] = 3216472808 fa[1] = 134513645 ra = 134513645 #v- This is what I would expect. Mmm, only by chance: don't expect fa[0], fa[1], ... to give you useful information, only the _value_ of the pointer returned by __builtin_frame_address() really makes sense. But #v+ main:fa = 3220364948fa[1] = 3220365064 ra = 3085416652 func:fa[0] = 3220364952 fa[1] = 134513639 ra = 134513639 #v- Yes, looking at asm shows 80483bf: 8d 45 fclea0xfffc(%ebp),%eax for the call to __builtin_frame_address(0) in main(), which seems odd to me. Samuel ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
