patch to make init_array work (2nd version; resend)

patch to make init_array work (2nd version; resend)

[David Mosberger]

[I'm resending this patch since there has been no response to the original
 mail on October 28th.  I'd appreciate it if someone could let me know if
 something is wrong with the patch.  If not, please apply.  The patch will
 be helpful for any platform that needs/wants correct unwind info for
 constructors/destructors.  Thanks.]

My previous patch (adopted from HJ's work) was missing a change to
dl-fini.c which broke the handling of .fini_array.  The patch below is
updated to fix that and "make check" now passes as expected (I must
have made a mistake previously as I thought it worked with the
previous patch already).

If it looks OK, please apply.  (Yes, I know both Uli and Roland are
out this week, but I'll likely be out next week...).

Thanks,

	--david

2002-10-28  David Mosberger  <davidm@hpl.hp.com>

	* elf/dl-fini.c (_dl_fini): Invoke fini_array in _reverse_ order.
	Don't add l->l_addr to array entry values.

2002-03-12  H.J. Lu  <hjl@gnu.org>

	* csu/init.c (__libc_preinit_array): New. Define if
	HAVE_INITFINI_ARRAY is defined.
	(__libc_init_array): Likewise.
	(__libc_fini_array): Likewise.

	* elf/Makefile (tests): Add tst-array1, tst-array2 and
	tst-array3 if $(have-initfini-array) is yes.
	(tests-static): Add tst-array3 if $(have-initfini-array) is
	yes.
	(modules-names): Add tst-array2dep if $(have-initfini-array)
	is yes.
	($(objpfx)tst-array1.out): New target.
	($(objpfx)tst-array2): Likewise.
	($(objpfx)tst-array2.out): Likewise.
	($(objpfx)tst-array3.out): Likewise.

	* elf/tst-array1.c: New file.
	* elf/tst-array1.exp: Likewise.
	* elf/tst-array2.c: Likewise.
	* elf/tst-array2dep.c: Likewise.
	* elf/tst-array2.exp: Likewise.
	* elf/tst-array3.c: Likewise.

	* sysdeps/generic/libc-start.c (__libc_start_main): Process
	__libc_preinit_array, __libc_init_array and __libc_fini_array
	if HAVE_INITFINI_ARRAY is defined.

Index: csu/init.c
===================================================================
RCS file: /cvs/glibc/libc/csu/init.c,v
retrieving revision 1.4
diff -u -r1.4 init.c
--- csu/csu/init.c	6 Jul 2001 04:54:45 -0000	1.4
+++ csu/csu/init.c	29 Oct 2002 05:35:15 -0000
@@ -25,3 +25,43 @@
 const int _IO_stdin_used = _G_IO_IO_FILE_VERSION;
 
 #endif
+
+#ifdef HAVE_INITFINI_ARRAY
+extern void (*__preinit_array_start []) (void);
+extern void (*__preinit_array_end []) (void);
+
+void
+__libc_preinit_array (void)
+{
+  unsigned int size, i;
+
+  size = __preinit_array_end - __preinit_array_start;
+  for (i = 0; i < size; i++)
+    __preinit_array_start [i] ();
+}
+
+extern void (*__init_array_start []) (void);
+extern void (*__init_array_end []) (void);
+
+void
+__libc_init_array (void)
+{
+  unsigned int size, i;
+
+  size =  __init_array_end - __init_array_start;
+  for (i = 0; i < size; i++)
+    __init_array_start [i] ();
+}
+
+extern void (*__fini_array_start []) (void);
+extern void (*__fini_array_end []) (void);
+
+void
+__libc_fini_array (void)
+{
+  int i;
+
+  for (i = __fini_array_end - __fini_array_start - 1; i >= 0; i--)
+    __fini_array_start [i] ();
+}
+#endif
Index: elf/Makefile
===================================================================
RCS file: /cvs/glibc/libc/elf/Makefile,v
retrieving revision 1.242
diff -u -r1.242 Makefile
--- elf/elf/Makefile	24 Oct 2002 00:20:38 -0000	1.242
+++ elf/elf/Makefile	29 Oct 2002 05:35:15 -0000
@@ -117,6 +117,9 @@
 endif
 
 tests = tst-tls1 tst-tls2 tst-tls9
+ifeq (yes,$(have-initfini-array))
+tests += tst-array1 tst-array2 tst-array3
+endif
 ifeq (yes,$(build-static))
 tests-static = tst-tls1-static tst-tls2-static
 ifeq (yesyesyes,$(build-static)$(build-shared)$(elf))
@@ -156,6 +159,9 @@
 		tst-tlsmod5 tst-tlsmod6 \
 		circlemod1 circlemod1a circlemod2 circlemod2a \
 		circlemod3 circlemod3a
+ifeq (yes,$(have-initfini-array))
+modules-names += tst-array2dep
+endif
 modules-vis-yes = vismod1 vismod2 vismod3
 modules-nodelete-yes = nodelmod1 nodelmod2 nodelmod3 nodelmod4
 modules-nodlopen-yes = nodlopenmod nodlopenmod2
@@ -543,3 +549,22 @@
 $(objpfx)tst-tls9-static: $(common-objpfx)dlfcn/libdl.a
 $(objpfx)tst-tls9-static.out: $(objpfx)tst-tlsmod5.so $(objpfx)tst-tlsmod6.so
 endif
+
+$(objpfx)tst-array1.out: $(objpfx)tst-array1
+	$(elf-objpfx)$(rtld-installed-name) \
+	  --library-path $(rpath-link)$(patsubst %,:%,$(sysdep-library-path)) \
+	  $(objpfx)tst-array1 > $@
+	cmp $@ tst-array1.exp > /dev/null
+
+$(objpfx)tst-array2: $(objpfx)tst-array2dep.so
+$(objpfx)tst-array2.out: $(objpfx)tst-array2
+	$(elf-objpfx)$(rtld-installed-name) \
+	  --library-path $(rpath-link)$(patsubst %,:%,$(sysdep-library-path)) \
+	  $(objpfx)tst-array2 > $@
+	cmp $@ tst-array2.exp > /dev/null
+
+$(objpfx)tst-array3.out: $(objpfx)tst-array3
+	$(elf-objpfx)$(rtld-installed-name) \
+	  --library-path $(rpath-link)$(patsubst %,:%,$(sysdep-library-path)) \
+	  $(objpfx)tst-array3 > $@
+	cmp $@ tst-array1.exp > /dev/null
Index: elf/dl-fini.c
===================================================================
RCS file: /cvs/glibc/libc/elf/dl-fini.c,v
retrieving revision 1.27
diff -u -r1.27 dl-fini.c
--- elf/elf/dl-fini.c	1 Mar 2002 09:11:58 -0000	1.27
+++ elf/elf/dl-fini.c	29 Oct 2002 05:35:15 -0000
@@ -157,12 +157,11 @@
 	      ElfW(Addr) *array =
 		(ElfW(Addr) *) (l->l_addr
 				+ l->l_info[DT_FINI_ARRAY]->d_un.d_ptr);
-	      unsigned int sz = (l->l_info[DT_FINI_ARRAYSZ]->d_un.d_val
-				 / sizeof (ElfW(Addr)));
-	      unsigned int cnt;
+	      int i = (l->l_info[DT_FINI_ARRAYSZ]->d_un.d_val
+		       / sizeof (ElfW(Addr))) - 1;
 
-	      for (cnt = 0; cnt < sz; ++cnt)
-		((fini_t) (l->l_addr + array[cnt])) ();
+	      for (; i >= 0; --i)
+		((fini_t) array[i]) ();
 	    }
 
 	  /* Next try the old-style destructor.  */
Index: elf/tst-array1.c
===================================================================
RCS file: elf/tst-array1.c
diff -N elf/tst-array1.c
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ elf/elf/tst-array1.c	29 Oct 2002 05:35:15 -0000
@@ -0,0 +1,101 @@
+#include <unistd.h>
+
+static void init (void) __attribute__ ((constructor));
+
+static void
+init (void)
+{
+  write (STDOUT_FILENO, "init\n", 5);
+}
+
+static void fini (void) __attribute__ ((destructor));
+
+static void
+fini (void)
+{
+  write (STDOUT_FILENO, "fini\n", 5);
+}
+
+static void
+preinit_0 (void)
+{
+  write (STDOUT_FILENO, "preinit array 0\n", 16);
+}
+
+static void
+preinit_1 (void)
+{
+  write (STDOUT_FILENO, "preinit array 1\n", 16);
+}
+
+static void
+preinit_2 (void)
+{
+  write (STDOUT_FILENO, "preinit array 2\n", 16);
+}
+
+void
+(*preinit_array []) (void) __attribute__ ((section (".preinit_array"))) =
+{
+  &preinit_0,
+  &preinit_1,
+  &preinit_2
+};
+
+static void
+init_0 (void)
+{
+  write (STDOUT_FILENO, "init array 0\n", 13);
+}
+
+static void
+init_1 (void)
+{
+  write (STDOUT_FILENO, "init array 1\n", 13);
+}
+
+static void
+init_2 (void)
+{
+  write (STDOUT_FILENO, "init array 2\n", 13);
+}
+
+void
+(*init_array []) (void) __attribute__ ((section (".init_array"))) =
+{
+  &init_0,
+  &init_1,
+  &init_2
+};
+
+static void
+fini_0 (void)
+{
+  write (STDOUT_FILENO, "fini array 0\n", 13);
+}
+
+static void
+fini_1 (void)
+{
+  write (STDOUT_FILENO, "fini array 1\n", 13);
+}
+
+static void
+fini_2 (void)
+{
+  write (STDOUT_FILENO, "fini array 2\n", 13);
+}
+
+void
+(*fini_array []) (void) __attribute__ ((section (".fini_array"))) =
+{
+  &fini_0,
+  &fini_1,
+  &fini_2
+};
+
+int
+main (void)
+{
+  return 0;
+}
Index: elf/tst-array1.exp
===================================================================
RCS file: elf/tst-array1.exp
diff -N elf/tst-array1.exp
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ elf/elf/tst-array1.exp	29 Oct 2002 05:35:15 -0000
@@ -0,0 +1,11 @@
+preinit array 0
+preinit array 1
+preinit array 2
+init
+init array 0
+init array 1
+init array 2
+fini array 2
+fini array 1
+fini array 0
+fini
Index: elf/tst-array2.c
===================================================================
RCS file: elf/tst-array2.c
diff -N elf/tst-array2.c
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ elf/elf/tst-array2.c	29 Oct 2002 05:35:15 -0000
@@ -0,0 +1 @@
+#include "tst-array1.c"
Index: elf/tst-array2.exp
===================================================================
RCS file: elf/tst-array2.exp
diff -N elf/tst-array2.exp
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ elf/elf/tst-array2.exp	29 Oct 2002 05:35:15 -0000
@@ -0,0 +1,19 @@
+preinit array 0
+preinit array 1
+preinit array 2
+DSO init
+DSO init array 0
+DSO init array 1
+DSO init array 2
+init
+init array 0
+init array 1
+init array 2
+fini array 2
+fini array 1
+fini array 0
+fini
+DSO fini array 2
+DSO fini array 1
+DSO fini array 0
+DSO fini
Index: elf/tst-array2dep.c
===================================================================
RCS file: elf/tst-array2dep.c
diff -N elf/tst-array2dep.c
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ elf/elf/tst-array2dep.c	29 Oct 2002 05:35:15 -0000
@@ -0,0 +1,69 @@
+#include <unistd.h>
+
+static void init (void) __attribute__ ((constructor));
+
+static void
+init (void)
+{
+  write (STDOUT_FILENO, "DSO init\n", 9);
+}
+
+static void fini (void) __attribute__ ((destructor));
+
+static void
+fini (void)
+{
+  write (STDOUT_FILENO, "DSO fini\n", 9);
+}
+
+static void
+init_0 (void)
+{
+  write (STDOUT_FILENO, "DSO init array 0\n", 17);
+}
+
+static void
+init_1 (void)
+{
+  write (STDOUT_FILENO, "DSO init array 1\n", 17);
+}
+
+static void
+init_2 (void)
+{
+  write (STDOUT_FILENO, "DSO init array 2\n", 17);
+}
+
+void
+(*init_array []) (void) __attribute__ ((section (".init_array"))) =
+{
+  &init_0,
+  &init_1,
+  &init_2
+};
+
+static void
+fini_0 (void)
+{
+  write (STDOUT_FILENO, "DSO fini array 0\n", 17);
+}
+
+static void
+fini_1 (void)
+{
+  write (STDOUT_FILENO, "DSO fini array 1\n", 17);
+}
+
+static void
+fini_2 (void)
+{
+  write (STDOUT_FILENO, "DSO fini array 2\n", 17);
+}
+
+void
+(*fini_array []) (void) __attribute__ ((section (".fini_array"))) =
+{
+  &fini_0,
+  &fini_1,
+  &fini_2
+};
Index: elf/tst-array3.c
===================================================================
RCS file: elf/tst-array3.c
diff -N elf/tst-array3.c
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ elf/elf/tst-array3.c	29 Oct 2002 05:35:15 -0000
@@ -0,0 +1 @@
+#include "tst-array1.c"
Index: sysdeps/generic/libc-start.c
===================================================================
RCS file: /cvs/glibc/libc/sysdeps/generic/libc-start.c,v
retrieving revision 1.33
diff -u -r1.33 libc-start.c
--- sysdeps/generic/sysdeps/generic/libc-start.c	25 Oct 2002 19:41:24 -0000	1.33
+++ sysdeps/generic/sysdeps/generic/libc-start.c	29 Oct 2002 05:35:16 -0000
@@ -36,6 +36,16 @@
      ;
 #endif
 
+#ifdef HAVE_INITFINI_ARRAY
+# ifdef SHARED
+extern void __libc_init_array (void) __attribute__ ((weak));
+extern void __libc_fini_array (void) __attribute__ ((weak));
+# else
+extern void __libc_preinit_array (void);
+extern void __libc_init_array (void);
+extern void __libc_fini_array (void);
+# endif
+#endif
 
 extern int BP_SYM (__libc_start_main) (int (*main) (int, char **, char **),
 				       int argc,
@@ -115,6 +125,17 @@
   if (fini)
     __cxa_atexit ((void (*) (void *)) fini, NULL, NULL);
 
+#ifdef HAVE_INITFINI_ARRAY
+# ifdef SHARED
+  if (__libc_fini_array)
+# endif
+    __cxa_atexit ((void (*) (void *)) __libc_fini_array, NULL, NULL);
+
+# ifndef SHARED
+  __libc_preinit_array ();
+# endif
+#endif
+
   /* Call the initializer of the program, if any.  */
 #ifdef SHARED
   if (__builtin_expect (GL(dl_debug_mask) & DL_DEBUG_IMPCALLS, 0))
@@ -122,6 +143,13 @@
 #endif
   if (init)
     (*init) ();
+
+#ifdef HAVE_INITFINI_ARRAY
+# ifdef SHARED
+  if (__libc_init_array)
+# endif
+    __libc_init_array ();
+#endif
 
 #ifdef SHARED
   if (__builtin_expect (GL(dl_debug_mask) & DL_DEBUG_IMPCALLS, 0))

Re: patch to make init_array work (2nd version; resend)

[Roland McGrath]

You'll have to forgive me if there is some context I don't have about this
new init-array stuff, which was invented while I was not actively involved. 
Unless Uli answers with specific comments, I will just be figuring out the
issues from scratch myself starting now.

Your dl-fini.c fix is obviously correct and I put that in.

None of the messages I have seen from you or HJ have mentioned what the
problem being fixed by HJ's changes was, so I had to look at the whole
thing for a while to figure out what the point was.  (The arrays are already
processed properly in loaded objects, but not in the executable itself.)
Now that I see the problem, I can at least put in those test cases.

I don't like HJ's implementation, which introduces three new relocs in
libc.so with weak references to symbols defined in crt1.o.  That's just
nasty.  The simple thing would be to pass more arguments to
__libc_start_main, which would require versioning.

But I think that, in keeping with the convention that its own .init/.fini
are the executable's problem, it would be cleanest for the arrays just to
be handled by the existing init/fini functions in the executable.  That is,
have the single function pair it passes (now _init/_fini) do all the work.
My first thought was to just put the code into crti.o/crtn.o, but this code
should not go into shared libraries.

Re: patch to make init_array work (2nd version; resend)

[David Mosberger]

>>>>> On Thu, 7 Nov 2002 13:31:39 -0800, Roland McGrath <roland@redhat.com> said:

  Roland> Your dl-fini.c fix is obviously correct and I put that in.

Great!  Thanks a lot!

  Roland> None of the messages I have seen from you or HJ have
  Roland> mentioned what the problem being fixed by HJ's changes was,
  Roland> so I had to look at the whole thing for a while to figure
  Roland> out what the point was.  (The arrays are already processed
  Roland> properly in loaded objects, but not in the executable
  Roland> itself.)  Now that I see the problem, I can at least put in
  Roland> those test cases.

Sorry, I think neither HJ nor I were trying to be cryptic.  Yes, the
main problem is indeed that .init_array/.fini_array don't get called
for the main program (though HJ's patch obviously address other things
as well, such as correcting the order of .fini_array calls and adding
test case).

  Roland> I don't like HJ's implementation, which introduces three new
  Roland> relocs in libc.so with weak references to symbols defined in
  Roland> crt1.o.  That's just nasty.  The simple thing would be to
  Roland> pass more arguments to __libc_start_main, which would
  Roland> require versioning.

  Roland> But I think that, in keeping with the convention that its
  Roland> own .init/.fini are the executable's problem, it would be
  Roland> cleanest for the arrays just to be handled by the existing
  Roland> init/fini functions in the executable.  That is, have the
  Roland> single function pair it passes (now _init/_fini) do all the
  Roland> work.  My first thought was to just put the code into
  Roland> crti.o/crtn.o, but this code should not go into shared
  Roland> libraries.

OK, I _think_ I understand your concern.  Perhaps we could just change
the platform-specific start.S to pass a different _init/_fini function
which takes care of calling init_array/fini_array?  If you think that
would work, I can take a stab at doing that for
sysdeps/ia64/elf/start.S.

Thanks,

	--david

Re: patch to make init_array work (2nd version; resend)

[Roland McGrath]

> OK, I _think_ I understand your concern.  Perhaps we could just change
> the platform-specific start.S to pass a different _init/_fini function
> which takes care of calling init_array/fini_array?  If you think that
> would work, I can take a stab at doing that for sysdeps/ia64/elf/start.S.

That seems like a reasonable thing to do, though it's unfortunate it means
changing all the platforms' start.S files.  For preinit_array+init_array,
start.S could just contain the code in the .init section, no?  But probably
it is better to write generic _init/_fini replacements in C.

Re: patch to make init_array work (2nd version; resend)

[David Mosberger]

>>>>> On Thu, 7 Nov 2002 13:58:52 -0800, Roland McGrath <roland@redhat.com> said:

  Roland> That seems like a reasonable thing to do, though it's
  Roland> unfortunate it means changing all the platforms' start.S
  Roland> files.

Yes.

  Roland> For preinit_array+init_array, start.S could just contain the
  Roland> code in the .init section, no?

Perhaps, but it would defeat the whole purpose of switching to
init_array (see my previous mail about why any call in .init/.fini
causes incorrect unwind info).

	--david

Re: patch to make init_array work (2nd version; resend)

[Roland McGrath]

> Perhaps, but it would defeat the whole purpose of switching to
> init_array (see my previous mail about why any call in .init/.fini
> causes incorrect unwind info).

Since this part of the section is generated normally along with the
prologue, I would think that its unwind info would come out normally too.

Re: patch to make init_array work (2nd version; resend)

[David Mosberger]

>>>>> On Thu, 7 Nov 2002 14:29:24 -0800, Roland McGrath <roland@redhat.com> said:

  >> Perhaps, but it would defeat the whole purpose of switching to
  >> init_array (see my previous mail about why any call in
  >> .init/.fini causes incorrect unwind info).

  Roland> Since this part of the section is generated normally along
  Roland> with the prologue, I would think that its unwind info would
  Roland> come out normally too.

For .init, wouldn't the new code have to go into the epilogue to
ensure that the .init_array entries are called after .init?

	--david

Re: patch to make init_array work (2nd version; resend)

[Richard Henderson]

On Thu, Nov 07, 2002 at 01:58:52PM -0800, Roland McGrath wrote:
> That seems like a reasonable thing to do, though it's unfortunate it means
> changing all the platforms' start.S files.  For preinit_array+init_array,
> start.S could just contain the code in the .init section, no?  But probably
> it is better to write generic _init/_fini replacements in C.

I think the best solution is to write

	static void
	do_all_init(void)
	{
	  // Loop over .preinit_array
	  // Loop over .init_array
	  _init ();
	}

or whatever the proper ordering is, and then pass this
new function to __libc_start_main.


r~

Re: patch to make init_array work (2nd version; resend)

[Roland McGrath]

> On Thu, Nov 07, 2002 at 01:58:52PM -0800, Roland McGrath wrote:
> > That seems like a reasonable thing to do, though it's unfortunate it means
> > changing all the platforms' start.S files.  For preinit_array+init_array,
> > start.S could just contain the code in the .init section, no?  But probably
> > it is better to write generic _init/_fini replacements in C.
> 
> I think the best solution is to write
> 
> 	static void
> 	do_all_init(void)
> 	{
> 	  // Loop over .preinit_array
> 	  // Loop over .init_array
> 	  _init ();
> 	}
> 
> or whatever the proper ordering is, and then pass this
> new function to __libc_start_main.

Yup, that's the C I was talking about.

Re: patch to make init_array work (2nd version; resend)

[David Mosberger]

>>>>> On Thu, 7 Nov 2002 18:20:09 -0800, Roland McGrath <roland@redhat.com> said:

  >> On Thu, Nov 07, 2002 at 01:58:52PM -0800, Roland McGrath wrote: >
  >> That seems like a reasonable thing to do, though it's unfortunate
  >> it means > changing all the platforms' start.S files.  For
  >> preinit_array+init_array, > start.S could just contain the code
  >> in the .init section, no?  But probably > it is better to write
  >> generic _init/_fini replacements in C.
  >>
  >> I think the best solution is to write
  >>
  >> static void do_all_init(void) { // Loop over .preinit_array //
  >> Loop over .init_array _init (); }
  >>
  >> or whatever the proper ordering is, and then pass this new
  >> function to __libc_start_main.

  Roland> Yup, that's the C I was talking about.

I suppose it makes sense to put do_all_init() and do_all_fini() in a
shared source file.  Do you want to do that or should I work on it?
If the latter, just tell me where you want the functions.

	--david

Re: patch to make init_array work (2nd version; resend)

[Roland McGrath]

> I suppose it makes sense to put do_all_init() and do_all_fini() in a
> shared source file.  Do you want to do that or should I work on it?
> If the latter, just tell me where you want the functions.

I suppose csu/init.c makes sense.  I think you can make them static if you
use attribute_used so they are definitely there when the ld -r with start.o
is done.

Re: patch to make init_array work (2nd version; resend)

[David Mosberger]

>>>>> On Fri, 8 Nov 2002 11:34:31 -0800, Roland McGrath <roland@frob.com> said:

  Roland> When this approach came up before, Ulrich also objected to
  Roland> the implementation, see
  Roland> http://sources.redhat.com/ml/libc-alpha/2002-03/msg00063.html.
  Roland> In future repostings of patches previously discussed, it
  Roland> would be helpful if you could cite the prior posting and
  Roland> discussion in the mailing list archives, for the benefit of
  Roland> people like me who were not involved in the discussion the
  Roland> first time around.

Yes, though I did point to the thread earlier on
(see http://sources.redhat.com/ml/libc-hacker/2002-10/msg00085.html).

  Roland> That suggested approach is not available for static linking,
  Roland> however.

Right.

  Roland> I am inclined to think the plan we discussed yesterday is
  Roland> the best one.

I like it, too.

	--david

Re: patch to make init_array work (2nd version; resend)

[Roland McGrath]

When this approach came up before, Ulrich also objected to the implementation,
see http://sources.redhat.com/ml/libc-alpha/2002-03/msg00063.html.
In future repostings of patches previously discussed, it would be helpful
if you could cite the prior posting and discussion in the mailing list
archives, for the benefit of people like me who were not involved in the
discussion the first time around.

For dynamic executables, the dynamic linker or libc could in fact examine
the DT_INIT_ARRAY slots directly, rather than having the crt1.o code supply
the values.  I think this is what Ulrich wanted to see from what he said in
the message cited above.

The same is true of DT_INIT/DT_FINI, but for whatever reason the convention
inherited from SVR4 is to have the startup code call its own _init and
_fini entry points rather than the dynamic linker doing it.  

That suggested approach is not available for static linking, however.  We
need to keep the same crt1.o code for both static and dynamic linking (or
else all go raving mad).  So it is not entirely clear to me what exact
criteria the ideal solution should meet.

I am inclined to think the plan we discussed yesterday is the best one.
But if Ulrich prefers to have ld.so or libc look up DT_INIT_ARRAY et al,
then I would like to hear his thoughts on the plan for static linking.



Thanks,
Roland