On Fri, Mar 16, 2001 at 09:45:38AM -0800, Bill Studenmund wrote:
> 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.

That's not exactly true. gcc *does* know how to emit the long
variety of jump on powerpc, and does so if you include __attribute__
((longcall)) at the end of a function's prototype. It just doesn't
understand the -mlong-calls command line option on powerpc.

That is, in miscmod.c I've got:

  extern void   *memcpy __P((void *, const void *, size_t)) LKMATTR;

... and two versions of miscmod.h, one, which I'll call the long
version, with:

#define LKMATTR __attribute__((longcall))

... and the other, which I'll call the short version, with:

#define LKMATTR 

So, I do cc -S -D_LKM -D_KERNEL -I/sys -c miscmod.c first with the
long version (and move the .s file somewhere safe) and then with the
short version. The files are definitely different in plenty of
places, but one chunk of the unified diff is sufficiently illustrative:

--- miscmod.s.long  Fri Mar 16 13:04:05 2001
+++ miscmod.s Fri Mar 16 13:05:00 2001
[...]
@@ -59,10 +57,7 @@
  b .L40
 .L31:
  lwz 3,8(31)
- addis 9,0,lkmexists@ha
- addi 29,9,lkmexists@l
- mtlr 29
- blrl
+ bl lkmexists
  mr 0,3
  cmpwi 0,0,0
  bc 12,2,.L32
[...]

So gcc on powerpc can definitely emit long jumps (the addis, addi,
mtlr, blrl lines).

(Oh, and long jumps actually take four instructions, not three, but
that's a minor point. And they might take even more if you have to
do some register preservation before the jump, though I don't see a
handy instance of that in my assembly output.)

This may seem like picking nits, but the point is that all we're
missing is some command line framework which I am ready, willing,
and probably able to dig out of the extant patch, but only if
there's some compelling reason to not commit the extant patch in its
entirety.

> 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.

... which the LKMATTR (I'm tired of typing it out) business above fixes.

This does NOT resolve the issue of the gcc builtins for things like
memcpy(), but that's a quasi-separate issue.

> Well, it's a shame you're taking that stand against using a different gcc,
> since the real fix is to fix gcc.

No, no. I'm all for fixing gcc, I just want to have the NetBSD
distributed gcc dtrt as opposed to having to maintain my own copy of
gcc to work on my project (and theoretically have anyone who ever
wants to use LKMs on powerpc archs referred my way, now that I'm all
over mail-index.netbsd.org talking about it ;^>).

> 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. :-)

One of my later messages (in reply to Ignatios Souvatzis) references
the messages you mean, including the one on the gcc mailing list
that contains the patch in question.

Since the gcc folks turned this patch down once, I have a feeling
they will again, so what I'm trying to get clear is:

IF I take the time to dig just the parts needed for LKMs on NetBSD
out of it, is it a reasonable hope that it will end up in the
toolchain? (And if so, what are the chances the FSF folks will take
it, though that's clearly not under the control of anyone here.)

I think I should stop talking about doing that and just do it, so
this'll be my last email on the subject till I have.

> 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. :-)

That's pretty much the response I was looking for anyhow.

> 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.
> :-)

Isn't that space used for other things by the kernel? (Wired VM?
Something like that?) Not that I'm one of the people who knows this
stuff. :^>

Incidentally, I seldom have kernels over about two and a quarter
MBs, but I prune lots of stuff (ahem, USB) out, so...

> 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.

Yeah, and Todd's one of the people I'm hoping to hear a "Yeah, that
sounds good," or "Eek! No! Don't do that!" kind of response from.
But maybe he's on the busy side...

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

That strikes me as a bit over my head. (Dragging pieces of the
existing-but-unused gcc patch into a useable state is not.) Not that
I wouldn't *like* to know how to do this stuff, but I'm actually
working on something else that needs the LKMs, no matter how
(intially) dirty using them may be.

(I'm also of the opinion that dirtily-implemented LKMs aren't that
big a deal, since they oughtn't be something one ships, but rather
a development crutch. Though doing things the right way is always
pleasant.)

> 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. :-)

I'm a college student. I'd have better luck nudging Wasabi to hire
me to do it. Speaking of which, I DO need a job this summer... ;^>

I'll pull the machine where I'm playing with LKMs up to a real
-current (it's, uh, 1.5E now), install the most recent toolchain
gcc, and look at patching it. That shouldn't take long, right?

:^>

Cheers...

       ~ g r @ eclipsed.net