[9/10 PATCH] Update riscv64-linux baseline_symbols.txt file

Jonathan Wakely jwakely@redhat.com
Tue Apr 30 09:22:00 GMT 2019


On 30/04/19 10:54 +0200, Jakub Jelinek wrote:
>On Tue, Apr 30, 2019 at 09:36:31AM +0100, Jonathan Wakely wrote:
>> On 30/04/19 10:28 +0200, Jakub Jelinek wrote:
>> > On Fri, Apr 26, 2019 at 01:57:06PM +0200, Jakub Jelinek wrote:
>> > > And here for powerpc 32-bit and s390 32-bit from binaries provided by
>> > > richi, the former cross-checked from binaries on a recent compile farm
>> > > bootstrap I've done.
>> >
>> > And here is riscv64, cross checked between Debian riscv64 build from 0428
>> > and Fedora alt riscv64 build from 0328, ok for trunk/9.1?
>>
>> OK, thanks.
>>
>> We're still waiting to hear from Rainer if his Solaris tests passed,
>> so we can commit his patch for the Solaris baselines.
>>
>> > Note, this is the only port I've touched the baseline_symbols.txt for that
>> > has fewer GLIBCXX_3.4.26 symbols from the others, in particular compared
>> > to e.g. x86_64-linux and others, following symbols are missing:
>> > FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_@@GLIBCXX_3.4.26
>> > FUNC:_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26
>> > FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS4_@@GLIBCXX_3.4.26
>> > FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26
>> > FUNC:_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS4_@@GLIBCXX_3.4.26
>> > FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS6_@@GLIBCXX_3.4.26
>> > FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26
>> > FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_@@GLIBCXX_3.4.26
>> > FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev@@GLIBCXX_3.4.26
>> > FUNC:_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS5_@@GLIBCXX_3.4.26
>> > Would that be because of no _GLIBCXX_HAVE_ATOMIC_LOCK_POLICY ?
>>
>> Yes, but I wonder why it doesn't have _Lock_policyE1 symbols instead
>> of the _Lock_policyE2 ones.
>
>Answer for that is easy, because gnu.ver doesn't say so:

Doh, of course.

>    _ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev;
>    _ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS4_;
>    _ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS4_;
>    _ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev;
>    _ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_;
>    _ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1Ev;
>    _ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_;
>    _ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEaSEOS5_;
>    _ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1Ev;
>    _ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE2EEC1EOS6_;
>Thus, you'd need to replace those _Lock_policyE2 with _Lock_policyE[012].
>If we want to do that, we need to do that right now (but not sure how long
>would it take to get a confirmation from riscv64, either we'd need to ask
>Matthias to do some build, or I'd need to talk to whatever maintainers

Linking this program should verify if the symbols are needed:

#include <filesystem>
int main()
{
  for (auto f : std::filesystem::directory_iterator("."))
    ;
  for (auto f : std::filesystem::recursive_directory_iterator("."))
    ;
}

>RISCV64 Fedora alt port has).  From what I can see, these _Lock_policyE2
>symbols are only exported in GLIBCXX_3.4.26, not earlier symvers.

Right, they're new with the std::filesystem exports.

>Note, there are many other _Lock_policyE2 symbols that aren't exported

Yes those other symbols are instantiated but only referenced from
within libstdc++.so.6 and not needed (or even possible to use) for
clients of the lib.



More information about the Gcc-patches mailing list