Please see my comments below. tools-linking-request at opensolaris.org wrote: > Send tools-linking mailing list submissions to > tools-linking at opensolaris.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.opensolaris.org/mailman/listinfo/tools-linking > or, via email, send a message with subject or body 'help' to > tools-linking-request at opensolaris.org > > You can reach the person managing the list at > tools-linking-owner at opensolaris.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tools-linking digest..." > > > Today's Topics: > > 1. How to tell the runtime linker not to resovle some symbol? > (brian.lu) > 2. Re: How to tell the runtime linker not to resovle some > symbol? (Rod Evans) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 06 Sep 2006 14:03:32 +0800 > From: "brian.lu" <Brian.Lu at Sun.COM> > Subject: [tools-linking] How to tell the runtime linker not to resovle > some symbol? > To: tools-linking at opensolaris.org > Message-ID: <44FE64B4.5090508 at sun.com> > Content-Type: text/plain; format=flowed; charset=ISO-8859-1 > > Hi, experts, > > We met a problem when tuning firefox startup performance. The issue is: > NSPR shared library (which is used by Firefox) exports an interface (a > function name) to the applications (like Firefox). Applications can > provide a implementation of that function to override some > function provided by NSPR. Firefox doesn't use that interface. I.e. it > doesn't define that symbol. > > But every time, when firefox starts, NSPR lookups that symbol by using > dlsym(). That takes some time and fails finally. We can't modify the > NSPR codes > because it is not part of firefox code base. > Does ld.so.1 provide some mechanism that we can void looking up this > symbol in firefox? > > Thanks > > Brian > > > ------------------------------ > > Message: 2 > Date: Wed, 06 Sep 2006 09:16:27 -0700 > From: Rod Evans <Rod.Evans at sun.com> > Subject: Re: [tools-linking] How to tell the runtime linker not to > resovle some symbol? > To: "brian.lu" <Brian.Lu at sun.com> > Cc: tools-linking at opensolaris.org > Message-ID: <44FEF45B.9050206 at sun.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > brian.lu wrote: > >> Hi, experts, >> >> We met a problem when tuning firefox startup performance. The issue is: >> NSPR shared library (which is used by Firefox) exports an interface (a >> function name) to the applications (like Firefox). Applications can >> provide a implementation of that function to override some >> function provided by NSPR. Firefox doesn't use that interface. I.e. it >> doesn't define that symbol. >> >> But every time, when firefox starts, NSPR lookups that symbol by using >> dlsym(). That takes some time and fails finally. We can't modify the >> NSPR codes >> because it is not part of firefox code base. >> Does ld.so.1 provide some mechanism that we can void looking up this >> symbol in firefox? >> > > Presumably you're referring to: > > 21799: 1: file=0; dlopen() called from file=/usr/lib/mps/libnspr4.so \ > [ RTLD_LAZY RTLD_LOCAL RTLD_GROUP RTLD_WORLD ] > ...... > > 21799: 1: symbol=nspr_use_zone_allocator; dlsym() called from \ > file=/usr/lib/mps/libnspr4.so; starting at > file=/usr/lib/firefox/firefox-bin > ...... > > Which then looks for the symbol in every dependency that has so far been > loaded, and then causes a bunch of pending lazy-loaded objects to be brought > in in an attempt to find the symbol? > > And you can't change libnspr to either use dlopen(0, RTLD_FIRST), or use > dlsym(RTLD_PROBE)? > We can't change this because the code is in NSPR which is not owned by our team. > Could you not provide nspr_use_zone_allocator() as some null routine in > firefox? > We can't provide the nspr_use_zone_allocator() either. The routine is used for server applications. > Hmmm, the idea of defining a symbol within an object, and then tagging > it in some way as "does-not-exist" such that a symbol lookup would > be aborted when this symbol is found, is an idea to chew on :-) > > Can runtime linker provide some feature like "don't resolve this symbol even it is looked up by dlsym()"?
Thanks Brian
