On 4/10/19 11:50 AM, Joe Lawrence wrote:
Hi folks,
This is the third installment of the klp-convert tool for generating and
processing livepatch symbols for livepatch module builds. For those
following along at home, archive links to previous versions:
RFC:
https://lore.kernel.org/lkml/cover.1477578530.git.jpoimboe@xxxxxxxxxx/
v2:
https://lore.kernel.org/lkml/f52d29f7-7d1b-ad3d-050b-a9fa8878faf2@xxxxxxxxxx/
(Note that I don't see v2 archived at lore, but that is a link to the
most recent subthread that lore did catch.)
Livepatches may use symbols which are not contained in its own scope,
and, because of that, may end up compiled with relocations that will
only be resolved during module load. Yet, when the referenced symbols are
not exported, solving this relocation requires information on the object
that holds the symbol (either vmlinux or modules) and its position inside
the object, as an object may contain multiple symbols with the same name.
Providing such information must be done accordingly to what is specified
in Documentation/livepatch/module-elf-format.txt.
Hi Miroslav,
I noticed that some binutils programs like gdb, objdump, etc. don't like
the .ko kernel objects that we're generating from this patchset,
specifically those with the additional '.klp.rela.<obj>..text' livepatch
symbol relocation sections.
For reference, I opened a new bugzilla with more details here:
https://sourceware.org/bugzilla/show_bug.cgi?id=24456
And was about to ping the binutils mailing list about the assertion that
is tripping in bfd/elf.c. The thought occurred to me that you guys
might already be carrying a patch to workaround this issue?
-- Joe
