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

[Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>]

On 11/28/19 1:57 PM, Jan Beulich wrote:
> 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?
> 

It uses CROSS_COMPILE to funnel all build output to a script
(https://xenbits.xen.org/gitweb/?p=livepatch-build-tools.git;a=blob;f=livepatch-gcc)
which then notes changed object files by processing gcc's command-line.

If objcopy is used instead of gcc to produce the final output then the script
processes gcc's command-line but doesn't get the output it expects so no
changes are detected.

Yes, this is hacky -- improvements are welcome!

-- 
Ross Lagerwall

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