Re: [PATCH 1/2] x86: move arch_generic_hweightl() to arch-specific library

[Jan Beulich <jbeulich@xxxxxxxx>]

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