Subject: Re: Loading DSP code from an LKM
To: Simon Burge <simonb@wasabisystems.com>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 09/30/2001 04:59:24
On Sun, 30 Sep 2001, Simon Burge wrote:

> der Mouse wrote:
>
> > As I recall, when I heard about this some time ago and looked at it, I
> > determined there was a relatively simple and elegant way to fix it:
> > have the linker, perhaps under control of a suitable option, generate
> > stub long jumps as necessary.  The fixup would occur when the LKM .o
> > file is linked against the kernel; when jumps are too long, ld would
> > then generate a small blob of three or four instructions and point the
> > short jump reloc at that blob; the blob would be the long jump.
> >
> > I don't see anything obviously wrong with this, but since I've never
> > actually tried implementing it, there may prove to be problems I
> > haven't thought of.  I don't recall anyone pointing any out when it was
> > discussed before....
>
> Wouldn't this have problems with local branches within functions,
> like those generated for if/then/else and switch?  All the offsets
> are generated at assembly time, not link time.

No, you don't have to insert these instructions where the one instruction
was before, just within 32 MB of that instruction.

So you add a virtual .o file which only has longjump instruction blobs in
it, point the can't-reach jump's relocations at the blob, and add
relocations for the blob to point at the can't-reach location. If you get
fancy, you can have the one virtual .o work for 32 MB of code. (hmmm.. no,
64 MB of code).

Take care,

Bill