Okay, I lied... THIS will be my last email. ;^>

On Fri, Mar 16, 2001 at 01:42:34PM -0500, Greg Kritsch wrote:
> I'm going to reiterate my point of view for fun, mainly because it doesn't
> involve changing the compiler, just all the .h files from the kernel.

Which I still think might work more logically but bloats the kernel
source hideously.

> This would fix the problem for all architectures that have LKM trouble due
> to limited branch range.

... assuming we even know which ones those are, and we define
LKMCALL appropriately for each with #ifdefs, but yes, true.

> Now, someone has reported a problem with compiler builtin functions.  I
> haven't looked into that problem, so maybe some additional fixing is
> required there.

It has been theorized that having a -mlong-call will make that
magically work. I'm not buying it yet, but I'm willing to find out
the real way.

> The second best solution, in my opinion, hasn't been expressed yet.  What if
> some piece of code, say the linker, took any branch target that was too far
> away and changed it to a branch to a little stub of code that does a long
> call?  Perhaps this could even be integrated with the module loading tool
> rather than the linker, for now.

That was mentioned (and largely passed over) in the original
discussion over on port-macppc as being what AIX does to solve this
problem. I happen to agree that it'd be a better way to do it, but
since we use Gnu's ld too (right?) it also requires submitting
changes to FSF and doesn't seem to be the way they'd like to do
this (judging by the fact that they've made similar changes for
processors with crippled far calling setups within gcc as opposed
to within ld).

That says nothing about which way is better, just which has prior
art behind it.

> I know NetBSD is all about machine independance and portability, but I
> believe in efficiency as well.  This approach prevents us from having to
> deal with using inefficient long calls all over the place unless we
> explicitly ask the compiler not to use them (the shortcall attribute).  But
> all the .h files do need to change.

The part of this that you're still not quite catching (and it's
never been expressed very clearly) is that the patch we all keep
talking about to include a -mlong-call option to gcc intelligently
decides when it should ACTUALLY emit a short call, and does so. (It
decides this, as near as I can tell, by seeing if the referenced
function is implemented in the same compiled block as the call,
which sounds like it will always dtrt with an LKM.)

> Option 3: have the module loader change the relative branch instructions to
> absolute branch instructions, in place, since the entire kernel is reachable
> by an absolute branch instruction.  This would be nicely efficient, too.

Ooooo... I really like that.

It is again, however, over my head. And does modload actually have
the ability to do this, considering it's effectively just a couple
of system() calls to ld?

> Again, just throwing out ideas.

They're appreciated.

       ~ g r @ eclipsed.net