On Thu, 15 Mar 2001, gabriel rosenkoetter wrote:

> Disregarding entirely the background of why I want them, considering
> the conversation devolved into a discussion strictly of that last
> time, rather than how to make a basic function for development of
> OS-related stuff work on one of our ports:
> 
> 1. Why do LKMs not work on the macppc (or any powerpc, as near as I
> can tell) port? (I actually know the answer to this one in part, but
> I'm looking for some new thoughts.)

Because of how LKMs get loaded and how gcc works on ppc.

Here's my understanding: the ppc (and POWER) supports two main types of
jumps, from the compilers point of view, one "short" and the other "long".
Both are available in relative & absolute, and w/ & w/o LR update (JMP vs
JSR in m68k syntax). "Short" and "long" are relative terms, though. The
"short" one can span +/-32MB as I recall. The "short" one is also the only
one which gcc happens to support (emits in generated code). The "short"
variety requires one instruction, while the "long" takes three.

The second part of the problem is that the kernel gets mapped in segment E
(0xExxxxxxx), but the LKMs want to get loaded somewhere else (like segment
2, 0x2xxxxxxx) I believe. This results in the linker wanting to make
relocations which are more than 32 MB away. That doesn't work (This is
what the RELOCATION type 10 errors are which others have seen). The only
way for it to be made to work would be if the compiler had used a
different relocation type, so the jump could happen.

> 2. What would be necessary to make them work? (I'm not in favor of
> the "get a non-NetBSD gcc" or "don't use any builtins" options here,
> thanks.)

Well, it's a shame you're taking that stand against using a different gcc,
since the real fix is to fix gcc. There was a patch sent in to the FSF
which taught gcc about attributes (they might have been pragmas, I can't
recall) that indicate a routine should be called with the long or with the
short jump style, and also to define a default jump style for routines
which don't say. I think the reason that the changes were rejected was
that there were other things in the patches which "were too much." I'm
just repeating what I heard, and not trying to express any value
judgements on the patches. :-)

The idea is that the default would be the "short" jumps. But when making
an LKM, we pass in a gcc flag which changes the default to "long" jumps.
For other routines in the LKM, we can add the attributes or pragmas which
say to use the "short" jumps, so intra-LKM calls are fast.

Also, once someone gets these patches working with our gcc (if they don't
already), they'd become part of the NetBSD gcc. And hopefully they'd get
done in a manner which will make it back into the FSF gcc too. :-)

The only other thing I can think of, which I'd like some input on from
folks more familiar with the ppc kernel layout, is to try to link LKMs in
in the top of the "D" segment. Like starting at 0xdfffffff and working
down. I mean our kernels aren't THAT big (I think 3MB to 4 MB is typical),
so all of the kernel should be within 32 MB of the top of the D segment.
:-)

> 3. Is there any hope of this happening in an even remotely timely
> manner? (Or, "What can I do to make this happen NOW?")

There are only three things I can think of. 1) is get to know gcc &
binutils better. The existing FSF patches should be a guide, and I think
their author is around here somewhere. :-) The one complication here is
that I think tv@netbsd.org is in the middle of a binutils update, so the
tool chain is subject to change.

2) get to know lkm linking better, and teach mod_load & friends to load
just below 0xe0000000, or wherever lkms were last loaded.

3) nudge folks who can do the above to do it. If you have $$, you probably
could hire Wasabi to do it. Yes, that might be one to ten kilobucks (I
don't know their rates), but it would just happen. :-) Otherwise, ask
toolchain folks what to do, and try playing with changes. :-)

Take care,

Bill