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

[Roland McGrath <roland@redhat.com>]

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.