Date: Thu, 1 Mar 2001 15:44:38 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Michael Sinz <msinz@wgate.com> Cc: "Duane H. Hesser" <dhh@androcles.com>, Randell Jesup <rjesup@wgate.com>, "(Bruce Bauman)" <bbauman@wgate.com>, Alfred Perlstein <bright@wintelcom.net>, arch@FreeBSD.ORG Subject: Re: ELF and diskless boot Message-ID: <Pine.BSF.4.21.0103011452140.1021-100000@besplex.bde.org> In-Reply-To: <3A9D246B.D254796B@wgate.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 28 Feb 2001, Michael Sinz wrote: > The real issue, however, is that external tools are using internal symbols > rather than public interfaces. sysctl is the real way to do this but > even without sysctl, public interfaces for things like top/etc. should > be somehow designated as "public" or even "semi-public". As it is, if two Sysctl just doesn't work for dead kernels. The symbols must be in the kernel executable (or somewhere) so that ps, etc. can find them. (top is not in "etc." here because it doesn't support dead kernels, and since its main purpose is presenting a real-time display, making it work on dead kernels wouldn't be very useful. Similarly for systat.) All symbols, including fully debugging symbols, must be available somewhere for debugging dead kernels. > source files happen to have the same named static variable (which is > perfectly legal and part of what static keyword provides) the lookup will > "randomly" return one of them. (Randomly in this case depends on the link > order) Good point, but again support for debugging makes it moot. Kernel symbols should be unique so that they can be distinguished by simple debuggers like ddb and types easily in full debuggers. > BTW - I agree that the ddb kernel needs its internal symbols. But that is > debugging and not operational behavior. If you issue the command: > > strip kernel > > The end result should work just as well for production use as a non-stripped > kernel. (Yes, debugging is not as good, but that is not what we are talking > about) There's no reason that should work better than stripping the text section. The kernel Makefile issues all the strip commands that can be done easily and are safe. It's just not worth the effort to strip more. The extras just waste 5c worth of disk space and a few msec of booting time. > > > As far as Elf raising the bar goes, it does a better job of separating > > > external vs internal symbols. Making the loaders provide access to all > > > symbols is not the correct solution. The correct solution is to have > > > any symbols that are defined for "external access" to be defined as such. > > > > I disagree. Exporting bits of the kernel using linker symbols isn't > > the correct solution for anything except possibly for examining dead > > kernels, but it's easy to use. Loaders need to support all symbols > > for other reasons. > > The linker symbols (external ones) are the way shared libraries link to > each other. This is the defined mechanism. Now, it is not the best for Don't get me started on the evilness of shared libraries :-). > > > BTW - there is little to prevent a compiler from doing nasty optimizations > > > with variables that are marked "static" since it has full knowledge of the > > > scope of thos variables (or at least it thinks it does since it has been > > > told so in the source) But this is a different issue and does not currently > > affect GCC/x86 systems for various reasons. > > > > Similarly for all symbols if the linker is part of the compiler and > > understands the scope of everything. > > I agree (and have worked with compilers that do that) which is even more > reason to define which objects/symbols/etc are part of the public interface > and which are internal use only. The current (4.x) system does not provide > any way of doing so and has tools (top/vmstat/etc) that depend on access > to a variety of symbols that are not obviously exported for direct access. Regrading to 2.x would bring back support for symbols.raw which is supposed to list all "public" symbols. This file rotted before 2.x. > (And sometimes even have comments saying that they should not be, as in > FSCALE... That is, if I read that comment correctly.) I think that comment is mostly out of date now. ps uses only the kern.fscale sysctl. However, this seems to weaken ps's support for dead kernels. There are some even more cryptically exported symbols for supporting gdb on dead kernels. Some of them are in symbols.raw, but the easiest way to find out about them is to try removing them. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0103011452140.1021-100000>