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] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |