This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |