Different compiler causes the kernel build to behave differently about kpatch HOT 5 CLOSED

Well, the .meminfo.o.cmd file is not the cause.

After updated gcc from gcc-4.8.2-1.fc20.x86_64 to gcc-4.8.2-7.fc20.x86_64, I could got the right address of meminfo_proc_show.
(I installed the minimized environment, so the affected packages are: gcc, libgcc, libgomp, cpp.)
And I tried to downgrade it, then the wrong address came back.

So that, this fact could tell us:
either different compilers could generate different address of meminfo_proc_show, because some compiling optimization improvement.
or there is a bug on gcc-4.8.2-1.fc20.x86_64.
I prefer to the former conclusion. (why? I don't know, just guess.)

One question could be asked: should we build the vmlinux using the same version of gcc by which the running kernel builds?

from kpatch.

should we build the vmlinux using the same version of gcc by which the running kernel builds?

Yes, I think we should.

from kpatch.

I think we could check /proc/version and gcc -v to decide whether building kpatch-xxx.ko for running kernel in kpatch-build.
The second choice is checking the changed function address against running kernel, if consistent, then building kpatch-xxx.ko.

from kpatch.

Another option would be to compare the System.map of our unpatched kernel with the System.map or kallsyms of the running kernel to ensure all the addresses match up.

But the only problem is that we have the --sourcedir option which allows the user to build patch modules against other kernels. In that case I guess we would need to add another cmdline option to find the System.map to compare against.

We are planning on adding some additional runtime checks to ensure that the kernel matches our expectations at module loading time. So adding them at build time might not be necessary.

from kpatch.

I think this is no longer an issue, since #209 added the verification of the addresses of all patched functions and non-exported relocations when loading the module.

from kpatch.