Ok, I'll give it another try.
Trying to use the same approach for targets using gnu.ver and others
thought, seems more reasonable to me.
François
On 22/05/2025 09:28, Jonathan Wakely wrote:
On Thu, 22 May 2025, 08:26 Jonathan Wakely, <jwakely....@gmail.com> wrote:
On Thu, 15 May 2025, 06:26 François Dumont, <frs.dum...@gmail.com>
wrote:
Got
On 14/05/2025 18:46, Jonathan Wakely wrote:
> On Wed, 14 May 2025 at 17:31, François Dumont
<frs.dum...@gmail.com> wrote:
>> On 12/05/2025 23:03, Jonathan Wakely wrote:
>>> On 31/03/25 22:20 +0200, François Dumont wrote:
>>>> Hi
>>>>
>>>> Following this previous patch
>>>>
https://gcc.gnu.org/pipermail/libstdc++/2024-August/059418.html
I've
>>>> completed it for the _Safe_unordered_container_base type and
>>>> implemented the rest of the change to store the safe iterator
>>>> sequence as a pointer-to-const.
>>>>
>>>> libstdc++: Make debug iterator pointer sequence
const [PR116369]
>>>>
>>>> In revision a35dd276cbf6236e08bcf6e56e62c2be41cf6e3c
the debug
>>>> sequence
>>>> have been made mutable to allow attach iterators to
const
>>>> containers.
>>>> This change completes this fix by also declaring
debug unordered
>>>> container
>>>> members mutable.
>>>>
>>>> Additionally the debug iterator sequence is now a
>>>> pointer-to-const and so
>>>> _Safe_sequence_base _M_attach and all other methods
are const
>>>> qualified.
>>>> Symbols export are maintained thanks to __asm
directives.
>>>>
>>> I can't compile this, it seems to be missing changes to
>>> safe_local_iterator.tcc:
>>>
>>> In file included from
>>>
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/safe_local_iterator.h:444,
>>> from
>>> /home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++11/debug.cc:33:
>>>
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/safe_local_iterator.tcc:
>>> In member function ‘typename
>>> __gnu_debug::_Distance_traits<_Iterator>::__type
>>> __gnu_debug::_Safe_local_iterator<_Iterator,
>>> _Sequence>::_M_get_distance_to(const
>>> __gnu_debug::_Safe_local_iterator<_Iterator, _Sequence>&)
const’:
>>>
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/safe_local_iterator.tcc:47:17:
>>> error: there are no arguments to ‘_M_get_sequence’ that
depend on a
>>> template parameter, so a declaration of ‘_M_get_sequence’
must be
>>> available [-Wtemplate-body]
>>> 47 | _M_get_sequence()->bucket_size(bucket()),
>>> | ^~~~~~~~~~~~~~~
>>>
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/safe_local_iterator.tcc:47:17:
>>> note: (if you use ‘-fpermissive’, G++ will accept your
code, but
>>> allowing the use of an undeclared name is deprecated)
>>>
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/debug/safe_local_iterator.tcc:59:18:
>>> error: there are no arguments to ‘_M_get_sequence’ that
depend on a
>>> template parameter, so a declaration of ‘_M_get_sequence’
must be
>>> available [-Wtemplate-body]
>>> 59 | -_M_get_sequence()->bucket_size(bucket()),
>>> | ^~~~~~~~~~~~~~~
>>>
>> Yes, sorry, I had already spotted this problem, but only
updated the PR
>> and not re-sending patch here.
>>
>>
>>>> Also available as a PR
>>>>
>>>> https://forge.sourceware.org/gcc/gcc-TEST/pulls/47
>>>>
>>>> /** Detach all singular iterators.
>>>> * @post for all iterators i attached to this sequence,
>>>> * i->_M_version == _M_version.
>>>> */
>>>> void
>>>> - _M_detach_singular();
>>>> + _M_detach_singular() const
>>>> +
__asm("_ZN11__gnu_debug19_Safe_sequence_base18_M_detach_singularEv");
>>> Does this work on all targets?
>> No idea ! I thought the symbol name used here just had to
match the
>> entries in config/abi/pre/gnu.ver.
> That linker script is not used for all targets.
Ok, got it, I only need to use this when symbol versioning is
activated.
I don't think that's right. For targets that don't use gnu.ver we
still want to preserve the same symbols. They just aren't
versioned on those targets.
And e.g. Solaris uses versioning, but a different format, not
gnu.ver, and I don't remember it the same macro is defined.
Isn't it possible to do this without asm somehow? At least as a
fallback for targets that don't use gnu.ver
Basically this needs more research, and then testing on other targets.
I think this new patch should do it if so.
François
