in-kernel linking issues

So you said you had a userland test harness?

Some problems I've seen browsing the code:

(1) You make no provision for sections to be loaded in any order except the order they appear in the object file. This is bad. You *really* need to replicate something akin to obj_load_order_prio from the 2.4 modutils, lest small data sections be placed incorrectly wrt the GOT section.

(2) I see no provision for small COMMON symbols to be placed in the .sbss section rather than in the .bss section. Unless you are sorting your allocation of COMMON symbols by size, which I also don't see, this can result in link errors due to SCOMMON symbols not being reachable from the GP.

These will affect at least Alpha, IA-64, and MIPS.

(3) Alpha and MIPS64 absolutely require that the core and init allocations are "close" (within 2GB). I don't see how this can be guaranteed with two different vmalloc calls.

Allocating the two together would also allow us to only have one flush_icache_range call. Not that I consider module loading particularly performance critical, but it'd be nice.

That's all I can think of at the moment.

r~

Yes, which is fine for testing basic relocs, but misses some subtle issues. [ Sorry for the delayed reply, I only got this mail via kernel.org: did you
get a bounce from [email protected]? ]

Thanks for this. It adds even more weight to your ET_DYN argument as well. I'll need to play with that linker script some more (on PPC, binfmt_misc.o is 13000 bytes, binfmt_misc.so becomes 156128 bytes 8)

There's still the issue of PPC and PPC64 which can only jump 24-bits away, and so currently insert trampolines which have to be allocated with the module, but that should be no uglier than currently. (They could use a special allocator, too, but with only 16M, they have to ensure noone else uses those addresses).

PPC64 also frobs the TOC ptr (r2) in the trampolines: I don't have a ppc64 box in front of me, but I imagine -shared will do the right thing there too.

Thanks!
Rusty.

   there are those who do and those who hang on and you don't see too
   many doers quoting their contemporaries.  -- Larry McVoy

Nope.

I know what this is -- max architectural page size of 64k. The linker is trying to make the file offset congruent to the address mod 64k. Which adds a *lot* of padding.

Should be fixable by using the -N option.

I would hope that this would be handled by the normal .plt creation. We'll see.

r~

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~