This is the mail archive of the mailing list for the libstdc++ project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: debug mode symbols cleanup

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
>>>>> export.
>>>> 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
>>> relax.
>>> 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
>>> method
>>> which is the correct signature.
>>> François
>> 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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]