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

Louis Dionne via libcxx-dev libcxx-dev at lists.llvm.org
Fri Nov 16 07:45:11 PST 2018 


> On Nov 16, 2018, at 01:04, Kristina Brooks via libcxx-dev <libcxx-dev at lists.llvm.org> wrote:
> 
> I wrote a reply on the issue, however, I am not really known within the C++ community and
> since you're a C++ standards committee member, your input would likely be of very high
> value here as well. Could I ask you to chime in on the GitHub thread you linked
> (the https://github.com/itanium-cxx-abi/cxx-abi/issues/42 one).

I opened a strawman proposal here: https://github.com/itanium-cxx-abi/cxx-abi/pull/69 <https://github.com/itanium-cxx-abi/cxx-abi/pull/69>

This is naive, but that way folks can chime in and at least we have something concrete to work on.

Louis

> 
> Thank you in advance.
> - Kristina
> 
> On 16/11/2018 05:18, JF Bastien 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.
>> 
>> 
>>>> 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
> 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/8669bad4/attachment.html>

More information about the libcxx-dev mailing list