support for calling a new function in another object#390
Merged
sjenning merged 1 commit intodynup:masterfrom Sep 2, 2014
Merged
support for calling a new function in another object#390sjenning merged 1 commit intodynup:masterfrom
sjenning merged 1 commit intodynup:masterfrom
Conversation
If a patch adds a new function in foo.c, and calls that function from
bar.c, currently it fails with something like:
kpatch_create_dynamic_rela_sections: 2115: lookup_global_symbol failed for tpe_allow_file, needed for .text.do_mmap_pgoff
This (crudely) fixes the issue by assuming that if we can't find the
global symbol in the original vmlinux, that it will be provided by
another object in the patch module. If that assumption is incorrect,
the module will fail to load due to the missing symbol dependency.
A (perhaps) better way to fix this is to search for the symbol in the
patched version of the vmlinux. But I think this approach is good
enough, for now at least.
Fixes dynup#388.
Member
Author
|
@cormander I think this should fix issue #388. |
Contributor
There was a problem hiding this comment.
think we should output some sort of warning at least that says "symbol x lookup failed, assuming object is provided by patch" or something like that?
Member
Author
There was a problem hiding this comment.
I'm inclined to say we don't need a warning, because my feeling is that 90% of the time, the symbol will be defined elsewhere in the patch module, and a warning would be inappropriate and confusing.
The other 10% of the time (or maybe less? I'm not even sure what could legitimately cause this error...) the module would fail to load and the printk message would state which symbol is missing.
sjenning
added a commit
that referenced
this pull request
Sep 2, 2014
support for calling a new function in another object
Contributor
|
Confirmed, this fixes it. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
If a patch adds a new function in foo.c, and calls that function from
bar.c, currently it fails with something like:
This (crudely) fixes the issue by assuming that if we can't find the
global symbol in the original vmlinux, that it will be provided by
another object in the patch module. If that assumption is incorrect,
the module will fail to load due to the missing symbol dependency.
A (perhaps) better way to fix this is to search for the symbol in the
patched version of the vmlinux. But I think this approach is good
enough, for now at least.
Fixes #388.