[libcxx-dev] Option to disable inline namespacing completely?

Kristina Brooks via libcxx-dev libcxx-dev at lists.llvm.org
Fri Nov 16 15:34:56 PST 2018 

FWIW, I think it may be worth moving this discussion over to https://github.com/itanium-cxx-abi/cxx-abi/pull/69 since
it's kind of out of scope of libc++(abi) alone.

On 16/11/2018 18:30, John McCall wrote:
>> On Nov 16, 2018, at 12:31 PM, Louis Dionne <ldionne at apple.com <mailto: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/
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>> 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>> 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
>>>>>>>>>>
>>>>>>>>>>  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>> 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>> 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>
>>>>>>>>>>
>>>>>>>>>>      -- 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>
>>>>>>>>>>      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
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4010 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20181116/33505600/attachment.bin>

More information about the libcxx-dev mailing list