Re: in-kernel linking issues

[Richard Henderson <rth@twiddle.net>]

Another Idea:

Why build our own __ksymtab section, which contains names and
addresses in some random order that requires a linear search,
when instead we can re-use the dynamic symbol table for the 
shared library.  If we do that, we no longer have a linear search,
but can use the hash table provided by the linker.  Plus we don't
have to work so hard to get rid of it.  ;-)

Consider

#define EXPORT_SYMBOL(sym)			\
	asm (".section .exports\n"		\
	     "	.asciz \"" #sym "\"\n"		\
	     ".previous")

then link with '--version-exports-section ""'.  This will result
in a .dynsym section that contains exactly those symbols we asked
to exported from the module (plus the undefineds, but that's obvious).

This has other benefits in that the linker will now know that
the symbols not exported may be able to have their relocations
satisfied completely at link time, which results in fewer dynamic
relocations.

Along that same vein, we should be using the link option -Bsymbolic,
since we do not allow modules to override one another's symbols,
and this describes that fact to the linker.  Which will result in
even fewer dynamic relocations.

The problem remaining here is to get the same dynamic symbol table
generated for the kernel itself.  This is where we'd really win with
the hashing, since the kernel has by far the largest symbol table.
I'll have to give this some more thought.


r~