On Fri, Mar 16, 2001 at 03:13:53PM +0100, Ignatios Souvatzis wrote:
> > 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)?

Assuming the below is a response just to that question, what about
this?

-mlong-calls is one thing, but I don't *think* the gcc we're using
even has a shortcall attribute. I wish I knew the piece of
documentation from which to find that out, but, fwiw, changing my
code to use __attribute ((shortcall)) where it had use longcall
(blatantly wrong, but whatever), I get:

cc -D_LKM -D_KERNEL -I/sys  -c miscmod.c
miscmod.c: In function `miscmod_handle':
miscmod.c:95: warning: `shortcall' attribute directive ignored

... which makes me think that shortcall doesn't actually exist. But
I could be completely wrong, as always. :^>

(The original behemoth patch from the gcc mailing list even
automatically generated shortcalls when referencing the something in
the same code block under -mlong-call... but this seems to be part
of the excessiveness that led to it's not being commited to gcc. Go
figure.)

> > 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?
> Well, I'm not our toolchain maintainer... but I guess, both at the same 
> time.

Sounds good.

> Well, it is perfectly reasonable to require something like -mlong_calls 
> for powerpc, and I guess we can even provide makefile templates or
> something similar to that that.

Perhaps even in the /usr/share/lkm examples, from which I'm working?

:^>

> As for the __attribute__((shortcall)):
> 
> Thats just an optimization. IMO, this should be pointed out to the 
> knowledgable developer in some documentation, but is not really
> necessary. When in doubt, not using it is fine (and on the secure
> side; you know, an LKM *might* be > 64MB in size itself, although
> this is unlikely :-)

None too sure I'd want to sit around while it loaded either... ;^>

Again, probably belongs in a comment or a README somewhere in
/usr/share/lkm.

> Please forgive the harsh tone; I didn't detect the "real offer" part in
> your original mail.

No trouble. Forgive the tone of my response.

(I got a little weary of saying, "I will do this, tell me where to
start," in the original fracas over this. ;^>)

       ~ g r @ eclipsed.net