Messages in this thread | | | Date | Sun, 17 Nov 2002 12:59:59 -0800 | From | Richard Henderson <> | Subject | Re: in-kernel linking issues |
| |
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~ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |