On 26.11.2025 14:51, Andrew Cooper wrote: > On 26/11/2025 1:24 pm, Jan Beulich wrote: >> diff --git a/xen/arch/x86/arch.mk b/xen/arch/x86/arch.mk >> index 16368a498bb7..a0ee050c931b 100644 >> --- a/xen/arch/x86/arch.mk >> +++ b/xen/arch/x86/arch.mk >> @@ -3,6 +3,8 @@ >> >> export XEN_IMG_OFFSET := 0x200000 >> >> +ALL_LIBS-y += arch/x86/lib/lib.a >> + > > Oh, I'd realised it was this easy, I'd have done so straight away when > adding x86's custom arch_generic_hweightl(). > > I assumed it was going to be more complicated getting the order of the > arch specific lib correct with the generic lib. > > More concretely. Given an x86 lib, we should move things like > arch/x86/memcpy.S to it. > > Therefore, when we have common/lib.a and arch/lib.a, do we guarantee to > have arch/lib.a with higher precedence so for matching functions the > arch specific one guarantees to be taken?
Not with the change above, it would need to become ALL_LIBS-y := arch/x86/lib/lib.a $(ALL_LIBS-y) to achieve that, requiring that ALL_LIBS-y won't change into a lazy-expansion variable. If that's okay (please confirm), I can adjust the patch. Things would be yet easier if every arch had a lib/lib.a, as then in xen/Makefile we could simply have ALL_LIBS-y := arch/$(SRCARCH)/lib/lib.a ALL_LIBS-y += lib/lib.a Alternatively we could move the setting of ALL_LIBS-y in xen/Makefile to after the arch/$(SRCARCH)/arch.mk inclusion. I'd be a little wary of that, though, as it would then be different from ALL_OBJS-y. Jan
