[Bug 278333] clang-18 crashes on the port audio/noise-suppression-for-voice-lv2: Assertion failed: (result && "no existing substitution for template name"), function mangleExistingSubstitution, file [
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278333 --- Comment #3 from Dimitry Andric --- Created attachment 250214 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=250214&action=edit audio/noise-suppression-for-voice-lv2: fix build with clang 18 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 --- Comment #19 from Mark Millard --- (In reply to Mark Millard from comment #18) Whaat says that the two /wrkdirs/usr/ports/lang/gcc13/work/gcc-13.2.0/libgcc/* source files referenced are compatible with the otherwise-FreeBSD-specific source code files referenced? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 --- Comment #18 from Mark Millard --- FYI: I got more source code path information from a gdb based run. The context used g++13 but the system has symbols as well. I keep a main-src worktree that holds a copy of the main branch materials. Thus the /usr/main-src/ in my paths. (gdb) run Starting program: /usr/home/root/c_tests/g++-static-link-test [New LWP 249477 of process 56713] kernel Thread 2 received signal SIGABRT, Aborted. Sent by thr_kill() from pid 56713 and user 0. [Switching to LWP 249477 of process 56713] thr_kill () at thr_kill.S:4 4 RSYSCALL(thr_kill) (gdb) bt #0 thr_kill () at thr_kill.S:4 #1 0x004c283f in __raise (s=s@entry=6) at /usr/main-src/lib/libc/gen/raise.c:48 #2 0x004df3d9 in abort () at /usr/main-src/lib/libc/stdlib/abort.c:61 #3 0x00402be5 in uw_init_context_1 (context=context@entry=0x7fffdfffdd50, outer_cfa=outer_cfa@entry=0x7fffdfffdf80, outer_ra=0x4b2fc6 ) at /wrkdirs/usr/ports/lang/gcc13/work/gcc-13.2.0/libgcc/unwind-dw2.c:1336 #4 0x004ae786 in _Unwind_ForcedUnwind (exc=0x800818940, stop=0x4b3170 , stop_argument=stop_argument@entry=0x0) at /wrkdirs/usr/ports/lang/gcc13/work/gcc-13.2.0/libgcc/unwind.inc:212 #5 0x004b2fc6 in thread_unwind () at /usr/main-src/lib/libthr/thread/thr_exit.c:172 #6 0x004b2f2c in _pthread_exit_mask (status=0x0, mask=mask@entry=0x0) at /usr/main-src/lib/libthr/thread/thr_exit.c:254 #7 0x004b2e9b in _Tthr_exit (status=0x3ce85) at /usr/main-src/lib/libthr/thread/thr_exit.c:206 #8 0x004b2b0d in thread_start (curthread=0x800818700) at /usr/main-src/lib/libthr/thread/thr_create.c:289 #9 0x in ?? () Backtrace stopped: Cannot access memory at address 0x7fffdfffe000 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 --- Comment #17 from Mohammed Goder --- (In reply to Ed Maste from comment #16) I did some further testing and I'm pretty sure that it's a clang issue. I remember using the flag on Windows, MacOS, and Linux but it seems as though either my memory is bad or they removed support for the flag on Windows and MacOS; and left it in an unstable state on Linux. My memory might be conflating using GCC's shadow stack with clang's safe-stack. Either way; Thanks a bunch. I'll leave you guys to solve the GCC problem. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 --- Comment #16 from Ed Maste --- (In reply to Mohammed Goder from comment #14) > Should I make another bug report on FreeBSD's bug tracker or should this go > to the clang > devs? If you can get a minimized reproducer and exact reproduction steps, please go ahead and submit a FreeBSD bug. Issues that affect 3rd party FreeBSD base system software could be clearly upstream issues, could be clearly FreeBSD issues, or (as is the case here) might not be obvious or might be somewhere in between, so it's most reasonable for FreeBSD folks to do an initial triage before sending upstream. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 --- Comment #15 from Mohammed Goder --- (In reply to Mohammed Goder from comment #14) Actually slight correction. Clang's safe-stack does not work on OpenBSD. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 --- Comment #14 from Mohammed Goder --- Thank you guys for your hard work and dedication. I found the issue with clang++. The "-fsanitize=safe-stack" flag causes a segfault on FreeBSD. GCC's equivalent "-mshstk" works fine and Clang's safe-stack works on OpenBSD, Linux, Windows, and MacOS. Should I make another bug report on FreeBSD's bug tracker or should this go to the clang devs? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 --- Comment #13 from Ed Maste --- I'm using the gcc13 package, and adding -v to my g++13 command line shows the link invocation as: /usr/local/libexec/gcc13/gcc/x86_64-portbld-freebsd14.0/13.2.0/collect2 -plugin /usr/local/libexec/gcc13/gcc/x86_64-portbld-freebsd14.0/13.2.0/liblto_plugin.so -plugin-opt=/usr/local/libexec/gcc13/gcc/x86_64-portbld-freebsd14.0/13.2.0/lto-wrapper -plugin-opt=-fresolution=/tmp//cc3JPuk2.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_eh -plugin-opt=-pass-through=-lpthread -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_eh -m elf_x86_64_fbsd -V -Bstatic -o main_g++ /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbeginT.o -L/usr/local/lib/gcc13/gcc/x86_64-portbld-freebsd14.0/13.2.0 -L/usr/local/lib/gcc13/gcc/x86_64-portbld-freebsd14.0/13.2.0/../../../../../x86_64-portbld-freebsd14.0/lib -L/usr/local/lib/gcc13/gcc/x86_64-portbld-freebsd14.0/13.2.0/../../.. --eh-frame-hdr /tmp//ccQ9SSiv.o -lstdc++ -lm -lgcc -lgcc_eh -lpthread -lc -lgcc -lgcc_eh /usr/local/lib/gcc13/gcc/x86_64-portbld-freebsd14.0/13.2.0/crtend.o /usr/lib/crtn.o So looks like it should be libstdc++. Perhaps there's a newly-introduced issue, or a patch that exists only in the ports tree? -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 --- Comment #12 from Konstantin Belousov --- (In reply to Ed Maste from comment #11) Perhaps you do use libc++ from base indeed. I tried with the manual gcc build from sources, and got the destructor faulting. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 --- Comment #11 from Ed Maste --- I did not reproduce a problem with g++13, with -Wl,--eh-frame-hdr: $ g++13 -Wl,--eh-frame-hdr -std=c++20 -static-libgcc -static-libstdc++ -static -pthread -O3 "main.cpp" -o "main_g++" && ./main_g++ kernel FreeBSD RELEASE 14.0 doesn't reach here. $ -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 --- Comment #10 from Mark Millard --- (In reply to Mohammed Goder from comment #0) If gcc is to be involved, a question may be if -Wl,-rpath=/usr/local/lib/gcc* for the appropriate * substitution is needed. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 Ed Maste changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=114839 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551
--- Comment #9 from Ed Maste ---
from g++13 -dumpspecs it looks like --eh-frame-header is not included for
statically linked binaries
*link:
%{!static|static-pie:--eh-frame-hdr} %{m32:-m elf_i386_fbsd}%{!m32:-m
elf_x86_64_fbsd} %{p:%nconsider using '-pg' instead of '-p' with gprof(1)}
%{v:-V} %{assert*} %{R*} %{rpath*} %{defsym*} %{shared:-Bshareable %{h*}
%{soname*}} %{!shared: %{!static: %{rdynamic:-export-dynamic}
-dynamic-linker %(fbsd_dynamic_linker) } %{static:-Bstatic}}
%{symbolic:-Bsymbolic}
I've opened a GCC bug for this:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114839
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 --- Comment #8 from Konstantin Belousov --- (In reply to Ed Maste from comment #6) -Wl,--eh-frame-hdr indeed help with the unwinder in thread_exit. There is one more bug meantime, (gdb) r Starting program: /usr/home/kostik/work/DEV/tests/pr278551 [New LWP 308137 of process 11609] kernel [LWP 308137 of process 11609 exited] FreeBSD RELEASE 14.0 doesn't reach here. Thread 1 received signal SIGSEGV, Segmentation fault. Invalid permissions for mapped object. 0x005aec00 in (anonymous namespace)::moneypunct_cache_ct () (gdb) bt #0 0x005aec00 in (anonymous namespace)::moneypunct_cache_ct () #1 0x004032bf in __do_global_dtors_aux () #2 0x005400a5 in _fini () #3 0x004dfaff in __cxa_finalize () #4 0x004dfede in exit () #5 0x004bf93f in __libc_start1 () #6 0x00403298 in _start () -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 Mark Millard changed: What|Removed |Added CC||marklmi26-f...@yahoo.com --- Comment #7 from Mark Millard --- (In reply to Ed Maste from comment #6) -lc++ is not using libstdc++ but is using clang's libc++ instead. The command is not comparible to the failing context's use of libstdc++ . -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 --- Comment #6 from Ed Maste --- If I link using Clang as the compiler driver (using either the ld.lld default, or ld.bfd) it works. The linker command line in the bfd case is: "/usr/local/bin/ld.bfd" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --hash-style=both --enable-new-dtags -o static-except /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/lib static-except.o -lc++ -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/crtend.o /usr/lib/crtn.o On a quick look it appears GCC fails to pass `--eh-frame-header` -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278551] lang/gcc: exceptions do not work in statically linked binaries
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 Ed Maste changed: What|Removed |Added Product|Base System |Ports & Packages Version|14.0-RELEASE|Latest Component|threads |Individual Port(s) Summary|pthread_join() kills the|lang/gcc: exceptions do not |process with a return code |work in statically linked |of 134 |binaries -- You are receiving this mail because: You are the assignee for the bug.
[Bug 278551] pthread_join() kills the process with a return code of 134
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551
--- Comment #5 from Ed Maste ---
I can reproduce this with GCC 10, 11, 12, and 13. I cannot reproduce this with
Clang 16 or 17.
$ clang++16 -std=c++20 -static-libgcc -static-libstdc++ -static -pthread -O3
"main.cpp" -o "main_clang++" && ./main_clang++
clang-16: warning: argument unused during compilation: '-static-libgcc'
[-Wunused-command-line-argument]
clang-16: warning: argument unused during compilation: '-static-libstdc++'
[-Wunused-command-line-argument]
kernel
FreeBSD RELEASE 14.0 doesn't reach here.
$ clang++17 -std=c++20 -static-libgcc -static-libstdc++ -static -pthread -O3
"main.cpp" -o "main_clang++" && ./main_clang++
clang++: warning: argument unused during compilation: '-static-libgcc'
[-Wunused-command-line-argument]
clang++: warning: argument unused during compilation: '-static-libstdc++'
[-Wunused-command-line-argument]
kernel
FreeBSD RELEASE 14.0 doesn't reach here.
It's reproducible with any exception with GCC:
static-except.cc:
int fn(void) { throw (int)0; }
int main(int argc, char *argv[])
{
try {
fn();
} catch (int i) {
return 0;
}
return 1;
}
$ g++13 -static static-except.cc -o static-except && ./static-except
Abort trap (core dumped)
I'll change this to a lang/gcc bug
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 278551] pthread_join() kills the process with a return code of 134
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278551 Konstantin Belousov changed: What|Removed |Added CC||salvad...@freebsd.org Assignee|thre...@freebsd.org |toolchain@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug.
