This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Problems with glibc startup code on the Hurd


   From: Ulrich Drepper <drepper@cygnus.com>
   Date: 03 Jun 1998 09:43:55 -0700

   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.

To my understanding (which I must admit is not that big), the Hurd
startup code replaces the stack with one that it creates itself, and
then frees the original stack.  This means that after calling
__libc_init_start the arguments to __libc_start_main are no longer
accessable right?.

Another problem is that the current __libc_init_start relies on being
called from the first stack frame to access some variables on the
stack that _start does not know of (because they may or may not be
there, depending on the way the programs was started).

Note that the problems I'm talking about are probably relevant to
statically linked programs only.  As far as I can see the startup code
of the dynamic linker is still OK (the dynamic linker itself however
is broken on the Hurd).

   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.

But rewriting the entire startup code for the Hurd would probably mean
breaking old binaries, which may be a big problem.

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

I would prefer not changing the generic code too.  I hope Roland can
come up with a clean solution.

Mark


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]