Re: [PATCH v5 1/2] xen: Allow lib-y targets to also be .init.o

["Orzel, Michal" <michal.orzel@xxxxxxx>]

On 22/01/2026 11:01, Jan Beulich wrote:
> On 22.01.2026 10:49, Jan Beulich wrote:
>> On 21.01.2026 16:47, Alejandro Vallejo wrote:
>>> There's some assumptions as to which targets may be init-only. But
>>> there's little reason to preclude libraries from being init-only.
>>>
>>> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@xxxxxxx>
>>> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
>>
>> I can't tell (yet) what it is, but as per CI something's clearly wrong with 
>> this
>> change. Both xilinx-smoke-dom0less-arm64-* and qemu-smoke-dom0*-debug* fail 
>> with
>> it in place. qemu-smoke-dom0-arm64-gcc (no "debug") was fine, suggesting it 
>> may
>> be an early assertion triggering.
> 
> Or an early UBSAN failure. I think ...
I did a test and it looks like the problem is division by zero in
generic_muldiv64. At this point, time is not yet initialized on Arm, so cpu_khz
is 0 in ticks_to_ns.

(XEN) [000000005019d0ee] UBSAN: Undefined behaviour in lib/muldiv64.c:23:21
(XEN) [00000000501cfc11] division by zero
(XEN) [0000000050211d11] Xen WARN at common/ubsan/ubsan.c:176
(XEN) [000000005023b3ec] ----[ Xen-4.22-unstable  arm64  debug=y ubsan=y  Not
tainted ]----
(XEN) [0000000050afc964] Xen call trace:
(XEN) [0000000050b0e4ec]    [<00000a000032ab44>]
ubsan.c#ubsan_epilogue+0x14/0xec (PC)
(XEN) [0000000050b2f1c1]    [<00000a000032b35c>]
__ubsan_handle_divrem_overflow+0x114/0x1e4 (LR)
(XEN) [0000000050b577dd]    [<00000a000032b35c>]
__ubsan_handle_divrem_overflow+0x114/0x1e4
(XEN) [0000000050b790fb]    [<00000a00003eb9d0>] generic_muldiv64+0x7c/0xbc
(XEN) [0000000050b94539]    [<00000a00003bfb9c>] ticks_to_ns+0x24/0x2c
(XEN) [0000000050bad89d]    [<00000a00003bfc04>] get_s_time+0x34/0x54
(XEN) [0000000050bc731b]    [<00000a000032dec8>]
console.c#printk_start_of_line+0x2bc/0x374
(XEN) [0000000050be7987]    [<00000a000032ef3c>]
console.c#vprintk_common+0x454/0x484
(XEN) [0000000050c06033]    [<00000a000032ef94>] vprintk+0x28/0x30
(XEN) [0000000050c1e4df]    [<00000a000032eff8>] printk+0x5c/0x64
(XEN) [0000000050c3904b]    [<00000a00005548f8>] end_boot_allocator+0x31c/0x548
(XEN) [0000000050c55a86]    [<00000a0000585c58>] start_xen+0x150/0xe68
(XEN) [0000000050c70232]    [<00000a00002001a4>] 
head.o#primary_switched+0x4/0x24
(XEN) [0000000050c8d2bf]

~Michal

> 
>>> --- a/xen/Rules.mk
>>> +++ b/xen/Rules.mk
>>> @@ -130,9 +130,9 @@ endif
>>>  
>>>  targets += $(targets-for-builtin)
>>>  
>>> -$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS-y += 
>>> -DINIT_SECTIONS_ONLY
>>> +$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y) $(lib-y)): CFLAGS-y += 
>>> -DINIT_SECTIONS_ONLY
>>>  
>>> -non-init-objects = $(filter-out %.init.o, $(obj-y) $(obj-bin-y) $(extra-y))
>>> +non-init-objects = $(filter-out %.init.o, $(obj-y) $(obj-bin-y) $(extra-y) 
>>> $(lib-y))
> 
> ... this is the problem: You're _adding_ library files here which weren't 
> there
> before. Why $(lib-y) isn't here I don't really known, but as per the CI 
> results
> there must be a reason for this.
> 
> Jan