Date: Thu, 01 Mar 2001 08:07:28 -0500 From: Michael Sinz <msinz@wgate.com> To: Bruce Evans <bde@zeta.org.au> 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: <3A9E4990.ACE5EF50@wgate.com> References: <Pine.BSF.4.21.0103011452140.1021-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote: > > 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. Like I said elsewhere - debugging (and debugging a dead kernel would fall into that catagory) is very different than the act of handling active systems. You seem to be very caught up on the "debugging dead kernels" which, while very important when kernel hacking (of which I have done my fair share, past and present) I do not see how that relates to operational use of a system. Plus, there is nothing that states that ps/top/etc can not have access to some public symbol that is the sysctl list when the kernel is dead. However, depending on such "open kemono" system structures for operational use (ps is an operational tool more so than a debug dead kernel tool) just begs for problems as the system grows and evolves. > > 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. So, in a large project I would need to make sure that I never use a name for a static symbol that some other file has already used? How does that get solved long term? It would seem to me that > > > 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. It has nothing to do with boot time/disk space/memory (albeit some may have issues with these but that is not the reasoning I am presenting) The issue is how one defines the interfaces into a system. It usually is not one of "whatever code there is, feel free to call it" but rather "these are the defined functions we provide - all other code is internal and used to provide these defined functions and may change with the next revision as we extend/enhance/fix things." When I use "functions" above, that does not mean just function calls like open() or malloc() but rather all interfaces, including variables and other defined access points and values. As it is now, there is nothing that would suggest to someone hacking at a tool that using, for example, the bpf_iflist symbol is not a valid action to take. (Or ihashtbl or any of the other static variables...) Maybe the answer is that the sysctl list is what the public interface is. And note that it is very easy to walk the sysctl list yourself in a dead kernel - even the as yet unregisted sets as they are in a simple array linked off of a public symbol that happens to be in a very standard format and thus lets you find them by just looking for symbols of that form. But, again, there is a difference between debugging the kernel and operational work. (Except for when kernel hacking is what you do, at which point operational work is debugging the kernel - and at that time, I know I am very glad to have symbols but I also know that I build with symbols.) > > > > 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 :-). Yes, there are problems and lets not go there... > > > > 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. Again, there should be no reason for ps not to have some kernel grubbing mode but is that the way the normal case should be? > 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. Yum... (oh, sorry, just ate a good bunch of symbols for breakfast :-) -- Michael Sinz ---- Worldgate Communications ---- msinz@wgate.com A master's secrets are only as good as the master's ability to explain them to others. 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?3A9E4990.ACE5EF50>