Re: [PATCH v3 0/9] klp-convert livepatch build tooling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux&nblp;USB Development]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite Secrets]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux