Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 1 Mar 2001 02:57:15 +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.0103010229150.3974-100000@besplex.bde.org>
In-Reply-To: <3A9CF0FF.804199EE@wgate.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

> 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.

> 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.

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.0103010229150.3974-100000>