Am Montag, dem 08.09.2025 um 14:51 -0700 schrieb Kees Cook:
> On Sun, Sep 07, 2025 at 11:25:19AM +0200, Martin Uecker wrote:
> > Am Donnerstag, dem 04.09.2025 um 17:24 -0700 schrieb Kees Cook:
> > > To support the KCFI type-id which needs to convert unique function
> > > prototypes into unique 32-bit values, add a subset of the Itanium C++
> > > mangling ABI for C typeinfo of function prototypes, but then do
> > > hashing, which is needed by KCFI to get a 32-bit hash value for a
> > > given function prototype. Optionally report the mangled string
> > > to the dumpfile.
> > >
> > > Trying to extract only the C portions of the gcc/cp/mangle.cc code
> > > seemed infeasible after a few attempts. So this is the minimal subset
> > > of the mangling ABI needed to generate unique KCFI type ids.
> > >
> > > I could not find a way to build a sensible selftest infrastructure for
> > > this code. I wanted to do something like this:
> > >
> > > #ifdef CHECKING_P
> > > const char code[] = "
> > > typedef struct { int x, y } xy_t;
> > > extern int func(xy_t *p);
> > > ";
> > >
> > > ASSERT_MANGLE (code, "_ZTSPFiP4xy_tE");
> > > ...
> > > #endif
> > >
> > > But I could not find any way to build a localized parser that could
> > > parse the "code" string from which I could extract the "func" fndecl.
> > > It would have been so much nicer to build the selftest directly into
> > > mangle.cc here, but I couldn't figure it out. Instead, later patches
> > > create a "kcfi" dump file, and the large kcfi testsuite validates
> > > expected mangle strings as part of the type-id validation.
> >
> > (BTW: I somewhere have a half-finished patch for two builtins, one that
> > one parse a string and return a type
>
> For the self test, that would be nice.
>
> > and one which would serialize
> > a type into a string. But it wasn't finished and I am not sure this
> > would be helpful.)
>
> This we have already (but prior to this is on C++) with the Mangling
> ABI.
I meant a string that is valid (and also human readable)
C representation of the type, not a mangled version.
>
> > I have two more general questions about this code. Is this mangling
> > be intended to be compatible with C's type system? Is it meant
> > to be stable, or can it be changed later?
>
> It is intended to be ABI, matching the Itanium C++ Mangling ABI.
>
> > If it is meant to be compatible with C's rules, you need to be
> > careful when to encode the size of an array, as, char[] and char[5]
> > are compatible types. So in many cases, one would have to remove
> > the size to not have errors when calling a function via a compatible
> > type that is slightly different.
>
> Since the serialization (mangling) and hashing need to be shared across
> languages (i.e. Rust needs to generate KCFI calls/preambles), we need to
> have the encoding agree.
If I am not mistaken, it would currently not agree between C and C.
typedef int arr_t[];
typedef int arr3_t[3];
void f(arr3_t);
void g(void (*fp)(arr_t)) {
int a[3];
(*fp)(&a); // this call would fail?
}
int h()
{
g(&f);
}
One has to canonicalize types before mangling if this is meant to be
compatible with C's type system
Martin
>
> One element for this series is whether we should continue to use FNV-1a
> for the hash (if so, we need to change Clang to match), and if not, we
> need to find a hash that both GCC and Clang can easily implement, and
> then switch to that for both.
