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@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
---
xen/Rules.mk | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/xen/Rules.mk b/xen/Rules.mk
index 2b28d1ac3c..2c3f836c1b 100644
--- 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))
ifeq ($(CONFIG_CC_IS_CLANG),y)
cov-cflags-$(CONFIG_COVERAGE) := -fprofile-instr-generate -fcoverage-mapping
@@ -146,7 +146,7 @@ endif
$(call cc-option-add,cov-cflags-$(CONFIG_COVERAGE),CC,-fprofile-update=atomic)
# Reset cov-cflags-y in cases where an objects has another one as prerequisite
-$(nocov-y) $(filter %.init.o, $(obj-y) $(obj-bin-y) $(extra-y)): \
+$(nocov-y) $(filter %.init.o, $(obj-y) $(obj-bin-y) $(extra-y) $(lib-y)): \
cov-cflags-y :=
$(non-init-objects): _c_flags += $(cov-cflags-y)
@@ -156,7 +156,7 @@ ifeq ($(CONFIG_UBSAN),y)
UBSAN_FLAGS := $(filter-out -fno-%,$(CFLAGS_UBSAN)) $(filter -fno-%,$(CFLAGS_UBSAN))
# Reset UBSAN_FLAGS in cases where an objects has another one as prerequisite
-$(noubsan-y) $(filter %.init.o, $(obj-y) $(obj-bin-y) $(extra-y)): \
+$(noubsan-y) $(filter %.init.o, $(obj-y) $(obj-bin-y) $(extra-y) $(lib-y)): \
UBSAN_FLAGS :=
$(non-init-objects): _c_flags += $(UBSAN_FLAGS)
@@ -273,7 +273,7 @@ define cmd_obj_init_o
$(OBJCOPY) $(foreach s,$(SPECIAL_DATA_SECTIONS),--rename-section .$(s)=.init.$(s)) $< $@
endef
-$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): $(obj)/%.init.o: $(obj)/%.o FORCE
+$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y) $(lib-y)): $(obj)/%.init.o: $(obj)/%.o FORCE
$(call if_changed,obj_init_o)
quiet_cmd_cpp_i_c = CPP $@
--
2.43.0On 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@amd.com> > Reviewed-by: Jan Beulich <jbeulich@suse.com> 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. Nothing in the logs though. Jan
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@amd.com> >> Reviewed-by: Jan Beulich <jbeulich@suse.com> > > 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 ... >> --- 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
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@amd.com> >>> Reviewed-by: Jan Beulich <jbeulich@suse.com> >> >> 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
On 23.01.2026 11:56, Orzel, Michal wrote: > 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@amd.com> >>>> Reviewed-by: Jan Beulich <jbeulich@suse.com> >>> >>> 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. And division by 0 is otherwise benign on Arm64? (On x86 it raises an exception and hence would be a problem also without UBSAN.) Jan > (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
On 23/01/2026 12:37, Jan Beulich wrote: > On 23.01.2026 11:56, Orzel, Michal wrote: >> 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@amd.com> >>>>> Reviewed-by: Jan Beulich <jbeulich@suse.com> >>>> >>>> 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. > > And division by 0 is otherwise benign on Arm64? (On x86 it raises an exception > and hence would be a problem also without UBSAN.) From the ARM ARM spec: "A division by zero results in a zero being written to the destination register, without any indication that the division by zero occurred." ~Michal
On Thu Jan 22, 2026 at 11:01 AM CET, 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@amd.com> >>> Reviewed-by: Jan Beulich <jbeulich@suse.com> >> >> 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 ... > >>> --- 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. Apologies for the unintended breakage. I should've checked the baseline for arm before ruling out this patch being the cause (it did fire in my pipeline, but didn't consider how this could affect arm and attributed it to a spurious failure). So we're neither doing UBSAN nor collecting coverage data from libs? Great. One more task to the pile, I guess. Seeing how... $(non-init-objects): _c_flags += $(cov-cflags-y) [snip] $(non-init-objects): _c_flags += $(UBSAN_FLAGS) I'll try to clean this mess. :/ Cheers, Alejandro
On 22.01.2026 12:02, Alejandro Vallejo wrote: > On Thu Jan 22, 2026 at 11:01 AM CET, 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@amd.com> >>>> Reviewed-by: Jan Beulich <jbeulich@suse.com> >>> >>> 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 ... >> >>>> --- 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. > > Apologies for the unintended breakage. I should've checked the baseline for > arm before ruling out this patch being the cause (it did fire in my pipeline, > but didn't consider how this could affect arm and attributed it to a spurious > failure). > > So we're neither doing UBSAN nor collecting coverage data from libs? Great. One > more task to the pile, I guess. Seeing how... > > $(non-init-objects): _c_flags += $(cov-cflags-y) > [snip] > $(non-init-objects): _c_flags += $(UBSAN_FLAGS) > > I'll try to clean this mess. :/ In the meantime, should I give your patch another try with that one change dropped? Jan
On Thu Jan 22, 2026 at 12:04 PM CET, Jan Beulich wrote: > On 22.01.2026 12:02, Alejandro Vallejo wrote: >> On Thu Jan 22, 2026 at 11:01 AM CET, 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@amd.com> >>>>> Reviewed-by: Jan Beulich <jbeulich@suse.com> >>>> >>>> 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 ... >>> >>>>> --- 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. >> >> Apologies for the unintended breakage. I should've checked the baseline for >> arm before ruling out this patch being the cause (it did fire in my pipeline, >> but didn't consider how this could affect arm and attributed it to a spurious >> failure). >> >> So we're neither doing UBSAN nor collecting coverage data from libs? Great. One >> more task to the pile, I guess. Seeing how... >> >> $(non-init-objects): _c_flags += $(cov-cflags-y) >> [snip] >> $(non-init-objects): _c_flags += $(UBSAN_FLAGS) >> >> I'll try to clean this mess. :/ > > In the meantime, should I give your patch another try with that one change dropped? > > Jan Sure, thanks. Cheers, Alejandro
© 2016 - 2026 Red Hat, Inc.