On Thu, Apr 2, 2009 at 8:34 AM, Pavan Chandrashekar - Sun Microsystems <pavan.chandrashe...@sun.com> wrote: > > This observation of yours is correct but there is more to the story. > I did the following: > truss -u a.out -u libc -o dladm.log dladm show-link > > on both a s10u6 machine and a Nevada build 92 machine. Looks like ld behaves > differently on both. On s10u6, a resolvepath was called on all the libraries > that the executable depended on right away, even before making any calls to > any of the APIs. > But on Nevada, they were done on a true "on-demand" basis. So, that explains > your difference in behaviour, and also the one with the strcmp that you used > as a check point to see if the libraries were loaded.
Yeah, this jibes with what I've been seeing, and I'd tracked it down to lazy loading by the linker. (I used dtrace to stop the executable both before and after the first libdladm call, and then I ran pldd on the stopped binary.) So something has changed so that everything is lazily loaded. Regardless of that, dtrace should still be doing the right thing. I'm looking into why it's not doing the right thing. Chad _______________________________________________ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
