-
Notifications
You must be signed in to change notification settings - Fork 305
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
link-vmlinux-syms doesn't handle symbol collisions properly #54
Comments
This issue is actually hard to resolve. create-diff-object changes unchanged LOCAL symbols to GLOBAL symbols with section index UNDEF so that they can be linked to the version in vmlinux. However, this introduces the chance that the local symbol name collides with an existing global symbol in the kernel and we can't determine, from link-vmlinux-syms point of view, which symbol was being referenced since it has no FILE context as LOCAL symbols do. In the meantime, commit 2be6178 checks for this ambiguity and errors out of the situation above is ever encountered. |
I attempted to recreate this issue, but strangely got another problem. I used the following patch:
I expected an error, but instead it succeeded, and strangely pages_to_scan_show doesn't show up in the symbol table. |
Looking at the rela table for pages_to_scan_store with the patch applied:
Looks like the compiler is inlining pages_to_scan_show. |
And the patch does work :)
|
Blasted compiler. |
/me wonders how to get gcc to not inline an otherwise not inlined function. |
I'm playing around with using -fno-inline, in addition to -f[function|data]-sections in the KCFLAGS for building the diff objects. |
This issue is as fixed as it can be right now, see commit 2be6178 |
This may be lower priority, but let's leave it open since it helps us keep track of a real issue that will need to be fixed at some point. I'm not sure that changing unchanged LOCAL symbols to GLOBAL undef symbols in create-diff-object is the best approach. |
With the addition of dynrela support, link-vmlinux-syms doesn't exist anymore and the issue has disappeared because we no longer do the change-symbol-binding trick for pinning addresses into the symbol table. |
Same problem as #53 only with link-vmlinux-syms when pinning addresses into the symbol table of the kernel module.
The text was updated successfully, but these errors were encountered: