Re: Do LKMs work *at*all* on powerpc platforms?

[gabriel rosenkoetter <gr%eclipsed.net@localhost>]

Remember me? I'm back.

I've spent a day digging through modload (src/sbin/modload, if you're
interested in reference), and I can't, for the life of me, fix this.
Yet.

As a refresher:

achemar:misc/module# make load                                             [15]
modload -o miscmod -emiscmod combined.o
combined.o: In function `miscmod_handle':
combined.o(.text+0x4c): relocation truncated to fit: R_PPC_REL24 lkmexists
combined.o(.text+0x100): relocation truncated to fit: R_PPC_REL24 memcpy
combined.o(.text+0x12c): relocation truncated to fit: R_PPC_REL24 memcpy
combined.o(.text+0x148): relocation truncated to fit: R_PPC_REL24 printf
combined.o(.text+0x158): relocation truncated to fit: R_PPC_REL24 printf
combined.o(.text+0x168): relocation truncated to fit: R_PPC_REL24 printf
combined.o(.text+0x178): relocation truncated to fit: R_PPC_REL24 printf
combined.o(.text+0x1b4): relocation truncated to fit: R_PPC_REL24 memcpy
combined.o: In function `miscmod':
combined.o(.text+0x2cc): relocation truncated to fit: R_PPC_REL24 lkm_nofunc
combined.o(.text+0x2fc): relocation truncated to fit: R_PPC_REL24 lkmdispatch
combined.o: In function `misccall':
combined.o(.text+0x350): relocation truncated to fit: R_PPC_REL24 printf
combined.o(.text+0x360): relocation truncated to fit: R_PPC_REL24 printf
combined.o(.text+0x370): relocation truncated to fit: R_PPC_REL24 printf
modload: can't link `combined.o' creating `miscmod' bound to 0xe9244000
*** Error code 1

Stop.

That's through the Makefile for an example LKM (/usr/share/lkm/misc).
ld gets called two ways there, once for prelinking (which works, no
problem) and then again for actual linking before insertion into the
kernel.  The calls to ld actually used (thanks, fprintf(stderr...))
are:

  ld -R /netbsd -e miscmod -o miscmod -Ttext 0x0 combined.o

(which works) and:

  ld -R /netbsd -e miscmod -o miscmod -Ttext 0xe9240000 -Tdata 0xe92404ac 
combined.o

(which doesn't).

What's going on here with the -T flags is that we're specifying
addresses (in the output binary, yes?) for the beginning of the text
and data segments, respectively. I get that. Also, if I leave off
the -Ttext flag on the second one (calling ld myself), ld doesn't
complain. So it's just in writing that text segment (and only when its
writing it to a real address; it's got no problem with the dummy 0x0)
that shit hits the fan (and does even leaving out the -Tdata flag).

At first, I thought that either ld or the modload includes were
confused and trying to build an a.out binary (we went to elf fairly
recently), but the errors don't make sense in that case and, anyway,
using the 0x0 address call to ld yields us a binary, about which
file says:

  miscmod: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1, 
statically linked, not stripped

What the bloody, steaming hell is going on here?

Back to the trenches...

       ~ g r @ eclipsed.net

PS, side question... why do we always statically link? Do we not
support elf shared libs yet on ppc?