Date: Wed, 28 Feb 2001 07:37:19 -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: <3A9CF0FF.804199EE@wgate.com> References: <Pine.BSF.4.21.0102281753170.1204-100000@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote: > > On Tue, 27 Feb 2001, Michael Sinz wrote: > > > > On Mon, 13 Mar 2000, Ruslan Ermilov wrote: > > > > > > > One thing that should IMHO be pointed out in the upcoming 4.0-RELEASE's > > > > ERRATA (or some more appropriate place), is the fact that the loader(8) > > > > is now a prerequisite for certain programs using kvm(3) interface. > > > > Obvious examples are top(1) and swapinfo(8). > > > > > > > > If you boot your kernel without loader(8), directly through bootblocks, > > > > these programs will not work. > > > > [I wrote] > > > I don't user loader(8), and finally got around to fixing this. The > > > problem is that the kernel linker wants module data for the kernel. > > > It defaults to using incomplete data if none is present. The following > > > supplies slightly less incomplete data: > > > > [...] > > > > Note that the "using incomplete data" is not really correct. It uses > > complete data -- the dynamic section, aka the publicly defined symbols. > > The problem is that FreeBSD requires the debug symbols. > > It's the module data that is incomplete. My hack doesn't completely fix > this. It only supplies enough data for the kernel linker to see all the > sections that have been loaded. > > 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) 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) 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. 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. -- 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?3A9CF0FF.804199EE>