On Fri, Mar 16, 2001 at 10:17:35AM +0100, Ignatios Souvatzis wrote:
> teach the compiler a switch to always create long jumps/calls/loads, 
> and teach the LKM Makefiles to set it when on ppc.

Ah, and here we have the problem, as a perfectly good gcc patch to
enable long calls on PowerPC architectures exists (by Mike Stump
of WindRiver/VxWorks), but has previously been rejected from
inclusion in gcc. The hearsay I was given was that it "tried to
do too much".[1]

Is it necessary to separate out just the bits of that patch we
actually want (implementing the -mlong_calls flag on powerpc for
gcc, preferably allowing __attribute__ ((shortcall)) so that
prototypes used entirely internally in the LKM can be tagged with it
so as not to waste 3 or more instructions where one would have been
sufficient)? If so, can it be committed to a NetBSD-maintained
version of gcc (say, in the toolchain), or will it have to go
through gcc channels?

I'm none too big on maintaining my own, private version of gcc,
nor in supporting everyone else who wants to use LKMs under NetBSD
on PowerPC architectures. (This is really something that ought just
work, not something that developers ought to have to wrangle with
just to get around to developing.)

Oh, and I'm presuming the "right" way to make LKMs tick for powerpc-
based ports goes something like this:

1) Have -mlong_calls and __attribute__ ((shortcall)) (or something
with similar function) in the gcc you're using.

2) Tag all your internal-use-only function prototypes with
__attribute__ ((shortcall)).

3) Build your LKM with -mlong_calls in CFLAGS in the Makefile.

This puts the onus of accounting for the weirdness of long/short
calls on the PowerPC on the LKM author. That is, LKM whose author
doesn't write it with these things (presumably wrapped in a #ifdef
__powerpc__) will (still) be broken for all the powerpc ports.

It would maybe be nice if this were not the case, but since LKMs
exist under NetBSD with the theory that they ought be used as a
development aid NOT for released software (a principle I agree with,
seeing how hairy using them can get), I don't think it's really that
big a deal.

For the background of this discussion, you'll want to have a look
at [2].

Is this the approach tech-kern thinks appropriate? If so, I'll see
if I can get a gcc that will properly link LKMs on my powerpc box
and submit patches to the appropriate place (presuming someone can
tell me where that is), but I need to know that the method will
even be accepted before I give up a few days of class work to do
it.

> Yes. Stop complaining, instead start coding *know*.
> I guess you're aware this is a volunteer project?

That was, of course, what I was implying by the "What can I do..."
rephrasing. I've included tech-kern so that I can do this the right
way, not because I want it done for me. Sorry if that was unclear.
I'm glad to see the good ol' BSD Way of welcoming interested
developers, btw. Perhaps we can quit throwing around how much better
than thou we all are and get back to work?

(I contemplated editing that out, but I think my signal to noise
ratio is sufficient to justify leaving it in. If you disagree,
perhaps you could do everyone else the service of replying
PRIVATELY?)

Incidentally, powerpc is not the only architecture for which LKMs
are broken in NetBSD[3], it just happens to be the one of which
I've many instances. Other ports do need changes to the LKM structure
in order for LKMs to work there, and they also ought to be fixed.
(So, having some place to store architecture-dependent LKM compile
flags would make me pretty happy, but I'm a little hazy on where
that belongs... bsd.kmod.mk? Is that port-specific or -indenpendant?)

       ~ g r @ eclipsed.net

[1] See: http://gcc.gnu.org/ml/gcc/2000-07/msg00141.html for the
patch and:
http://mail-index.netbsd.org/port-macppc/2000/08/03/0012.html
http://mail-index.netbsd.org/port-macppc/2000/08/04/0000.html
for the prior discussion on port-macppc.

[2] For simply redefining the prototype of in-kernel functions
called by the LKM to add __attribute__ ((longcall)) and its almost
working, see:
http://mail-index.netbsd.org/port-macppc/2000/08/02/0021.html
http://mail-index.netbsd.org/port-macppc/2000/08/02/0025.html
http://mail-index.netbsd.org/port-macppc/2000/08/02/0026.html

For the (IMHO, better) approach of using a -mlong_calls flag on gcc
and definite __attribute ((shortcall)) for functions we're sure the
LKM will only call internally, see:
http://mail-index.netbsd.org/port-macppc/2000/08/07/0012.html
http://mail-index.netbsd.org/port-macppc/2000/08/07/0016.html

[3] http://mail-index.netbsd.org/port-macppc/2000/08/03/0000.html