Date: Wed, 28 Feb 2001 11:16:43 -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: <3A9D246B.D254796B@wgate.com> References: <Pine.BSF.4.21.0103010229150.3974-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: > > > Bruce Evans wrote: > > > No debugging symbols are required, only some static ones. This is > > > because utilities require almost all symbols to be visible so that > > > they can be hacked on via kmem (if the kmem hack is used at all). > > > The publicness of symbols via the kmem hack has very little to do with > > > their publicness (external linkage) as C symbols or how the symbol > > > table is organized. It just happens that a.out format made access to > > > all symbols equally easy. ELF raised the bar, and nonstandard loaders > > > still haven't all jumped it. > > > > The "static" ones are only in the debugging sections (for obvious reasons > > of the fact that they are not public) > > Normal kernels don't have any debugging symbols. I define "debugging > symbols" as ones not stripped by strip --debug. However, static symbols > are required debugger using ddb (the internal kernel debugger). > > > The fix you had only works if the kernel has a way to load itself. This > > does not work for things like Etherboot which does not load the debug > > symbols (it does load the Elf DYNAMIC section, but that does not have > > symbols that are not exported) > > This is a bug in Etherboot. All loaders should load all the symbols > that are available, at least optionally, to support internal debugging > It's easier to load all sections that have debugging information of > any kind (not restricted by the above definition) than to provide > options to load them. You can use strip or objcopy to delete the > information that you don't want. Line numbers may be useful in ddb. > I think line numbers are also required (together with other information) > for basic block profiling. I'm not sure if basic block profiling still > works. That is a reasonable request and desire. It would depend on getting all kernels (FreeBSD/Linux/QNX/etc) to agree the way in which they find non-PT_LOAD loaded data (there is no pointer to it somewhere) 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 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) Just like function prototypes and other such things, externally defined interfaces should be known and not just "anything that we have a symbol for" 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) > > 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 "black box" work (sysctl and object-oriented mechanisms are much better albeit with some overhead) but it is much worse to just have "any variable" be accessable rather than just the defined subset that are part of the design. > > 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. (And sometimes even have comments saying that they should not be, as in FSCALE... That is, if I read that comment correctly.) -- 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?3A9D246B.D254796B>