Date: Tue, 25 Apr 95 14:32:11 MDT From: terry@cs.weber.edu (Terry Lambert) To: nate@trout.sri.MT.net (Nate Williams) Cc: patl@asimov.lashley.slip.netcom.com, hackers@FreeBSD.org Subject: Re: Shlib complaints ( was Re: benchmark hell..) Message-ID: <9504252032.AA01427@cs.weber.edu> In-Reply-To: <199504251932.NAA12630@trout.sri.MT.net> from "Nate Williams" at Apr 25, 95 01:32:02 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> There is a *large* difference between exporting symbols and importing > symbols. You're trying to wedge two arguements together which don't > belong together. > > 1) Exporting symbols in functions/libraries > 2) Importing symbols from functions/libraries > > The current setup of exporting functions is adequate w/out having to add > the extra overhead of asking the developer to specify which symbols are > to be seen. > > However, because of the current scheme which concatenates all of the > objects together into one big object file, we have difficulties doing > symbol resolution at run-time. These are completely different problems and > should be treated differently. I think we are in violent agreement that there should not be specification of the exported interfaces to reduce the overall symbol space. On the other hand, I believe the problem being pointed at is a real one. And I think it is solvable without restricting the symbol exports. The issue that is being argued is twofold: 1) The symbol space in the static symbol resoloution table in a shared binary is large, so it takes a while to search and is thus "slow". 2) There is pollution of the name space by symbols being required because they are being referenced, and this is in turn the result of the libraries being linked as a monoblock instead of as individual objects (some of which could be omitted). Now, linking as individual objects would relieve both problems. On the other hand, the first problem is succeptible to brute force; that is, prebalancing an AVL tree in the linker so you can bsearch for symbols; it's our damn static fixup code, and this is a relatively trivial change. I think the correct soloution would be to use an archive format instead of a relinked .o for shared libraries. This is somewhat annoying, but can easily be argued that it should be done. There is a question of "what is a shared library" and "PIC code is more expensive". I would propose resolving the library problem by making PIC the default code type for regular libraries; this would mean that it was impossible to to produce a library which could not then be processed into a shared library. The magic piece of the shared library that results in it being monolithic is the symbol fixup code that contains all of the symbols in the library instead of per object module fixup tables. This is more the choice of sticking the fixup code generation in the linker instead of putting it in the archiver, where it probably belongs. > > > This would solve some of the problems I've been trying to work out, but > > > it would mean a re-write of most of the code, which is IMHO not worth it. > > > > It's worth it for the C++ curses problems and it's worth it for unused > > virtual bas classes from a c++ library. > > > > It's also worth it in the reduction of available symbol space. > > Let's see the code to implement this. Now that your legal hassles are > out of the way, I'd *really* like to see code solutions instead of paper > tigers from you. :-) I'm in the process of tackling other tigers right now. You're probably aware of LessTif? 'd prefer a non-GPL'ed Motif clone library. You're probably also aware of the Stream project for Linux? I'm trying to revive my 386BSD 0.1 code for that. I'm also working on ODI driver loading to fix the ethernet problem once and for all. I believe Paul has my todo list and it's pretty big. Equipment is my big problem right now, since it still seems there isn't any decent Intel PCI machines one can buy, there isn't an agree upon SMP box (apparently), and there are plenty of PCMCIA portables, but the only usable ones are in excess of $5000, and they're just barely usable (800x600 internal display). They're also some joint projects that you're not going to hear about until they are done. I sent SEF some game code (prerelease) for evaluation, but haven't heard anything back on it yet... I also uploaded a prerelease of Mimic and haven't heard much on it either. > C'mon Terry, you've been promising this stuff for *years*!!! Let's see > some bits so we can believe that all of this talk has some basis in > reality. I thought you were one of the people who had logged onto the original "Hecate" machine I had at Weber and played with my system using shared libraries... Anyway, you've yheard plenty from me, I've just been real low key about release code (and I've only been free of my legal entanglements for a short while). If someone wants to help with the hacking, I'm prepared to be a bit freer with source for some projects, but only with the people actually helping -- I need end users right now like I need a hole in my head. 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?9504252032.AA01427>