On Tue, 16 Apr 2019, Joe Lawrence wrote: > 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 Another great catch. > 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? No, unfortunately we don't. At least I don't know about anything and a quick test on openSUSE Leap 15.0 confirms it (objdump -D gives "bad value"). Thanks Miroslav
