Am Dienstag, dem 09.09.2025 um 00:12 +0200 schrieb Martin Uecker:
> 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.
>
Sorry, example should have been this:
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.
>
>
>
