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

[Jonathan Wakely]

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 <filesystem>
>> 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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.txt
Type: text/x-patch
Size: 2528 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20190430/51b58cf9/attachment.bin>