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

[Jonathan Wakely <jwakely at redhat dot com>]

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.