This is the mail archive of the
libc-hacker@sourceware.cygnus.com
mailing list for the glibc project.
Re: Problems with glibc startup code on the Hurd
- To: Mark Kettenis <kettenis@phys.uva.nl>
- Subject: Re: Problems with glibc startup code on the Hurd
- From: Ulrich Drepper <drepper@cygnus.com>
- Date: 03 Jun 1998 09:43:55 -0700
- Cc: libc-hacker@cygnus.com, tb@mit.edu, gord@m-tech.ab.ca
- References: <199806031231.OAA10141@landau.phys.uva.nl>
- Reply-To: drepper@cygnus.com (Ulrich Drepper)
Mark Kettenis <kettenis@phys.uva.nl> writes:
> The current i386/elf startup code doesn't work for the Hurd. The
> problem is that on the Hurd `__libc_init_first' has to be called from
> the initial stack frame. Since the introduction of the
> `__libc_start_main' function this no longer is the case.
>
> I don't think it is possible to change the Hurd specific
> `__libc_init_first' function since it does some non-trivial stack
> manipulations. So we need to change `sysdeps/i386/elf/start.S'.
I looked briefly at the code and I don't understand why this code
cannot be adapted for the new situation. What's the big difference
between the __libc_init_first called one level higher? The program
never again will go back to the level where __libc_start_main was
called.
Maybe it's also time to think about a cleaner solution to handle the
startup. With the move to calling __libc_init_first in C some of the
complexity might not be necessary anymore.
> An other solution is to introduce a new function, let's say
> `__libc_setup_stack', that is called early from `_start'. On the Hurd
> this function would setup the stack (and most if not all Hurd-specific
> initializations). For Linux(and other ports) it would do nothing.
> `__libc_init_first' would then do the initialization of the library.
I don't like to add such a patch. Please try to find another solution
which does not require changing non-Hurd code.
-- Uli
---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com `------------------------