mangling substitutions for `std` inline namespaces about cxx-abi HOT 7 OPEN

Hi,

Wanted to chime in and mention that we discussed this on libcxx-dev mailing lists and IRC and want to come up with a more compact form of mangling for versioned inline namespaces used by libc++ (Handling it at Clang's mangler/demangler's level) as we previously decided that std::__[0-9]+ was reserved for libc++'s use (since there was a request to allow to configure a custom versioning namespace so the halfway solution was to reserve numeric parts of the namespace to libc++ and allow any other legal or illegal variation or characters to be specified there via a CMake option.

Now comes the main issue, while ABIv1 (std::__1) is set in stone and is considered stable, ABIv2 isn't and Fuchsia doesn't mind ABI breaks (they're the only notable users of ABIv2 which is the current unstable ABI). I'd like to propose some variation of shorthand mangling for the reserved namespaces of libc++ that would eliminate tons of clutter as far as debug data goes (I've covered the rationale extensively in this thread):

http://lists.llvm.org/pipermail/libcxx-dev/2018-November/000063.html

However agreeing on the mangling style while at the same time keeping it as short as possible and avoiding possible conflicts with libstdcxx is one of the issues. I don't think there's much point in extending this to user configurable namespaces as we don't have any control over that but I would very much like to have a consensus on having compact mangling forms for std::__2 (ABIv2) versions of string, basic_string and all others originally covered by the IA64 doc where they're available only at the top level (aka no inline namespaces).

Chandler said that this is not up to the C++ committee and that this should be brought up here instead. Given the recent improvements in both mangling and demangling code in Clang, I could handle the needed changes myself as far as LLVM/Clang go, though said change would need to be incorporated into IA64 ABI first with some sort of standard for mangling symbols in ABIv2 and above. Since I'm notoriously bad at writing proposals, I'm not sure what the new mangling scheme could/should look like, and I failed to get much feedback from Louis and Eric seems too busy, so it seems it's down to me.

Compatibility with GCC is always a concern as well so I'm not sure how to address that as I'm not a GCC contributor and am not that familiar with the GNU side of things. I am very much hoping that someone could provide some kind of a draft of what the shorthand mangling scheme would be like, keeping in mind that we've drawn the conclusion (at least on libc++ side) that std::__N or more specifically std::__2 and above are reserved for C++ stdlib implementers.

Thanks.

from cxx-abi.

Rest of the discussion is on this PR: #69

from cxx-abi.

If the std library is ever modilarized, we'll need to attach module-names to those substitutions too. i'm not attempting to do that in the module mangling right now.
Do these substitutions greatly compress manglings in practice? We only have 6 such special cases and there are many more std types.

from cxx-abi.

I think between libstdc++ using ABI tags and libc++ using an inline namespace, the standard manglings are fairly dead, other than the one for std:: itself. But the potential for substitutions to improve symbol sizes is quite large, and it's an important issue in practice; that's what this thread is about.

from cxx-abi.

How is this work going now? Can we have some option to disable inline namespace in libcxx?

from cxx-abi.

I think between libstdc++ using ABI tags and libc++ using an inline namespace, the standard manglings are fairly dead, other than the one for std:: itself. But the potential for substitutions to improve symbol sizes is quite large, and it's an important issue in practice; that's what this thread is about.

In the issue #69, I'm still confused why versioning namespaces in libcxx will not clash with ABI tags in libstdcxx. Sometimes we may need to both use libcxx and libstdcxx, there will be conflicts.

from cxx-abi.

There hasn't been any progress since the discussion in #70, mostly because nobody is working on implementing it.

from cxx-abi.