more ELF changes

more ELF changes

[Ulrich Drepper]

Hi,

I've checked in another bunch of ELF changes.  With these changes we
should now follow the upcoming ELF specification.  Again, the new
functionality is not yet tested as te linker cannot emit it yet.  But
it doesn't break existing programs.

I had to change the RTLD_START code.  This means that port maintainer
for architectures != ix86 have something to do.  The change are
trivial and I probably could very well do it myself but I'll leave it
to you.  The changes are that before calling the initializers one by
one there must be a similar loop before this which calls the
pre-initializers.  The function pointers can be found by calling
_dl_preinit_next.  Very simple.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: more ELF changes

[Roland McGrath]

Why don't you just change _dl_init_next to return the preinits and then the
inits?

Re: more ELF changes

[Ulrich Drepper]

Roland McGrath <roland@frob.com> writes:

> Why don't you just change _dl_init_next to return the preinits and then the
> inits?

Bookkeeping seems to bemore complicated.  It's already quite
complicated as it is with the different kind of initializers and the
way the _dl_init_next functions are working (at, the whole function is
called quite often) they should be kept simple and not have many ifs
distinguishing runs of the preinit and the init.

But I want to overhaul the init handling anyhow.  There is no reason
to do that much in assembly.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: more ELF changes

[Geoff Keating]

> From: Ulrich Drepper <drepper@cygnus.com>
> Date: 24 Jul 1999 17:28:29 -0700

> But I want to overhaul the init handling anyhow.  There is no reason
> to do that much in assembly.

My suggestion would be to do it in _dl_start.  Pass all init functions
argc, argv, and envp.  This is what dlopen does anyway, so there is no
point trying to do anything tricky in the startup code, because it
won't work properly when the library is dlopen()ed (and we don't in
fact do anything tricky now, anyway).  Then you can eliminate
init_first.h, which requires assembler on most targets for no
particular reason; ld.so has already worked out where argv etc. are
before init-first.h is run.

-- 
Geoffrey Keating <geoffk@cygnus.com>

Re: more ELF changes

[Roland McGrath]

> My suggestion would be to do it in _dl_start.  Pass all init functions
> argc, argv, and envp.  This is what dlopen does anyway, so there is no
> point trying to do anything tricky in the startup code, because it
> won't work properly when the library is dlopen()ed (and we don't in
> fact do anything tricky now, anyway).  

We do do something tricky in libc on the Hurd.  
See sysdeps/mach/hurd/i386/init-first.c; it switches stacks.

It's not reasonable for DT_INIT functions in general to do tricky things,
because they might be run via dlopen.  But libc itself reasonably expects
always to be the first library initialized, and so it can do tricky things.