On Fri, 16 Mar 2001, gabriel rosenkoetter wrote:

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

Ahhh.... gcc is farther along than I remembered.

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

Doh. That's what I get for remembering wrong. It strikes me as really
stupid that there is no branch out of a GP register....

Oh, and register setup doesn't count in my book for this, since it's more
a function of the fact you're jumping, not how you're jumping. :-)

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

I thought that there was something other than -mlong-jump in the patch
which was what didn't sit well with the FSF. My thought is that if we
skipped (or came up with a good reason for) that part, then the changes
in our tree would be more pallitable to the FSF.

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

Yep.

> 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 ;^>).

Ahh... I mis-understood!

> 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 the -mlong-jump part is most appropriate. The only snag I see is
with timing of the binutils update. But that's no reason not to do it.

I have no idea w.r.t. the FSF, and the reason I was babbling about only
doing part of the patch was to make it more palletable to them. ;-)

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

It's certainly _my_ opinion. :-)

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

Yep, it's use for copyin&out.

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

Yeah, he's the person I want to hear from too. :-)

> > 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 don't think we're at the stage of having summer interns, but who
knows. :-)

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

I hope not.

Let me know how it goes...

Take care,

Bill