From: Sascha Hauer <s.hauer@pengutronix.de>
To: barebox@lists.infradead.org, Ahmad Fatoum <a.fatoum@pengutronix.de>
Subject: Re: [PATCH master] kbuild: Use -fzero-init-padding-bits=all
Date: Tue, 29 Apr 2025 17:00:56 +0200 [thread overview]
Message-ID: <174593885657.3116244.17088022716425865208.b4-ty@pengutronix.de> (raw)
In-Reply-To: <20250425133849.2362142-1-a.fatoum@pengutronix.de>
On Fri, 25 Apr 2025 15:38:49 +0200, Ahmad Fatoum wrote:
> This is a port of Linux commit dce4aab8441d285b9a78b33753e0bf583c1320ee:
>
> | Author: Kees Cook <kees@kernel.org>
> | AuthorDate: Mon Jan 27 11:10:28 2025 -0800
> |
> | GCC 15 introduces a regression in "= { 0 }" style initialization of
> | unions that Linux has depended on for eliminating uninitialized variable
> | contents. GCC does not seem likely to fix it[1], instead suggesting[2]
> | that affected projects start using -fzero-init-padding-bits=unions.
> |
> | To avoid future surprises beyond just the current situation with unions,
> | enable -fzero-init-padding-bits=all when available (GCC 15+). This will
> | correctly zero padding bits in unions and structs that might have been
> | left uninitialized, and will make sure there is no immediate regression
> | in union initializations. As seen in the stackinit KUnit selftest union
> | cases, which were passing before, were failing under GCC 15:
> |
> | not ok 18 test_small_start_old_zero
> | ok 29 test_small_start_dynamic_partial # SKIP XFAIL uninit bytes: 63
> | ok 32 test_small_start_assigned_dynamic_partial # SKIP XFAIL uninit bytes: 63
> | ok 67 test_small_start_static_partial # SKIP XFAIL uninit bytes: 63
> | ok 70 test_small_start_static_all # SKIP XFAIL uninit bytes: 56
> | ok 73 test_small_start_dynamic_all # SKIP XFAIL uninit bytes: 56
> | ok 82 test_small_start_assigned_static_partial # SKIP XFAIL uninit bytes: 63
> | ok 85 test_small_start_assigned_static_all # SKIP XFAIL uninit bytes: 56
> | ok 88 test_small_start_assigned_dynamic_all # SKIP XFAIL uninit bytes: 56
> |
> | The above all now pass again with -fzero-init-padding-bits=all added.
> |
> | This also fixes the following cases for struct initialization that had
> | been XFAIL until now because there was no compiler support beyond the
> | larger "-ftrivial-auto-var-init=zero" option:
> |
> | ok 38 test_small_hole_static_all # SKIP XFAIL uninit bytes: 3
> | ok 39 test_big_hole_static_all # SKIP XFAIL uninit bytes: 124
> | ok 40 test_trailing_hole_static_all # SKIP XFAIL uninit bytes: 7
> | ok 42 test_small_hole_dynamic_all # SKIP XFAIL uninit bytes: 3
> | ok 43 test_big_hole_dynamic_all # SKIP XFAIL uninit bytes: 124
> | ok 44 test_trailing_hole_dynamic_all # SKIP XFAIL uninit bytes: 7
> | ok 58 test_small_hole_assigned_static_all # SKIP XFAIL uninit bytes: 3
> | ok 59 test_big_hole_assigned_static_all # SKIP XFAIL uninit bytes: 124
> | ok 60 test_trailing_hole_assigned_static_all # SKIP XFAIL uninit bytes: 7
> | ok 62 test_small_hole_assigned_dynamic_all # SKIP XFAIL uninit bytes: 3
> | ok 63 test_big_hole_assigned_dynamic_all # SKIP XFAIL uninit bytes: 124
> | ok 64 test_trailing_hole_assigned_dynamic_all # SKIP XFAIL uninit bytes: 7
> |
> | All of the above now pass when built under GCC 15. Tests can be seen
> | with:
> |
> | ./tools/testing/kunit/kunit.py run stackinit --arch=x86_64 \
> | --make_option CC=gcc-15
> |
> | Clang continues to fully initialize these kinds of variables[3] without
> | additional flags.
> |
> | Suggested-by: Jakub Jelinek <jakub@redhat.com>
> | Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118403 [1]
> | Link: https://lore.kernel.org/linux-toolchains/Z0hRrrNU3Q+ro2T7@tucnak/ [2]
> | Link: https://github.com/llvm/llvm-project/commit/7a086e1b2dc05f54afae3591614feede727601fa [3]
> | Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> | Acked-by: Masahiro Yamada <masahiroy@kernel.org>
> | Link: https://lore.kernel.org/r/20250127191031.245214-3-kees@kernel.org
> | Signed-off-by: Kees Cook <kees@kernel.org>
>
> [...]
Applied, thanks!
[1/1] kbuild: Use -fzero-init-padding-bits=all
https://git.pengutronix.de/cgit/barebox/commit/?id=56baf9bea6ba (link may not be stable)
Best regards,
--
Sascha Hauer <s.hauer@pengutronix.de>
prev parent reply other threads:[~2025-04-29 15:25 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-25 13:38 Ahmad Fatoum
2025-04-29 15:00 ` Sascha Hauer [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=174593885657.3116244.17088022716425865208.b4-ty@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=a.fatoum@pengutronix.de \
--cc=barebox@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox