Add vendor-specific suffixes to v0 mangling RFC 2603 by lqd · Pull Request #3224...

Copy link

Member

This comment has been hidden.

lqd commented 7 days ago

Fixed

eddyb commented 6 days ago

So I was talking to @lqd about my confusion around the Itanium ABI mangling not having such a general mechanism, and @lqd found that it was added in itanium-cxx-abi/cxx-abi#36, relatively recently!

Especially if someone doesn't find that repo, they're likely reading outdated versions without vendor suffixes.

The GNU demangler (in libiberty and used by e.g. c++filt) are not complying with it, they only handle the GCC .clone suffix

Oh, wow, I was wrong, c++filt will happily demangle a path (like _ZN3foo3barE into foo::bar), i.e. without a function signature, but they consider the vendor suffix part of the signature, so those don't get demangled without the signature (also, they kept their "clone" terminology even with other suffixes):

$ c++filt _ZN3foo3barE _ZN3foo3barEv _ZN3foo3barE.llvm.123 _ZN3foo3barEv.llvm.123
foo::bar
foo::bar()
_ZN3foo3barE.llvm.123
foo::bar() [clone .llvm.123]

I think it was a bad idea for this to be "nested" in a C++ symbol, because you then get weird stuff like that, and ideally it could be handled uniformly for every symbol name (after all, LLVM adds its suffixes without knowing about the mangling of the original symbol name, be it C++, Rust, unmangled, some other thing, etc.).

But specifying it in the RFC won't hurt, I suppose.