Re: Problems with glibc startup code on the Hurd

[Ulrich Drepper <drepper@cygnus.com>]

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   `------------------------