inlines_and_relocations.txt

It seems that there is some issue with inlines and writing kernel modules in C++.

Here is what we have came up with on the matter so far:

When gcc and the linker find inline functions which are "big" (we do not know what that means exactly)
then suddenly the link process in the kernel starts issueing "Unknown relocation: 0" error
when trying to load the resulting module.

If you really want to see the relations in a module you should use:
objdump -r [object file or .ko file]

Relocations come in 3 flavours:
RX
RX 386
and
NONE

Here is an example:
objdump -r obj/modules/KFcb.ko  | c++filt | grep NONE
000009d8 R_386_NONE        *ABS*
000009ec R_386_NONE        *ABS*
00002b08 R_386_NONE        *ABS*
00002b1c R_386_NONE        *ABS*
00003698 R_386_NONE        *ABS*
.... more here ....

The linux kernel knows how to handle only the first two ones. The user space dynamic linker
probably knows how to handle all of them.

We really don't know how to stop the compiler from doing whatever it is doing (we don't know if there is some magical --dont-do-relocation-shit flag to stop it). This needs to be ivestigated.

*We did* prove that moving functions from being inline to non inline makes the problem go away.

Addition (31 oct 09):
=====================
I have made an attempt to compile using -fpic/-fPIC to make the problem go away.
It didn't. The error is:
[28373.931835] KFcb: Unknown symbol _GLOBAL_OFFSET_TABLE_
It seems that -fPIC relies on the dynamic linker to provide this symbol and the kernel
dynamic linker does not supply this service.
I have made other efforts to make it go away (-mcmodel which does not apply - doens't work).

SUCCESS!!! I have managed to make it go away by adding "-fno-exceptions".
It seems that the compiler was generating exception handling code even though the code had nothing to
do with exceptions.


							Mark Veltzer