[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Ping: [PATCH v2] build: provide option to disambiguate symbol names
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |