[PATCH] xen/build: pass -fzero-init-padding-bits=all to gcc15

Jan Beulich posted 1 patch 4 months, 2 weeks ago
Failed in applying to current master (apply log)
[PATCH] xen/build: pass -fzero-init-padding-bits=all to gcc15
Posted by Jan Beulich 4 months, 2 weeks ago
See the respective bullet point in the Caveats section of
https://gcc.gnu.org/gcc-15/changes.html.

While I'm unaware of us currently relying on the pre-gcc15 behavior,
let's still play safe and retain what unknowingly we may have been
relying upon.

According to my observations, on x86 generated code changes
- somewhere deep in modify_bars(), presumably from the struct map_data
  initializer in apply_map() (a new MOVQ),
- in vpci_process_pending(), apparently again from the struct map_data
  initializer (and again a new MOVQ),
- near the top of find_cpio_data(), presumably from the struct cpio_data
  initializer (a MOVW changing to a MOVQ).

Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
apply_map() being inlined is kind of against our intentions, seeing that
it's marked __init. Should we add noinline there? After all post-init
this is effectively unreachable code, which Misra opposes to.

--- a/xen/Makefile
+++ b/xen/Makefile
@@ -396,6 +396,7 @@ endif
 CFLAGS-$(CONFIG_CC_SPLIT_SECTIONS) += -ffunction-sections -fdata-sections
 
 CFLAGS += -nostdinc -fno-builtin -fno-common
+$(call cc-option-add,CFLAGS,CC,-fzero-init-padding-bits=all)
 CFLAGS += -Werror -Wredundant-decls -Wwrite-strings -Wno-pointer-arith
 CFLAGS += -Wdeclaration-after-statement -Wuninitialized
 $(call cc-option-add,CFLAGS,CC,-Wvla)
Re: [PATCH] xen/build: pass -fzero-init-padding-bits=all to gcc15
Posted by Andrew Cooper 4 months ago
On 18/06/2025 9:22 am, Jan Beulich wrote:
> See the respective bullet point in the Caveats section of
> https://gcc.gnu.org/gcc-15/changes.html.
>
> While I'm unaware of us currently relying on the pre-gcc15 behavior,
> let's still play safe and retain what unknowingly we may have been
> relying upon.
>
> According to my observations, on x86 generated code changes
> - somewhere deep in modify_bars(), presumably from the struct map_data
>   initializer in apply_map() (a new MOVQ),
> - in vpci_process_pending(), apparently again from the struct map_data
>   initializer (and again a new MOVQ),
> - near the top of find_cpio_data(), presumably from the struct cpio_data
>   initializer (a MOVW changing to a MOVQ).
>
> Requested-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>