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

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?

Hope that makes sense...

       ~ g r @ eclipsed.net