>On Wed, 26 Dec 2001, der Mouse wrote:
>> I think I actually dislike it on two grounds, (1) the waste of using
>> long jumps everywhere and (2) having to use a PPC-specific compiler
>> option to build the LKM.)
>
>I think the latter we could embed in bsd.kmod.mk if we needed to.
>
>But only the lkm would be needing to worry about long jumps everywhere,
>and from what I understand, gcc will automatically use short jumps within
>a .o, so it's only inter-.o-intra-lkm calls that would be wasteful.
>

Would it be possble to simply have all code in the low 32 Mb of the
virtual address space for the kernel?  This does not "fix" the
problem, but if it could be done, it would certainly get something
working.

If I understand the problem, it's a matter of different code segments
residing "too far apart", and needing a PC offset field that is
too large.  If the low 32Mb could be simply reserved for code, then
things would work, no?  Data addresses are not a problem, right?

Could this be done by kludging the loading of LKMs so that
the text segment were allocated separately, and the "normal" heap
could start at 32M + 1.

This would have the advantage of no changes to the compilers or loader,
and limiting the necessary machinery to the code segment allocation,
the moving of the "normal" heap.  It would also mean that the
total code size would still be limited to 32 Mb, but that's true
today, and I'll bet that the number of cases where it's a problem is
pretty small.

-dgl-