On Fri, 16 Mar 2001, der Mouse wrote:

> The problem is that the LKM can't call routines in kernel text unless
> either (a) the LKM code containing the call is within 32MB (26 bits) of
> the called routine or (b) the LKM code uses the four-instruction long
> call sequence.

Tiny nit. There are only 24 bits for the jump. But the design recognizes
that all valid opcode addresses are divisable by four (lower two bits
zero), so '00' gets tacked onto the end of the 24-bit number. :-)

> Since kernel text is in low memory (it's mapped with VA==PA), this
> means putting the LKM there too.  Which, since it's mapped with a BAT
> rather than a segment, means finding physically contiguous memory
> within 32MB of kernel text (which is currently Hard) or persuading the
> code to do long calls (which is where gcc comes into it).  (Or, I
> suppose, moving kernel text, which would be
> (*cdevsw[major(worm_can->wc_dev)].d_open)(worm_can).)
> 
> Personally, I'm inclined to favor the linker hack that was recently
> mentioned; it seems to me that it would be useful when someone builds a
> program with >32MB of text segment anyway, and would break only when a
> single .o file's text, plus any necessary stubs, exceeds 64MB.  It
> would also completely sidestep the issue of having to decide which
> calls to declare longcall and which shortcall, since the decision would
> be made late enough to know which ones actually *need* longcall.

The linker change would be good in general, but I don't think anyone with
sufficient linker foo has volinteered to do it. :-) I think the gcc change
would be enough for now.

Take care,

Bill