On Mon, Sep 8, 2025 at 4:36 PM Andrew Pinski
<andrew.pin...@oss.qualcomm.com> wrote:
>
> On Mon, Sep 8, 2025 at 4:24 PM Kees Cook <k...@kernel.org> wrote:
> >
> > On Tue, Sep 09, 2025 at 12:13:19AM +0200, Martin Uecker wrote:
> > > 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);
> > > }
> >
> > Yes, that would fail. It's a pointer to an array of 3 ints, and that's
> > fine for distinguishing mismatched callers:
> >
> > void(arr3_t*) -> void(int(*)[3]) -> _ZTSFvPA3_iE
> > void(arr_t*) -> void(int(*)[]) -> _ZTSFvPA_iE
> >
> > How should I adjust this patch's description to say the mangling may
> > follow a stricter type system?
>
> Maybe it is time to step back for a second and figure out other things
> are not going to work with this mangling scheme? At the bare minimum
> write down limitations to the user documentation (and write up a bug
> report to LLVM for them to do the same).
>
> Or even better step back and fix the hashing scheme to fit better with
> C rather than reusing IA64 C++ ABI mangling (which is not designed for
> C). If we need a hard ABI break due to limitations, it is good to do
> it now rather than having 2 different implementations that need to
> change upstream; right now you only need to break LLVM's ABI.
Oh look it is also known to broken for anonymous named structs too:
https://github.com/llvm/llvm-project/issues/106593
Thanks,
Andrew
>
> Thanks,
> Andrew Pinski
