> -----Original Message-----
> From: gabriel rosenkoetter [mailto:gr@eclipsed.net]
> Sent: Thursday, August 03, 2000 4:34 AM
> To: Todd Whitesel
> Cc: ws@tools.de; dje@watson.ibm.com; root@ihack.net; greg@evertz.com;
> port-macppc@netbsd.org
> Subject: Re: Do LKMs work *at*all* on powerpc platforms?
> 
> 
> On Thu, Aug 03, 2000 at 01:19:39AM -0700, Todd Whitesel wrote:
> > > Would compiling LKMs with this flag really fix all the 
> problems, or
> > > will there still be the same trouble with the memcpy 
> called by the lkm
> > > function that gets passed to load() not using the 
> modified prototype?
> > The attribute only affects calls to that subroutine, it 
> does not modify the
> > entry/exit code of the subroutine itself -- so yes, that 
> flag (or attribute)
> > would deal with this.
> 
> Hrm. I think you misunderstood my question, but I'm not sure I can
> muster the technical terms to make it make sense right now.
> 
> When I add __attribute__ ((longcall)) to the prototypes of memcpy()
> and (the kernel) printf() in a header file for miscmod and misccall,
> all of the complaints from the linker disappear... except for one.
> 
> This one is about a call to memcpy() in miscmod_handle(), and it
> arises because miscmod_handle() gets passed (as a function pointer) to
> DISPATCH(), part of the in-kernel LKM framework (it's a macro in
> sys/lkm.h), which performs a load(lkmtp,cmd) where cmd =
> miscmod_handle() (in this case). Because it's the kernel doing the
> loading, we no longer have our modified prototype for memcpy() (or
> whatever else we've used), so we fail. (At least, that's my
> interpretation, and it seems to match up to what actually happens to
> me.)

Compile the code to assembly and see what it is the compiler is actually
generating.  Assuming, of course, that you speak PowerPC assembly...

> Will using the compiler flag *just* when compiling the source for the
> individual module in question fix this problem, or will the LKM
> architecture within the kernel need to be compiled with that flag as
> well?

There are four kinds of calls going on, LKM to LKM, LKM to kernel, kernel to
LKM, and kernel to kernel.

LKM to LKM and kernel to kernel don't need the attribute, as they are
basically local calls.  Relative branches will be fine, until either the
kernel or your module exceeds 32 MB in size.

kernel to LKM is handled explicitly by pointers, as someone else has already
pointed out.

So you only need to affect LKM to kernel calls, because they are jumping the
space between kernel virtual space (segment E) and the kernel load address
(segment 0).

Compiling ALL THE CODE IN THE module with long calls will solve the problem,
though it will also slow you down a bit on the LKM to LKM calls, but that
shouldn't matter.  What I don't understand right now is where that load()
function is coming from.  Is it part of the kernel, or is it part of some
lkm library?

I'd compile the thing myself to find out, but my system is such a mess right
now (hybrid between 1.4.2, 1.4Z and 1.5_ALPHA), and fixing it is simply not
a priority.  Someone hurry up and release 1.5 so I can do a nice clean
binary install...

> Hope that makes sense...

Not quite, that's why it's bothering me.  It should "just work," I think.

>        ~ g r @ eclipsed.net

Gregory