From: Jakub Jelinek <jakub@redhat.com>
To: Andrea Pinski <andrew.pinski@oss.qualcomm.com>
Cc: Juergen Christ <jchrist@linux.ibm.com>,
Kees Cook <kees@kernel.org>,
Jeffrey Law <jefflaw@qti.qualcomm.com>,
Joseph Myers <josmyers@redhat.com>,
Richard Biener <rguenther@suse.de>,
Martin Uecker <uecker@tugraz.at>,
Peter Zijlstra <peterz@infradead.org>,
Ard Biesheuvel <ardb@kernel.org>, Jan Hubicka <hubicka@ucw.cz>,
Richard Earnshaw <richard.earnshaw@arm.com>,
Richard Sandiford <richard.sandiford@arm.com>,
Marcus Shawcroft <marcus.shawcroft@arm.com>,
Kyrylo Tkachov <kyrylo.tkachov@arm.com>,
Kito Cheng <kito.cheng@gmail.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Andrew Waterman <andrew@sifive.com>,
Jim Wilson <jim.wilson.gcc@gmail.com>,
Dan Li <ashimida.1990@gmail.com>,
Sami Tolvanen <samitolvanen@google.com>,
Ramon de C Valle <rcvalle@google.com>,
Joao Moreira <joao@overdrivepizza.com>,
Nathan Chancellor <nathan@kernel.org>,
Bill Wendling <morbo@google.com>,
Osterlund Sebastian <sebastian.osterlund@intel.com>,
Constable Scott D <scott.d.constable@intel.com>,
gcc-patches@gcc.gnu.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH v15 1/7] kcfi: Introduce KCFI typeinfo mangling API
Date: Thu, 24 Sep 2026 10:27:42 +0200 [thread overview]
Message-ID: <arTe_idboRBVfJLY@tucnak> (raw)
In-Reply-To: <CALvbMcDRqkVH2gBbX-Ss8d7yM=-w3dunZYXuibp7dDrYbuJH3Q@mail.gmail.com>
On Wed, Sep 23, 2026 at 08:57:49PM -0700, Andrea Pinski wrote:
> > > +/* Test mangling of basic builtin types. */
> > > +
> > > +static void
> > > +test_typeinfo_basic_types ()
> > > +{
> > > + ASSERT_STREQ ("v", kcfi_test_mangle (void_type_node).c_str ());
> > > + ASSERT_STREQ ("c", kcfi_test_mangle (char_type_node).c_str ());
> > > + ASSERT_STREQ ("a", kcfi_test_mangle (signed_char_type_node).c_str ());
> > > + ASSERT_STREQ ("h", kcfi_test_mangle (unsigned_char_type_node).c_str ());
> > > + ASSERT_STREQ ("s", kcfi_test_mangle (short_integer_type_node).c_str ());
> > > + ASSERT_STREQ ("t", kcfi_test_mangle (short_unsigned_type_node).c_str ());
> > > + ASSERT_STREQ ("i", kcfi_test_mangle (integer_type_node).c_str ());
> > > + ASSERT_STREQ ("j", kcfi_test_mangle (unsigned_type_node).c_str ());
> > > + ASSERT_STREQ ("l", kcfi_test_mangle (long_integer_type_node).c_str ());
> > > + ASSERT_STREQ ("m", kcfi_test_mangle (long_unsigned_type_node).c_str ());
> > > + ASSERT_STREQ ("x", kcfi_test_mangle (long_long_integer_type_node).c_str ());
> > > + ASSERT_STREQ ("y", kcfi_test_mangle (long_long_unsigned_type_node).c_str ());
> > > + ASSERT_STREQ ("f", kcfi_test_mangle (float_type_node).c_str ());
> > > + ASSERT_STREQ ("d", kcfi_test_mangle (double_type_node).c_str ());
> > > + ASSERT_STREQ ("e", kcfi_test_mangle (long_double_type_node).c_str ());
> >
> > I looked at this on s390x. We actually change the mangling of long
> > double if we are on a target where long double is 128bit IEEE to a
> > "g". This causes this self-test to fail. I suggest to add this patch
> > on top of our patch to fix this:
> >
> > diff --git a/gcc/kcfi-typeinfo.cc b/gcc/kcfi-typeinfo.cc
> > index b6723fac48da..fab06249ae16 100644
> > --- a/gcc/kcfi-typeinfo.cc
> > +++ b/gcc/kcfi-typeinfo.cc
> > @@ -659,7 +659,14 @@ test_typeinfo_basic_types ()
> > ASSERT_STREQ ("y", kcfi_test_mangle (long_long_unsigned_type_node).c_str ());
> > ASSERT_STREQ ("f", kcfi_test_mangle (float_type_node).c_str ());
> > ASSERT_STREQ ("d", kcfi_test_mangle (double_type_node).c_str ());
> > +#if defined (__s390x__)
> > + if (TARGET_LONG_DOUBLE_128)
> > + ASSERT_STREQ ("g", kcfi_test_mangle (long_double_type_node).c_str ());
> > + else
> > + ASSERT_STREQ ("e", kcfi_test_mangle (long_double_type_node).c_str ());
> > +#else
> > ASSERT_STREQ ("e", kcfi_test_mangle (long_double_type_node).c_str ());
> > +#endif
>
> Maybe we should use out the target hook here instead of hard coding
> the encoding.
Certainly. Note, the ifdef is just wrong, that is testing the host
architecture, while it actually cares about the target architecture.
So, this would also fail miserably with cross-compilers (both from s390x
to something else, then TARGET_LONG_DOUBLE_128 macro wouldn't often even
exist), or from say x86_64 to s390x.
Also, it isn't really s390x specific, alpha also g or e based on options,
ia64 too, on rs6000 it can be e, g or u9__ieee128, on sparc also g or e.
Jakub
next prev parent reply other threads:[~2026-09-24 8:28 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-25 23:57 [PATCH v15 0/7] Introduce Kernel Control Flow Integrity ABI [PR107048] Kees Cook
2026-08-25 23:57 ` [PATCH v15 1/7] kcfi: Introduce KCFI typeinfo mangling API Kees Cook
2026-09-23 9:25 ` Juergen Christ
2026-09-24 3:55 ` Kees Cook
2026-09-24 7:55 ` Juergen Christ
2026-10-05 10:24 ` Kees Cook
2026-09-24 3:57 ` Andrea Pinski
2026-09-24 8:27 ` Jakub Jelinek [this message]
2026-08-25 23:57 ` [PATCH v15 2/7] kcfi: Add core Kernel Control Flow Integrity infrastructure Kees Cook
2026-08-25 23:57 ` [PATCH v15 3/7] kcfi: Add regression test suite Kees Cook
2026-08-25 23:57 ` [PATCH v15 4/7] x86: Add x86_64 Kernel Control Flow Integrity implementation Kees Cook
2026-08-26 8:57 ` Uros Bizjak
2026-08-27 5:03 ` Kees Cook
2026-08-27 8:03 ` Uros Bizjak
2026-08-25 23:57 ` [PATCH v15 5/7] aarch64: Add AArch64 " Kees Cook
2026-08-25 23:57 ` [PATCH v15 6/7] arm: Add ARM 32-bit " Kees Cook
2026-08-25 23:57 ` [PATCH v15 7/7] riscv: Add RISC-V " Kees Cook
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=arTe_idboRBVfJLY@tucnak \
--to=jakub@redhat.com \
--cc=andrew.pinski@oss.qualcomm.com \
--cc=andrew@sifive.com \
--cc=ardb@kernel.org \
--cc=ashimida.1990@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=hubicka@ucw.cz \
--cc=jchrist@linux.ibm.com \
--cc=jefflaw@qti.qualcomm.com \
--cc=jim.wilson.gcc@gmail.com \
--cc=joao@overdrivepizza.com \
--cc=josmyers@redhat.com \
--cc=kees@kernel.org \
--cc=kito.cheng@gmail.com \
--cc=kyrylo.tkachov@arm.com \
--cc=linux-hardening@vger.kernel.org \
--cc=marcus.shawcroft@arm.com \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=palmer@dabbelt.com \
--cc=peterz@infradead.org \
--cc=rcvalle@google.com \
--cc=rguenther@suse.de \
--cc=richard.earnshaw@arm.com \
--cc=richard.sandiford@arm.com \
--cc=samitolvanen@google.com \
--cc=scott.d.constable@intel.com \
--cc=sebastian.osterlund@intel.com \
--cc=uecker@tugraz.at \
/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