Date: Tue, 25 Apr 95 11:19:01 MDT From: terry@cs.weber.edu (Terry Lambert) To: patl@asimov.lashley.slip.netcom.com Cc: roberto@blaise.ibp.fr, nate@trout.sri.MT.net, hackers@FreeBSD.org Subject: Re: benchmark hell.. Message-ID: <9504251719.AA00233@cs.weber.edu> In-Reply-To: <9504251548.AA10160@lashley.slip.netcom.com> from "patl@asimov.lashley.slip.netcom.com" at Apr 25, 95 08:48:41 am
next in thread | previous in thread | raw e-mail | index | archive | help
> One thing that helps quite a bit, independant of object file format, > is what the Sun folks call a 'symbol hiding linker'. Basicly, it is > linker extensions that let the developer specify which symbols are to > be exported, and which ones are local to the library itself. Reducing > the final symbol table size speeds the dynamic linking at execution time. Clearly, this would also resolve the problem of "curses" with the C++ libraries. The problem in the current implementation that prevents this is that the link does not "run to completion" as it would with a normal library archive; that is, instead of dragging in only the externally referenced code from the shared lib as linked dynamic symbols and then dragging in only the library data referenced by the code in the program and the code previously dragged in, all data and all code are dragged in. This is an inevitable result of not using an archive format for the shared library objects so they can be pulled in an object at a time (or not), which is what you do with normal library archives. This has long been a pain in my rear. I think there is a distinction to be made between mapping the library into the user's address space and actually consuming or linking the symbols runtime. It's quite possible to shorten the list via directed graph without going to a fully symbol hiding linker (if an archive format is used instead of using ld to build a single object module). Crude symbol hiding is what Linux currently uses to draw the distinction between exported and non-exported kernel interfaces to achive AIX-like exported symbol lists for use by loadable kernel modules. Combined with the relocation located in the kernel, they have an extremely powerful (AIX-like) kernel module mechanism that can include things like one module causing another to be demand loaded (currently impossible in BSD because of the inability to load modules with a purely kernel interface based on computing transitive closure over a module dependency list, and the dependencies in the module depended on, etc.). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9504251719.AA00233>