brian.lu wrote: > Hi, Michael, > > Thanks very much for your help. > > If libbar.so is linked against libthread on S10, will this increase the > loading time when loading libbar.so?
yes - in theory, but very little. libthread on S10 is just a shell (filter library) which redirect bindings to libc. The only real cost is the time it takes to map in a couple of pages into memory which represent libthread. In the overall startup of firefox, I bet you can't even measure it... > > In your last e-mail, you say " When *libthread* is loaded,you cause the > threading libraries to enforce the POSIX model for the threads > library instead of the Solaris one." I think it should be "libpthread" > right? yes - libpthread. > > Every time when I start firefox, I want to make sure that shared > libraries are not in "Cache". The only way I know is to restart computer. > Do you know a better method? I don't know of a tool that does this for you, although there could be one. To do this very thing I once put together the attached memflush.c. You can point it at the shared libraries you want flushed - and it will load & flush them. If there are no other instances of the library loaded (other processes) it should cause them to be loaded from memory. > > How can I preload some shared libraries after the system boots? You want to warm the memory cache for a given object? There is no built in support to do that - I guess you could do a ldd <obj> to cause objects to be loaded. That should essentially place them into the cache..... > > Thanks again. > > Brian > > Michael Walker wrote: > >> brian.lu wrote: >> >>> Hi, experts, >>> >>> I'm really appreciate for your help. These do help me a lot really. >>> >>> I have some further questions. Please see them below inlined. >>> >>> >>> Michael Walker wrote: >>> >>>> brian.lu wrote: >>>> >>>>> Hi, experts, >>>>> >>>>> I use "ldd -u -r some-shared-library" to try to find out >>>>> unreferenced shared libraries for all mozilla shared libraries. >>>>> According to the ldd manual, all such kind of shared libraries >>>>> should be removed and this can reduce loading time. >>>>> >>>>> Now I have some questions about this: >>>>> 1. When I used "ldd -r -u libfoo.so", I was told that >>>>> "libthread.so" is an "unused object". Does that mean that >>>>> libthread.so is not >>>>> needed by libfoo.so? >>>> >>>> >>>> >>>> >>>> >>>> That's what it's saying... >>>> >>> Sorry, I'm not an English speaker. So you mean it is safe to remove >>> all those ?unused object"? >> >> >> >> yes - that's correct. >> >>> >>>>> >>>>> 2. I checked the command line of generating libfoo.so, there is no >>>>> options related to libthread.so. e.g. no "-lthread" is given. Why >>>>> "ldd" or the runtime linker "ld.so.1" knows that libfoo.so depends >>>>> on libthread.so? >>>> >>>> >>>> >>>> >>>> >>>> It could be a dependency of one of the dependencies of libfoo.so? >>>> >>>> It could be that the compiler driver decided you needed libthread.so >>>> and >>>> inserted it (I think C++/gcc does this sometimes). >>>> >>>> If you do a 'ldd -s libfoo.so' - ldd give you details on the search >>>> for objects it's loaded - and *why* it needs to load it. You can >>>> determine >>>> exactly which object has the dependency on libthread.so >>>> >>> I used the "ldd -s libfoo.so" and I found libthread.so is only >>> required by some other mozilla shared library which libfoo.so depends >>> on, say "libbar.so". >>> But when I use "ldd -u -r libbar.so", Nothing is reported as "unused >>> object". I.e. libthread.so is really *needed* by libbar.so, If so, >>> why libfoo.so says >>> libthread.so is *not* needed? >>> If this is a compiler issue, is there any compiler export that I can >>> contract? >>> >>> Further, I found S10 also provide libpthread.so. Both libraries >>> provide pthread_* APIs. Some mozilla shared libraries linked both >>> libthread.so and libpthread.so. >>> What's the difference between these two libraries? >>> Is it necessary to link the both libraries? >> >> >> >> You're on S10 - then this get's even a little bit more convoluted. >> One of the big changes (among all of the others) is that libthread >> has been merged into libc.so.1. So - you will find that libc.so.1 >> also offers all of the same threading interfaces that libthread.so.1 >> offers. libthread is actually just a 'filter' library which redirects >> the references into libc. >> >> So - if libc is loaded before libthread - then all bindings to libthread >> will actually end up binding to the threading interfaces in libc. This >> is true for S10. If you want to see the actual bindings - try running >> LDD with the foll >> >> % ldd -e LD_DEBUG=bindings -u -r libbar.so >> ... >> >> >> At this point - ldd will report all of the bindings occuring and >> between which objects. You can actually see where 'mutex_lock' is >> actually binding to - or any other symbol of interest. >> >> If you were to perform the same experiment on S9 - you might find >> a different answer. This is due to the fact that libthread & libc were >> independent libraries pre S10. >> >> So - what you need to track is what release are the binaries you >> are building targeted for? If it's S10 and later - then it sounds >> like you do not need to link against libthread. If you want to >> run on S8, S9, & S10 - you should link against libthread (for those >> libraries who need it) - and on S10 just be aware that it isn't actually >> needed, but is not doing any harm and gives you a binary that is >> backwards >> compatible. >> >> To your question on libthread vs. libpthread. There are differing >> semantics >> to the threading interfaces, there is the Solaris Threads interface and >> there is the POSIX threads interface (Solaris came first). To my >> understanding these are >> 98% compatible - but there are a couple of sublte changes. When >> libthread is loaded >> you cause the threading libraries to enforce the POSIX model for the >> threads >> library instead of the Solaris one. Take a look at the man pages for >> libpthread & libthread for further pointers. >> >> >> _Mike_ >> >> >>> >>> >>> Thanks a lot for your help. >>> >>> Brian >>> >>> >>>> >>>> _Mike_ >>>> >>>> >>>>> >>>>> _______________________________________________ >>>>> tools-linking mailing list >>>>> tools-linking at opensolaris.org >>>> >>>> >>>> >>>> >>>> >> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: memflush.c URL: <http://mail.opensolaris.org/pipermail/tools-linking/attachments/20051107/13645473/attachment.c>
