On Sun, 13 Aug 2000, gabriel rosenkoetter wrote:

> I went with a suggestion from the middle of last week, and added
> header files for the misc module to add __attribute__ ((longcall)) to
> the end of each prototype that was outside of the lkm's source (a
> kernel printf(), memcpy() from string.h, and a few lkm...() functions
> from sys/lkm.h). While some of the relocation problems went away, they
> did not *all* go away. Specifically, the references to memcpy() (or,
> seemingly, anything else in string.h--I tried strcpy() and a few
> others) ignore the __attribute__.

That's probably because memcpy() is a built-in in gcc.

> Here's an attempted make load from my modified source:
> 
> achemar:misc/module# make load
> modload -o miscmod -emiscmod combined.o
> combined.o: In function `miscmod_handle':
> combined.o(.text+0x114): relocation truncated to fit: R_PPC_REL24 memcpy
> combined.o(.text+0x140): relocation truncated to fit: R_PPC_REL24 memcpy
> combined.o(.text+0x1f8): relocation truncated to fit: R_PPC_REL24 memcpy
> modload: can't link `combined.o' creating `miscmod' bound to 0xe9212000
> *** Error code 1
> 
> Stop.
> 
> Judging by the preprocessor output (attachment 2 to this email) from the
> compilation of miscmod.c (which contains the offending miscmod_handle
> function), my modified prototype for memcpy() *should* be active, since
> it is included after the one from string.h and not overridden by
> anything later in the file before use of the function.

If it weren't a built-in, I think you'd be right. I think built-in's are a
little different, and I don't know what's up here.

[snip]

> What's going on here? Why is the change to the prototype not having
> effect? Does memcpy() simply ignore __attribute__s? If so, how? Is
> this actually cc's (therefore gcc/egcs's) fault?

I think it's gcc's fault. :-0

> In my opinion, this is a problem that should be fixed by individual
> LKM authors *not* by adding massive #ifdef's to every kernel function.
> That approach horrendously complicates the system source for the
> pleasure of a minority in number of ports and number of users. [snip]

I agree. :-)

> Hiding the -mlong-call (which doesn't work in the cc we're currently
> using right now, remember) withing -D_LKM somehow will just lead to
> people forgetting it's even necessary to do __attribute__
> ((shortcall)) (which they can't anyhow with the cc we've got), and
> make their code inexplicably slow.

I don't think that not using short-call will make the calls inexplicably
slow, it will just make the calls slower than they might be. :-)

> As an example to David Gatwood (at least, I think it was you that
> asked this question, David), LKMs need to have access to all the
> kernel functions because they may be rewriting functionality of the
> kernel (in preparation for a kernel modification, perhaps). In my
> case, this means changing the UVM structure such that the RAM of
> another computer in a cluster can be used as backing store in place
> of disk. I need access to considerably more than printf(), memcpy(),
> and extraneous other functions (specifically, I want to rewrite
> uvm_page(), pgo_get(), and related functions from sys/uvm).

I'm not sure, but I think what you want to do is add a new kind of swap
ability. I'm not sure how easy it is to add one, but your project
certainly argues for the ability. I'm not sufficiently familiar with the
uvm code to say.

Also, I think that it's hard to change existing kernel routines. The
linking process, as I understand it, will modify unresolved symbols in
your lkm to point to the in-kernel ones. But it will not modify existing
kernel references to other kernel functions (like existing calls to
uvm_page()) to point out to your lkm code.

Take care,

Bill