Date: Tue, 4 Feb 1997 20:50:19 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: chuckr@glue.umd.edu (Chuck Robey) Cc: terry@lambert.org, jmacd@CS.Berkeley.EDU, hackers@freebsd.org Subject: Re: g++, STL and -frepo on FreeBSD-2.2-Beta Message-ID: <199702050350.UAA14160@phaeton.artisoft.com> In-Reply-To: <Pine.OSF.3.95q.970204211959.1889B-100000@baud.eng.umd.edu> from "Chuck Robey" at Feb 4, 97 09:28:48 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> You said you don't think ELF DTRT, altho it could. Maybe it is? My > workaround is to have the virtual tables instantiated everywhere, and it > works, but I wish it worked the way it's supposed to, with just one copy > of the code (and virtual tables, which are the real bogie here, I think). > The object modules corresponding to your fee.C example are there, but the > virtual tables in fee.o are local. ELF's only a neat tool. There are a lot of clever things you could do with ELF. I bet most of them aren't being done, mostly because I don't see them being done, and it is Not The Nature Of Free Software to do these things. For instance, there still isn't a way to ABI-attribute ELF binaries being generated by the linker, even when people have complained about it for nearly a year now. There is a level of architectural complexity that free software never seems to exceed... sort of a "free software glass ceiling". The ELF hack I'm talking about is an obvious link-time version of a load-time optimization, but it's only obvious because I've dealt with code on an ELF machine that deals with segment coloring. I could page in only one instance of the ELF module for all my callers, even though I had multiple real instances in the binary. This type of thing only works with segment coloring to distinguish treatment of one code segment from treatment of another in a binary. This is basically link-time segment coloring with object agregation by color. I frankly don't think the G++ people are up for this type of thing yet because of the environments in which they run... but like I said, I could be wrong. If I was wrong in my scoping argument, it was because I assumed that the pilot error was somewhere other than where it was, not because I assumed pilot error existed. Not a good consolation, but at least I'm not totally off my rocker. 8-). Another clever thing for ELF: put the libkvm code in an ELF segment in the kernel image so it can be accessed by 'ps', 'w', and the kernel debuggers, alike. Then make it operate only on published externals instead of the entire kvm, and make 'ps', 'w', and company operate on exported externals instead of kvm symbols. Reduce the set of kernel interface to make it more modular. Agregate the interface with those exported by existing loadable kernel modules so the name space is entirely transparent. How about agregation of authentication objects, so that I can have one library routine linked that can look up account information from the local password file, the NIS, radiusd, the CISCO thing, LDAP, NDS, or whatever else I wanted to agregate into the thing? There's literally hundreds of these types of things, and they almost all depend on OS support, either to implement them, or to make them obvious. In any case, I'd like to see them do this kind of clever thing, but it requires that we OS geeks cooperate, or it will never occur to them because they won't have an execution environment that could use the changes. Regards, Terry Lambert terry@lambert.org --- 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?199702050350.UAA14160>