On Wed, 26 Dec 2001, der Mouse wrote:

> > [...fix which uses all long branches in LKMs...]  Don't like it?  Fix
> > it your way yourself. :^>
>
> :-)  (No, I don't really like that way of addressing it, but I also
> recognize the fairness of the person doing the work getting to decide.

I wish others took this approach. :-)

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

> > (Seriously, what der Mouse suggests is more Right, but figuring out
> > how to make ld check for the condition makes my head hurt, and I'd
> > mostly like something that at least works before getting too
> > ambitious.)

No, ld checks for the condition now. Thus the error message. :-)

> Hm, detecting it would, I'd think, be the easy part: it'd be exactly
> when the offset computed for the relocation overflows the field
> available for it - something I'd expect ld to check already.  What *I*
> would expect the hard part to be is consing up the stubs and arranging
> for them to show up where they need to.  (Perhaps a fake input file
> could be generated...but I'd expect to have some difficulty adding new
> input files to the link after relocation processing starts; it may be
> necessary to collect a list of all the stubs needed, fake up a file
> containing them, and restart the link right from the top.  But this is
> all speculating in a vacuum as far as I'm concerned right now.)

That's what we really need to do. I don't think we'd need to restart the
link, but we would need a seperate (fake) .o.

We need to do this anyway, as if you compile a program which is over 32 MB
big, you can run into this yourself.

Take care,

Bill