[Bug 248795] std::random_shuffle broken with LLVM11
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248795 --- Comment #2 from commit-h...@freebsd.org --- A commit references this bug: Author: dim Date: Sat Aug 22 12:05:12 UTC 2020 New revision: 364482 URL: https://svnweb.freebsd.org/changeset/base/364482 Log: Add a few new source files to libc++, in particular the implementation part of std::random_shuffle. These were split off at some point by upstream, but I forgot to add them to our Makefile. This should allow some ports which use std::random_shuffle to correctly link again. Reported by: thierry PR: 248795 MFC after:6 weeks X-MFX-With: r364284 Changes: head/lib/libc++/Makefile -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 248795] std::random_shuffle broken with LLVM11
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248795 Thierry Thomas changed: What|Removed |Added CC||thie...@freebsd.org --- Comment #1 from Thierry Thomas --- Same error for the port math/hpcombi: [14/22] : && /usr/bin/c++ -O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -fstack-protector-strong -L/usr/local/lib benchmark/CMakeFiles/sort.dir/sort.cpp.o -o benchmark/sort -lbenchmark -lpthread && : FAILED: benchmark/sort : && /usr/bin/c++ -O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -fstack-protector-strong -L/usr/local/lib benchmark/CMakeFiles/sort.dir/sort.cpp.o -o benchmark/sort -lbenchmark -lpthread && : ld: error: undefined symbol: std::__1::__rs_default::~__rs_default() >>> referenced by algorithm:3112 (/usr/include/c++/v1/algorithm:3112) >>> benchmark/CMakeFiles/sort.dir/sort.cpp.o:(rand_perms(int)) >>> referenced by algorithm:3112 (/usr/include/c++/v1/algorithm:3112) >>> benchmark/CMakeFiles/sort.dir/sort.cpp.o:(rand_perms(int)) ld: error: undefined symbol: std::__1::__rs_get() >>> referenced by algorithm:3105 (/usr/include/c++/v1/algorithm:3105) >>> benchmark/CMakeFiles/sort.dir/sort.cpp.o:(rand_perms(int)) ld: error: undefined symbol: std::__1::__rs_default::operator()() >>> referenced by algorithm:2950 (/usr/include/c++/v1/algorithm:2950) >>> benchmark/CMakeFiles/sort.dir/sort.cpp.o:(long std::__1::uniform_int_distribution::operator()(s td::__1::__rs_default&, std::__1::uniform_int_distribution::param_type const&)) >>> referenced by algorithm:2950 (/usr/include/c++/v1/algorithm:2950) >>> benchmark/CMakeFiles/sort.dir/sort.cpp.o:(long std::__1::uniform_int_distribution::operator()(s td::__1::__rs_default&, std::__1::uniform_int_distribution::param_type const&)) >>> referenced by algorithm:2950 (/usr/include/c++/v1/algorithm:2950) >>> benchmark/CMakeFiles/sort.dir/sort.cpp.o:(long std::__1::uniform_int_distribution::operator()(s td::__1::__rs_default&, std::__1::uniform_int_distribution::param_type const&)) >>> referenced 1 more times c++: error: linker command failed with exit code 1 (use -v to see invocation) -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 248745] /usr/bin/lldb dumps core when attempting to print variable with `p`, `fr v` works
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248745
--- Comment #1 from commit-h...@freebsd.org ---
A commit references this bug:
Author: dim
Date: Sat Aug 22 10:55:55 UTC 2020
New revision: 364480
URL: https://svnweb.freebsd.org/changeset/base/364480
Log:
Merge commit 1ce07cd614be from llvm git (by me):
Instantiate Error in Target::GetEntryPointAddress() only when
necessary
When Target::GetEntryPointAddress() calls
exe_module->GetObjectFile()->GetEntryPointAddress(), and the returned
entry_addr is valid, it can immediately be returned.
However, just before that, an llvm::Error value has been setup, but
in this case it is not consumed before returning, like is done
further below in the function.
In https://bugs.freebsd.org/248745 we got a bug report for this,
where a very simple test case aborts and dumps core:
* thread #1, name = 'testcase', stop reason = breakpoint 1.1
frame #0: 0x002018d4 testcase`main(argc=1,
argv=0x7fffea18) at testcase.c:3:5
1int main(int argc, char *argv[])
2{
-> 3return 0;
4}
(lldb) p argc
Program aborted due to an unhandled Error:
Error value was Success. (Note: Success values must still be checked prior
to being destroyed).
Thread 1 received signal SIGABRT, Aborted.
thr_kill () at thr_kill.S:3
3 thr_kill.S: No such file or directory.
(gdb) bt
#0 thr_kill () at thr_kill.S:3
#1 0x0008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52
#2 0x000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67
#3 0x0451b5f5 in fatalUncheckedError () at
/usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112
#4 0x019cf008 in GetEntryPointAddress () at
/usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267
#5 0x01bccbd8 in ConstructorSetup () at
/usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67
#6 0x01bcd2c0 in ThreadPlanCallFunction () at
/usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114
#7 0x020076d4 in InferiorCallMmap () at
/usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97
#8 0x01f4be33 in DoAllocateMemory () at
/usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604
#9 0x01fe51b9 in AllocatePage () at
/usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347
#10 0x01fe5385 in AllocateMemory () at
/usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383
#11 0x01974da2 in AllocateMemory () at
/usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301
#12 CanJIT () at
/usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331
#13 0x01a1bf3d in Evaluate () at
/usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190
#14 0x019ce7a2 in EvaluateExpression () at
/usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372
#15 0x01ad784c in EvaluateExpression () at
/usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414
#16 0x01ad86ae in DoExecute () at
/usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646
#17 0x01a5e3ed in Execute () at
/usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003
#18 0x01a6c4a3 in HandleCommand () at
/usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762
#19 0x01a6f98c in IOHandlerInputComplete () at
/usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760
#20 0x01a90b08 in Run () at
/usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548
#21 0x019a6c6a in ExecuteIOHandlers () at
/usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903
#22 0x01a70337 in RunCommandInterpreter () at
/usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946
#23 0x01d9d812 in RunCommandInterpreter () at
/usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169
#24 0x01918be8 in MainLoop () at
/usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675
#25 0x0191a114 in main () at
/usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:890
Fix the incorrect error catch by only instantiating an Error object
if it is necessary.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D86355
This should fix lldb aborting as described in the scenario above.
Reported by: dmgk
PR: 248745
Changes:
head/contrib/llvm-project/lldb/source/Target/Target.cpp
--
You are receiving this mail because:
You are the assignee for the bug.
___
Re: /usr/lib/libomp.so : is there a reason that aarch64 does not have such by default?
On August 21, 2020 6:52:23 PM UTC, Mark Millard via freebsd-arm wrote: >My context: head ( currently at -r363590 ) > >man src.conf is explicit that WITHOUT_OPENMP is the default for >aarch64 (for example). [...] >Nothing stands out for why WITH_OPENMP is in use by default only >for amd64, i386, and powerpc64. Because nobody has bothered to merge https://reviews.freebsd.org/D21167 ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
