This is the mail archive of the
mailing list for the libstdc++ project.
Re: debug mode symbols cleanup
- From: FranÃois Dumont <frs dot dumont at gmail dot com>
- To: Jonathan Wakely <jwakely at redhat dot com>
- Cc: "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 17 Sep 2015 21:27:35 +0200
- Subject: Re: debug mode symbols cleanup
- Authentication-results: sourceware.org; auth=none
- References: <55EB562F dot 9090607 at gmail dot com> <20150907110314 dot GE2631 at redhat dot com> <55EF495E dot 1090003 at gmail dot com> <55F71144 dot 30107 at gmail dot com> <20150915215707 dot GX2631 at redhat dot com>
On 15/09/2015 23:57, Jonathan Wakely wrote:
> On 14/09/15 20:26 +0200, François Dumont wrote:
>> On 08/09/2015 22:47, François Dumont wrote:
>>> On 07/09/2015 13:03, Jonathan Wakely wrote:
>>>> On 05/09/15 22:53 +0200, François Dumont wrote:
>>>>> I remember Paolo saying once that we were not guarantiing any abi
>>>>> compatibility for debug mode. I haven't found any section for
>>>>> unversioned symbols in gnu.ver so I simply uncomment the global
>>>> There is no section, because all exported symbols are versioned.
>>>> It's OK if objects compiled with Debug Mode using one version of GCC
>>>> don't link to objects compiled with Debug Mode using a different
>>>> version of GCC, but you can't change the exported symbols in the DSO.
>>>> Your changelog doesn't include the changes to config/abi/pre/gnu.ver,
>>>> but those changes are not OK anyway, they fail the abi-check:
>>>> FAIL: libstdc++-abi/abi_check
>>>> === libstdc++ Summary ===
>>>> # of unexpected failures 1
>>> Sorry, I though policy regarding debug mode symbols was even more
>>> It is not so here is another patch that doesn"t break abi checks.
>>> I eventually made all methods that should not be used deprecated, they
>>> were normally not used explicitely anyway. Their implementation is now
>>> empty. I just needed to add a symbol for the not const _M_message
>>> which is the correct signature.
>> I eventually considered doing it without impacting exported symbols. I
>> just kept the const qualifier on _M_messages and introduced a const_cast
>> in the implementation.
>> Is it ok to commit with this version ?
> The changes look OK now (assuming it passes 'make check-abi') but what
> does it actually do?
Mostly clean code, I have been upset in the past to be forced to
introduce new print methods to _Error_formatter or _Parameter type while
those methods were only used through a call to _M_error. Now we can
change anything to the code used to output the diagnostic without having
to also impact _Error_formatter.
I also disliked the mutable fields of _Error_formatter, it often
indicates a design flow, which was the case here.
> Does it significantly improve the output?
Not significantly. I initially start working on that because debug
messages were wrapped is a bad way. The message used to be cut on any
character that was not alnum, now we cut only on space. I would like to
improve rendering of types, they are not respecting the max line length
that can be specified by users, but that's not top priority of course.