Re: [Xen-devel] Ping: [PATCH v2] build: provide option to disambiguate symbol names

[Jan Beulich <jbeulich@xxxxxxxx>]

On 28.11.2019 14:54, Ross Lagerwall wrote:
> On 11/28/19 1:49 PM, Jan Beulich wrote:
>> On 28.11.2019 13:15, Sergey Dyasli wrote:
>>> Applying the patch didn't end up well for my test LP (from another thread):
>>>
>>> Perform full initial build with 8 CPU(s)...
>>> Reading special section data
>>> Apply patch and build with 8 CPU(s)...
>>> Unapply patch and build with 8 CPU(s)...
>>> Extracting new and modified ELF sections...
>>> Processing xen/arch/x86/mm/shadow/guest_2.o
>>> Processing xen/arch/x86/mm/shadow/guest_4.o
>>> Processing xen/arch/x86/mm/shadow/guest_3.o
>>> Processing xen/arch/x86/mm/guest_walk_3.o
>>> Processing xen/arch/x86/mm/hap/guest_walk_3level.o
>>> Processing xen/arch/x86/mm/hap/guest_walk_4level.o
>>> Processing xen/arch/x86/mm/hap/guest_walk_2level.o
>>> Processing xen/arch/x86/mm/guest_walk_2.o
>>> Processing xen/arch/x86/mm/guest_walk_4.o
>>> Processing xen/arch/x86/efi/efi/check.o
>>> Processing xen/arch/x86/pv/gpr_switch.o
>>> Processing xen/arch/x86/indirect-thunk.o
>>> Processing xen/arch/x86/boot/head.o
>>> Processing xen/arch/x86/x86_64/kexec_reloc.o
>>> Processing xen/arch/x86/x86_64/compat/entry.o
>>> Processing xen/arch/x86/x86_64/entry.o
>>> Processing xen/arch/x86/hvm/vmx/entry.o
>>> Processing xen/arch/x86/hvm/svm/entry.o
>>> Processing 
>>> xen/arch/x86/mnt/media/git/upstream/xen/xen/mnt/media/git/upstream/xen/xen/.xen.efi.0s.o
>>> Processing 
>>> xen/arch/x86/mnt/media/git/upstream/xen/xen/mnt/media/git/upstream/xen/xen/.xen.efi.0r.o
>>> Processing 
>>> xen/arch/x86/mnt/media/git/upstream/xen/xen/mnt/media/git/upstream/xen/xen/.xen.efi.1s.o
>>> Processing 
>>> xen/arch/x86/mnt/media/git/upstream/xen/xen/mnt/media/git/upstream/xen/xen/.xen.efi.1r.o
>>> ERROR: no functional changes found.
>>>
>>> So this looks like a regression.
>>
>> Thanks for doing the testing. But what am I to conclude from
>> the above? I can't even tell why "no functional changes found"
>> is an error.
>>
> 
> It's due to the way livepatch-build tool interposes on the build to capture
> changed object files for later comparison.  Now that objcopy writes out the
> proper object files rather than gcc (which just writes a temporary one), the
> livepatch-build tool needs some adjustment otherwise it doesn't capture any
> changed files. I'm working on a patch.

For my own education, and just if you have the time: Why would there
be any dependency on which build utility produces the object file?

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel