more notes

Author: veltzer

inlines_and_relocations.txt

@@ -0,0 +1,48 @@
+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