[libcxx-dev] Option to disable inline namespacing completely?
John McCall via libcxx-dev
libcxx-dev at lists.llvm.org
Fri Nov 16 10:30:51 PST 2018
> On Nov 16, 2018, at 12:31 PM, Louis Dionne <ldionne at apple.com> wrote:
>> On Nov 16, 2018, at 12:21, JF Bastien <jfbastien at apple.com <mailto:jfbastien at apple.com>> wrote:
>>> On Nov 16, 2018, at 5:06 AM, Louis Dionne <ldionne at apple.com <mailto:ldionne at apple.com>> wrote:
>>>
>>>
>>>
>>>> On Nov 16, 2018, at 00:18, JF Bastien via libcxx-dev <libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>> wrote:
>>>>
>>>>
>>>>
>>>>> On Nov 15, 2018, at 5:41 PM, Kristina Brooks via libcxx-dev <libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>> wrote:
>>>>>
>>>>> Well that was in my original suggestion, but I don't know who is in charge of IA64 mangling, I
>>>>> don't think Clang developers can push a change like this forward without some RFC to whatever
>>>>> committee maintains the IA64 ABI or am I wrong? I suppose libc++ ABI could be considered separate
>>>>> enough in which case we just need to come up with a compatible scheme for "short" manglings that
>>>>> is also guaranteed not to clash with the standard IA64 ABI.
>>>>>
>>>>> Since you and Eric are mostly in charge of libcxxabi, could you propose a draft for a compatible
>>>>> short mangling that would allow doing this as a breaking change (for unstable ABI versions, even
>>>>> 2+ since it's not stable yet unless Fuchsia has settled on it)? That way it's possible to add that
>>>>> into the Clang mangler. I'm still not sure if this requires a blessing from whoever is in charge
>>>>> of IA64 ABI, I think that would be a good idea to mention the draft to them at least.
>>>>
>>>> According to: https://itanium-cxx-abi.github.io/cxx-abi/ <https://itanium-cxx-abi.github.io/cxx-abi/>
>>>>
>>>> The primary discussion forum for the ABI is the GitHub repository <http://github.com/itanium-cxx-abi/cxx-abi/>. Please open a new issue for any new topic you want to discuss. Previously, the ABI was discussed on a mailing list, cxx-abi-dev, whose archives <http://sourcerytools.com/pipermail/cxx-abi-dev/> are still accessible.
>>>>
>>>> CC’ing John since he’ll know more about this, seeing as how he’s the most active contributor to the repository :-)
>>>>
>>>> This issue from Richard seems like a good starting point: https://github.com/itanium-cxx-abi/cxx-abi/issues/42 <https://github.com/itanium-cxx-abi/cxx-abi/issues/42>
>>>>
>>>>
>>>>> Thanks.
>>>>>
>>>>> On 16/11/2018 01:26, Louis Dionne wrote:
>>>>>>
>>>>>>
>>>>>>> On Nov 15, 2018, at 20:06, JF Bastien via libcxx-dev <libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Nov 15, 2018, at 3:59 PM, Kristina Brooks via libcxx-dev <libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>> wrote:
>>>>>>>>
>>>>>>>> Yes exactly, seems like an obvious win on a mono-ABI system, if preserving debug data
>>>>>>>> this saves a lot, not to mention symbol table strings. Also, I'm purely speculating here
>>>>>>>> but this would also speed up compilation and linking time by an insignificant margin, but
>>>>>>>> nevertheless, it's an improvement.
>>>>>>>>
>>>>>>>> If the ABI ever needs to change, on those kinds of systems, it's easy enough with an OS
>>>>>>>> update.
>>>>>>>
>>>>>>> Or, we could update the Itanium ABI so that the current mangling still works and is compatible with a new mangling which is shorter for libc++ (yet remains purposefully incompatible with libstdc++’s mangling) 🙂
>>>>>>>
>>>>>>
>>>>>> Is it necessary/desirable to distinguish between implementations of the standard library at the Itanium ABI level? Wouldn't it be possible to define a compressed scheme for `std::__N` in full generality, and handle the ability to differentiate between implementations differently?
>>>>
>>>> What I had in mind was distinguishing `std::__N` as you say, and by construction that would distinguish between implementations because libc++ and libstdc++ use different namespaces.
>>>
>>> But that would also prevent libstdc++ from ever using that mangling scheme (not that I care about libstdc++, but you know).
>>
>> Not really, they can share the namespace if we don’t collide. They get the odd numbers we get the even ones? As long as we don’t cause ABI mismatches it’s fine.
>
> Actually, I think the Itanium ABI provides a way to add vendor-specific tags to mangling:
>
> A <mangled-name <http://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangle.mangled-name>> containing a period represents a vendor-specific version or portion of the entity named by the <encoding <http://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangle.encoding>> prior to the first period. There is no restriction on the characters that may be used in the suffix following the period.
>
> So if libstdc++ wanted to use inline namespaces for versioning, they could do it with a bit of tooling support IIUC.
>
> Re-reading this, I'm now wondering why we're not piggy-backing on this mechanism to encode the version of libc++? It does seem like this mechanism was made explicitly for that use case.
It was added to bless the existing practice of vendors who want to do things like emit various private symbols associated with an ABI entity without invading on the set of names that the ABI could theoretically want to use someday. It is not intended for symbols whose mangling is controlled by the ABI, and in fact its motivation precludes the ABI from intruding on that space.
I agree that it would be nice to use the abbreviations. We could add some sort of mode prefix to the symbol that says that `std` in all the standard abbreviations actually refers to `std::__1`, and then anything that doesn't obey that — because it's differently-versioned or part of the small subset that's not in `std::__1` — wouldn't get to use it. We'd need some unambiguous way to decide whether to use the prefix; a reasonable heuristic would be "what's the exact namespace of the first declaration we try to mangle that's ultimately within std:: ?".
Of course, actually enabling that would be totally ABI-breaking.
John.
>
> Louis
>
>
>>
>>
>>> Louis
>>>
>>>>
>>>>
>>>>>> Louis
>>>>>>
>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> On 14/11/2018 17:06, Eric Fiselier wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Nov 14, 2018 at 12:04 PM Eric Fiselier <eric at efcs.ca <mailto:eric at efcs.ca> <mailto:eric at efcs.ca <mailto:eric at efcs.ca>>> wrote:
>>>>>>>>>
>>>>>>>>> The itanium specification provides special compressed mangled names for std::string when it's not in an inline
>>>>>>>>> namespace [1]
>>>>>>>>>
>>>>>>>>> Specifically, `Ss` vs `St3__112basic_string`
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Correction... `Ss` vs `NSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEE`
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> [1] https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling-compression <https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling-compression>
>>>>>>>>>
>>>>>>>>> On Wed, Nov 14, 2018 at 10:03 AM Marshall Clow via libcxx-dev <libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>
>>>>>>>>> <mailto:libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>>> wrote:
>>>>>>>>>
>>>>>>>>> On Sun, Nov 11, 2018 at 9:49 PM Kristina Brooks via libcxx-dev <libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>
>>>>>>>>> <mailto:libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I was wondering, would it be possible to add an option to disable inline namespacing completely (as a CMake
>>>>>>>>> configuration flag) in libc++ for the sake of being able to use shorthand mangling and without having to
>>>>>>>>> resort to
>>>>>>>>> handling it on IA64 mangler level. This has many use cases for example distributions of anything that
>>>>>>>>> includes libc++ as
>>>>>>>>> one and only libc++ and does not allow non-vendor software to be installed. On an embedded system, assuming
>>>>>>>>> debug info
>>>>>>>>> is generated, and given how common some of the debug data takes a very significant amount of space given the
>>>>>>>>> complex
>>>>>>>>> definition of something like `std::__2::basic_string<...>` versus the short form (`std::string` having a
>>>>>>>>> shorthand
>>>>>>>>> mangling is a godsend since it's 95% shorter, not an accurate figure but basically definitely above 90%).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'm confused here.
>>>>>>>>> Why are you comparing `std::string` to `std::__2::basic_string<......" ?
>>>>>>>>>
>>>>>>>>> `std::__2::string` is quite short.<http://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev>>
>>>>>>>>>
>>>>>>>>> -- Marshall
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> libcxx-dev mailing list
>>>>>>>>> libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org> <mailto:libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>>
>>>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev>
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> libcxx-dev mailing list
>>>>>>>> libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>
>>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> libcxx-dev mailing list
>>>>>>> libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>
>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev>
>>>>>>
>>>>> _______________________________________________
>>>>> libcxx-dev mailing list
>>>>> libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev>
>>>>
>>>> _______________________________________________
>>>> libcxx-dev mailing list
>>>> libcxx-dev at lists.llvm.org <mailto:libcxx-dev at lists.llvm.org>
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20181116/fa68061c/attachment-0001.html>
More information about the libcxx-dev
mailing list