On Sat, Dec 01, 2007 at 06:35:35PM -0500, Christos Zoulas wrote:
> On Dec 1, 10:55pm, ad@netbsd.org (Andrew Doran) wrote:
> -- Subject: Re: bin/37347: ld.elf_so does not execute .init/.fini functions i
> 
> | The following reply was made to PR bin/37347; it has been noted by GNATS.
> | 
> | From: Andrew Doran <ad@netbsd.org>
> | To: gnats-bugs@netbsd.org
> | Cc: 
> | Subject: Re: bin/37347: ld.elf_so does not execute .init/.fini functions in order
> | Date: Sat, 1 Dec 2007 22:51:00 +0000
> | 
> |  I've updated jtc's patch for -current:
> |  
> |  	http://www.netbsd.org/~ad/ld-current.diff
> |  
> 
> Why don't you commit it?

I think it could use more test coverage. There is still another problem.
shlibs aren't linked directly against libc so there is no dependency
recorded.

libc and threads can get initialized very late on, while the constructors
for other shlibs are already making use of their facilities. We should
probably fix the link process but I'm beginning to think that we need some
sort of special case for libc. I'm not sure how else we can deal with all
the shlibs already out there.

This is from firefox-2 with the patch applied:

_rtld_call_init_functions()
_rtld_initlist_tsort
calling init function /usr/lib/libm387.so.0 at 0xbb379a00
calling init function /usr/lib/libm.so.0 at 0xbb35d740
calling init function /usr/lib/libpthread.so.0 at 0xbb262650
calling init function /usr/pkg/lib/firefox/libnspr4.so at 0xbba3fcc0
calling init function /usr/pkg/lib/firefox/libplds4.so at 0xbba6c9f0
calling init function /usr/pkg/lib/firefox/libplc4.so at 0xbba68f30
calling init function /usr/pkg/lib/firefox/libmozjs.so at 0xbbb51a70
calling init function /usr/lib/libstdc++.so.6 at 0xbb2b7f60
calling init function /usr/lib/libgcc_s.so.1 at 0xbb26d3b0
calling init function /usr/pkg/lib/firefox/libxpcom_core.so at 0xbbac13c0
calling init function /usr/pkg/lib/firefox/libxpcom.so at 0xbbb3e3b0
calling init function /usr/lib/libintl.so.0 at 0xbb37d6e0
calling init function /usr/pkg/lib/libglib-2.0.so.0 at 0xbb390650
calling init function /usr/pkg/lib/libgmodule-2.0.so.0 at 0xbb40eb50
calling init function /usr/pkg/lib/libgobject-2.0.so.0 at 0xbb417960
calling init function /usr/pkg/lib/libgdk_pixbuf-2.0.so.0 at 0xbb693f80
calling init function /usr/X11R6/lib/libX11.so.6 at 0xbb4508d0
calling init function /usr/X11R6/lib/libXext.so.6 at 0xbb67b3c0
calling init function /usr/X11R6/lib/libXi.so.6 at 0xbb6be0e0
calling init function /usr/pkg/lib/libpango-1.0.so.0 at 0xbb50e990
calling init function /usr/lib/libz.so.0 at 0xbb15e470
calling init function /usr/pkg/lib/libfreetype.so.6 at 0xbb555b80
calling init function /usr/pkg/lib/libexpat.so.1 at 0xbb0d4f70
calling init function /usr/pkg/lib/libfontconfig.so.1 at 0xbb5b1b80
calling init function /usr/pkg/lib/libglitz.so.1 at 0xbb13a140
calling init function /usr/pkg/lib/libpng12.so.0 at 0xbb11b120
calling init function /usr/pkg/lib/libXrender.so.1 at 0xbb5001b0
calling init function /usr/X11R6/lib/libICE.so.6 at 0xbb0f3c80
calling init function /usr/X11R6/lib/libSM.so.6 at 0xbb111d40
calling init function /usr/pkg/lib/libcairo.so.2 at 0xbb604420
calling init function /usr/pkg/lib/libpangoft2-1.0.so.0 at 0xbb5d9c90
calling init function /usr/pkg/lib/libpangocairo-1.0.so.0 at 0xbb68b6a0
calling init function /usr/pkg/lib/libXrandr.so.2 at 0xbb686b60
calling init function /usr/pkg/lib/libXfixes.so.0 at 0xbb663d90
calling init function /usr/pkg/lib/libXcursor.so.1 at 0xbb669c20
calling init function /usr/pkg/lib/libgdk-x11-2.0.so.0 at 0xbb6d6df0
calling init function /usr/pkg/lib/libatk-1.0.so.0 at 0xbb6aaab0
calling init function /usr/pkg/lib/libgtk-x11-2.0.so.0 at 0xbb787e30
calling init function /usr/lib/libz.so.1 at 0xbb53f2e0
calling init function /usr/lib/libc.so.12 at 0xbb186170

Doing a string match on the name isn't great, so I'm wondering if there
is another cheap way to identify it, like something in the ELF headers.

Andrew