Re: [9/10 PATCH] Update riscv64-linux baseline_symbols.txt file
On Tue, Apr 30, 2019 at 12:06 PM Jakub Jelinek wrote: > I think you can e.g. have a look at what alpha does in > alpha_split_compare_and_swap_12, it doesn't have a hw 8-bit or 16-bit > compare and swap either. Thanks. I had noticed that the rs6000 port had what I needed, but looking the alpha one too is a good idea, as that one might be closer in design to the RISC-V architecture since both are similar to MIPS. Jim
Re: [9/10 PATCH] Update riscv64-linux baseline_symbols.txt file
On 30/04/19 21:06 +0200, Jakub Jelinek wrote: On Tue, Apr 30, 2019 at 12:02:04PM -0700, Jim Wilson wrote: On Tue, Apr 30, 2019 at 1:29 AM Jakub Jelinek wrote: > From what I can see in riscv/sync.md, there is 32 bit and 64 bit compare and > swap, but not 16 bit (no idea why it doesn't emulate 8 bit and 16 bit > cas using 32 bit one). This is a known problem on our to do list, and there is already a bugzilla or two about this. There are unfortunately a lot of items on our to do list as RISC-V is still a relatively new target. This is also complicated by the fact that we didn't have a formal memory model defined until last year, and now that we do have one, the gcc support needs to be updated to follow the formal memory model. There are a number of cleanup issues to fix here, such as the fact that we are emitting fences in places where the formal memory model says we don't need them. Anyways, we do want to fix this, but it is not clear when we will have time to do it. I think you can e.g. have a look at what alpha does in alpha_split_compare_and_swap_12, it doesn't have a hw 8-bit or 16-bit compare and swap either. Anyway, once you make a change, there will need to be work on the libstdc++ side for riscv too to preserve ABI (i.e. keep exporting the _Lock_priority 1 variants and add _Lock_priority 2 to a new symbol version). Or to make the directory iterators keep using the same type as used today, __shared_ptr, even if the _S_atomic policy would work instead.
Re: [9/10 PATCH] Update riscv64-linux baseline_symbols.txt file
On Tue, Apr 30, 2019 at 12:02:04PM -0700, Jim Wilson wrote: > On Tue, Apr 30, 2019 at 1:29 AM Jakub Jelinek wrote: > > From what I can see in riscv/sync.md, there is 32 bit and 64 bit compare and > > swap, but not 16 bit (no idea why it doesn't emulate 8 bit and 16 bit > > cas using 32 bit one). > > This is a known problem on our to do list, and there is already a > bugzilla or two about this. There are unfortunately a lot of items on > our to do list as RISC-V is still a relatively new target. This is > also complicated by the fact that we didn't have a formal memory model > defined until last year, and now that we do have one, the gcc support > needs to be updated to follow the formal memory model. There are a > number of cleanup issues to fix here, such as the fact that we are > emitting fences in places where the formal memory model says we don't > need them. Anyways, we do want to fix this, but it is not clear when > we will have time to do it. I think you can e.g. have a look at what alpha does in alpha_split_compare_and_swap_12, it doesn't have a hw 8-bit or 16-bit compare and swap either. Anyway, once you make a change, there will need to be work on the libstdc++ side for riscv too to preserve ABI (i.e. keep exporting the _Lock_priority 1 variants and add _Lock_priority 2 to a new symbol version). Jakub
Re: [9/10 PATCH] Update riscv64-linux baseline_symbols.txt file
On Tue, Apr 30, 2019 at 1:29 AM Jakub Jelinek wrote: > From what I can see in riscv/sync.md, there is 32 bit and 64 bit compare and > swap, but not 16 bit (no idea why it doesn't emulate 8 bit and 16 bit > cas using 32 bit one). This is a known problem on our to do list, and there is already a bugzilla or two about this. There are unfortunately a lot of items on our to do list as RISC-V is still a relatively new target. This is also complicated by the fact that we didn't have a formal memory model defined until last year, and now that we do have one, the gcc support needs to be updated to follow the formal memory model. There are a number of cleanup issues to fix here, such as the fact that we are emitting fences in places where the formal memory model says we don't need them. Anyways, we do want to fix this, but it is not clear when we will have time to do it. Jim
Re: [9/10 PATCH] Update riscv64-linux baseline_symbols.txt file
On 30/04/19 12:29 +0200, Jakub Jelinek wrote:
On Tue, Apr 30, 2019 at 10:04:33AM +0100, Jonathan Wakely wrote:
> 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
int main()
{
for (auto f : std::filesystem::directory_iterator("."))
;
for (auto f : std::filesystem::recursive_directory_iterator("."))
;
}
So, that indeed fails with -O0 -std=c++17 -Wl,--no-demangle
https://paste.fedoraproject.org/paste/wvIxqaH37DYNn4b4Cfua~w
Unfortunately, at least judging from the libstdc++*debug symbols on riscv64
I've posted, it probably isn't just a matter of following, because while
some symbols like that are in, most of them are not.
E.g. the first one mentioned in the above paste is missing, the closest
constructor to
_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE1EEC1EOS5_
that is missing but needed by the binary is:
_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE1EEC1ERKSt10__weak_ptrIS2_LS4_1EESt9nothrow_t
I've tried to simulate this on x86_64 by hand-editing c++config.h to
-#define _GLIBCXX_HAVE_ATOMIC_LOCK_POLICY 1
+/* #undef _GLIBCXX_HAVE_ATOMIC_LOCK_POLICY */
but then after make clean; make -j32 in libstdc++ objdir I don't see any
__shared_ptr.*_Lock_policyE symbols.
This patch should simulate it more reliably, by explicitly selecting
the _S_mutex policy instead of using the default.
diff --git a/libstdc++-v3/include/bits/fs_dir.h b/libstdc++-v3/include/bits/fs_dir.h
index 69f0eb825fe..dc1569067e0 100644
--- a/libstdc++-v3/include/bits/fs_dir.h
+++ b/libstdc++-v3/include/bits/fs_dir.h
@@ -420,7 +420,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
friend class recursive_directory_iterator;
-std::__shared_ptr<_Dir> _M_dir;
+std::__shared_ptr<_Dir, _S_mutex> _M_dir;
};
inline directory_iterator
@@ -509,7 +509,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
{ return !(__lhs == __rhs); }
struct _Dir_stack;
-std::__shared_ptr<_Dir_stack> _M_dirs;
+std::__shared_ptr<_Dir_stack, _S_mutex> _M_dirs;
};
inline recursive_directory_iterator
@@ -529,9 +529,9 @@ _GLIBCXX_END_NAMESPACE_CXX11
// value of __default_lock_policy between code including this header and
// the library will cause a linker error.
extern template class
-__shared_ptr;
+__shared_ptr;
extern template class
-__shared_ptr;
+__shared_ptr;
_GLIBCXX_END_NAMESPACE_VERSION
} // namespace std
diff --git a/libstdc++-v3/src/c++17/fs_dir.cc b/libstdc++-v3/src/c++17/fs_dir.cc
index d8c48f6d6d8..92a48836cf4 100644
--- a/libstdc++-v3/src/c++17/fs_dir.cc
+++ b/libstdc++-v3/src/c++17/fs_dir.cc
@@ -38,8 +38,8 @@
namespace fs = std::filesystem;
namespace posix = std::filesystem::__gnu_posix;
-template class std::__shared_ptr;
-template class std::__shared_ptr;
+template class std::__shared_ptr;
+template class std::__shared_ptr;
struct fs::_Dir : _Dir_base
{
@@ -135,7 +135,7 @@ directory_iterator(const path& p, directory_options options, error_code* ecptr)
if (dir.dirp)
{
- auto sp = std::__make_shared(std::move(dir));
+ auto sp = std::__make_shared(std::move(dir));
if (sp->advance(skip_permission_denied, ec))
_M_dir.swap(sp);
}
@@ -203,7 +203,7 @@ recursive_directory_iterator(const path& p, directory_options options,
{
if (ecptr)
ecptr->clear();
- auto sp = std::__make_shared<_Dir_stack>(options, dirp, p);
+ auto sp = std::__make_shared<_Dir_stack, _S_mutex>(options, dirp, p);
if (ecptr ? sp->top().advance(*ecptr) : sp->top().advance())
_M_dirs.swap(sp);
Re: [9/10 PATCH] Update riscv64-linux baseline_symbols.txt file
On Tue, Apr 30, 2019 at 10:04:33AM +0100, Jonathan Wakely wrote:
> > 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
> int main()
> {
> for (auto f : std::filesystem::directory_iterator("."))
>;
> for (auto f : std::filesystem::recursive_directory_iterator("."))
>;
> }
So, that indeed fails with -O0 -std=c++17 -Wl,--no-demangle
https://paste.fedoraproject.org/paste/wvIxqaH37DYNn4b4Cfua~w
Unfortunately, at least judging from the libstdc++*debug symbols on riscv64
I've posted, it probably isn't just a matter of following, because while
some symbols like that are in, most of them are not.
E.g. the first one mentioned in the above paste is missing, the closest
constructor to
_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE1EEC1EOS5_
that is missing but needed by the binary is:
_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE1EEC1ERKSt10__weak_ptrIS2_LS4_1EESt9nothrow_t
I've tried to simulate this on x86_64 by hand-editing c++config.h to
-#define _GLIBCXX_HAVE_ATOMIC_LOCK_POLICY 1
+/* #undef _GLIBCXX_HAVE_ATOMIC_LOCK_POLICY */
but then after make clean; make -j32 in libstdc++ objdir I don't see any
__shared_ptr.*_Lock_policyE symbols.
--- libstdc++-v3/config/abi/pre/gnu.ver.jj 2019-04-26 17:37:44.807122357
+0200
+++ libstdc++-v3/config/abi/pre/gnu.ver 2019-04-30 11:47:03.962801721 +0200
@@ -2234,17 +2234,17 @@ GLIBCXX_3.4.26 {
_ZNSt10filesystem7__cxx1128recursive_directory_iteratoraSEOS1_;
_ZNSt10filesystem7__cxx1128recursive_directory_iteratorppEv;
-
_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_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE[012]EEC1Ev;
+
_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE[012]EEC1EOS4_;
+
_ZNSt12__shared_ptrINSt10filesystem4_DirELN9__gnu_cxx12_Lock_policyE[012]EEaSEOS4_;
+
_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE[012]EEC1Ev;
+
_ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE[012]EEC1EOS5_;
-
_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_;
+
_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE[012]EEC1Ev;
+
_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE[012]EEC1EOS5_;
+
_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE[012]EEaSEOS5_;
+
_ZNSt12__shared_ptrINSt10filesystem7__cxx1128recursive_directory_it
Re: [9/10 PATCH] Update riscv64-linux baseline_symbols.txt file
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
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.
Re: [9/10 PATCH] Update riscv64-linux baseline_symbols.txt file
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: _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 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. Note, there are many other _Lock_policyE2 symbols that aren't exported in x86_64-linux libstdc++.so.6 and many other _Lock_policyE1 symbols that aren't exported in riscv64-linux libstdc++.so.6. For reference, here is readelf -Wa libstdc++.so.6.*debug | grep _Lock_policyE from riscv64 debuginfo: $ readelf -Wa libstdc++.so.6.0.26-9.0.1-0.12.0.riscv64.fc31.riscv64.debug | grep _Lock_policyE 840: 0013d642 128 FUNCLOCAL DEFAULT 11 _ZNSt12__shared_ptrINSt10filesystem28recursive_directory_iterator10_Dir_stackELN9__gnu_cxx12_Lock_policyE1EE5resetEv 857: 001333d8 2 FUNCLOCAL DEFAULT 11 _ZNSt23_Sp_counted_ptr_inplaceINSt10filesystem7__cxx1116filesystem_error5_ImplESaIS3_ELN9__gnu_cxx12_Lock_policyE1EED2Ev 859: 001288c0 8 FUNCLOCAL DEFAULT 11 _ZNSt23_Sp_counted_ptr_inplaceINSt10filesystem7__cxx114_DirESaIS2_ELN9__gnu_cxx12_Lock_policyE1EED0Ev 862: 001b0ce824 OBJECT LOCAL DEFAULT 20 _ZTISt23_Sp_counted_ptr_inplaceINSt10filesystem28recursive_directory_iterator10_Dir_stackESaIS2_ELN9__gnu_cxx12_Lock_policyE1EE 867: 0013cee472 FUNCLOCAL DEFAULT 11 _ZNSt23_Sp_counted_ptr_inplaceINSt10filesystem28recurs
Re: [9/10 PATCH] Update riscv64-linux baseline_symbols.txt file
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. From what I can see in riscv/sync.md, there is 32 bit and 64 bit compare and swap, but not 16 bit (no idea why it doesn't emulate 8 bit and 16 bit cas using 32 bit one). 2019-04-30 Jakub Jelinek * config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Update. --- libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt.jj 2019-03-08 09:52:12.761367362 +0100 +++ libstdc++-v3/config/abi/post/riscv64-linux-gnu/baseline_symbols.txt 2019-04-30 09:51:49.819285891 +0200 @@ -338,7 +338,9 @@ FUNC:_ZNKSt10filesystem16filesystem_erro FUNC:_ZNKSt10filesystem16filesystem_error5path1Ev@@GLIBCXX_3.4.26 FUNC:_ZNKSt10filesystem16filesystem_error5path2Ev@@GLIBCXX_3.4.26 FUNC:_ZNKSt10filesystem18directory_iteratordeEv@@GLIBCXX_3.4.26 +FUNC:_ZNKSt10filesystem28recursive_directory_iterator17recursion_pendingEv@@GLIBCXX_3.4.26 FUNC:_ZNKSt10filesystem28recursive_directory_iterator5depthEv@@GLIBCXX_3.4.26 +FUNC:_ZNKSt10filesystem28recursive_directory_iterator7optionsEv@@GLIBCXX_3.4.26 FUNC:_ZNKSt10filesystem28recursive_directory_iteratordeEv@@GLIBCXX_3.4.26 FUNC:_ZNKSt10filesystem4path11parent_pathEv@@GLIBCXX_3.4.26 FUNC:_ZNKSt10filesystem4path12has_filenameEv@@GLIBCXX_3.4.26 @@ -364,7 +366,9 @@ FUNC:_ZNKSt10filesystem7__cxx1116filesys FUNC:_ZNKSt10filesystem7__cxx1116filesystem_error5path1Ev@@GLIBCXX_3.4.26 FUNC:_ZNKSt10filesystem7__cxx1116filesystem_error5path2Ev@@GLIBCXX_3.4.26 FUNC:_ZNKSt10filesystem7__cxx1118directory_iteratordeEv@@GLIBCXX_3.4.26 +FUNC:_ZNKSt10filesystem7__cxx1128recursive_directory_iterator17recursion_pendingEv@@GLIBCXX_3.4.26 FUNC:_ZNKSt10filesystem7__cxx1128recursive_directory_iterator5depthEv@@GLIBCXX_3.4.26 +FUNC:_ZNKSt10filesystem7__cxx1128recursive_directory_iterator7optionsEv@@GLIBCXX_3.4.26 FUNC:_ZNKSt10filesystem7__cxx1128recursive_directory_iteratordeEv@@GLIBCXX_3.4.26 FUNC:_ZNKSt10filesystem7__cxx114path11parent_pathEv@@GLIBCXX_3.4.26 FUNC:_ZNKSt10filesystem7__cxx114path12has_filenameEv@@GLIBCXX_3.4.26 @@ -1804,6 +1808,7 @@ FUNC:_ZNSt10filesystem18create_directori FUNC:_ZNSt10filesystem18create_directoriesERKNS_4pathERSt10error_code@@GLIBCXX_3.4.26 FUNC:_ZNSt10filesystem18create_directoriesERKNS_7__cxx114pathE@@GLIBCXX_3.4.26 FUNC:_ZNSt10filesystem18create_directoriesERKNS_7__cxx114pathERSt10error_code@@GLIBCXX_3.4.26 +FUNC:_ZNSt10filesystem18directory_iterator9incrementERSt10error_code@@GLIBCXX_3.4.26 FUNC:_ZNSt10filesystem18directory_iteratorC1ERKNS_4pathENS_17directory_optionsEPSt10error_code@@GLIBCXX_3.4.26 FUNC:_ZNSt10filesystem18directory_iteratorC2ERKNS_4pathENS_17directory_optionsEPSt10error_code@@GLIBCXX_3.4.26 FUNC:_ZNSt10filesystem18directory_iteratorppEv@@GLIBCXX_3.4.26 @@ -1815,6 +1820,7 @@ FUNC:_ZNSt10filesystem24create_directory FUNC:_ZNSt10filesystem24create_directory_symlinkERKNS_4pathES2_RSt10error_code@@GLIBCXX_3.4.26 FUNC:_ZNSt10filesystem24create_directory_symlinkERKNS_7__cxx114pathES
