[Bug 221288] lang/gcc5 links against libsupc++ when compiling

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221288

--- Comment #5 from Mark Millard <markmi at dsl-only.net> ---
I suspect this mix of infrastructures ties in to
why standard c++ threading fails under the likes
of g++6 compiles while the code works when compiled
and linked via system clang++ 5. The infrastructure
issues may extend to the libgcc_s that is used as
well.

(The program here is just one that I happen to have
around, not minimized, but standard C++ code only.)

Starting without an explicit -pthread :

g++6 -std=c++14 -Wpedantic -Wall -Wl,-rpath=/usr/local/lib/gcc6 -O2
cpp_clocks_investigation.cpp

(So no -pthread explicitly.)

Note the lack of both libthr.so.3 and libcxxrt.so.1 in
the below. Also the libgcc_s being from gcc6 materials.

# ldd a.out
a.out:
        libstdc++.so.6 => /usr/local/lib/gcc6/libstdc++.so.6 (0x800844000)
        libm.so.5 => /lib/libm.so.5 (0x800bd9000)
        libgcc_s.so.1 => /usr/local/lib/gcc6/libgcc_s.so.1 (0x800e06000)
        libc.so.7 => /lib/libc.so.7 (0x80101d000)

leads to:

static inline int
__gthread_create (__gthread_t *__threadid, void *(*__func) (void*),
                  void *__args)
{ 
  return __gthrw_(pthread_create) (__threadid, NULL, __func, __args);
}

getting SIGSEGV from pthread_create not having a good address.



With -pthread the a.out produced gets a SIGSEGV in infrustrature.
Showing similar to the above information:

g++6 -std=c++14 -Wpedantic -Wall -pthread -Wl,-rpath=/usr/local/lib/gcc6 -O2
cpp_clocks_investigation.cpp

Note the libthr.so.3 but the lack of libcxxrt.so.1 in
the below.  Also the libgcc_s being from gcc6 materials.

# ldd a.out
a.out:
        libstdc++.so.6 => /usr/local/lib/gcc6/libstdc++.so.6 (0x800844000)
        libm.so.5 => /lib/libm.so.5 (0x800bd9000)
        libgcc_s.so.1 => /usr/local/lib/gcc6/libgcc_s.so.1 (0x800e06000)
        libthr.so.3 => /lib/libthr.so.3 (0x80101d000)
        libc.so.7 => /lib/libc.so.7 (0x801245000)

(run in /usr/local/bin/gdb :)

Thread 11 received signal SIGSEGV, Segmentation fault.
[Switching to LWP 100288 of process 18022]
uw_frame_state_for (context=context at entry=0x7fffdfdfce20,
fs=fs at entry=0x7fffdfdfcb70) at
/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind-dw2.c:1249
1249          return MD_FALLBACK_FRAME_STATE_FOR (context, fs);
(gdb) bt
#0  uw_frame_state_for (context=context at entry=0x7fffdfdfce20,
fs=fs at entry=0x7fffdfdfcb70) at
/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind-dw2.c:1249
#1  0x0000000800e1602b in _Unwind_ForcedUnwind_Phase2
(exc=exc at entry=0x80069cc30, context=context at entry=0x7fffdfdfce20) at
/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind.inc:155
#2  0x0000000800e16364 in _Unwind_ForcedUnwind (exc=0x80069cc30,
stop=0x801033450 <thread_unwind_stop>, stop_argument=<optimized out>)
    at
/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind.inc:207
#3  0x00000008010332b3 in _Unwind_ForcedUnwind (ex=<optimized out>,
stop_func=0x7fffdfdfc948, stop_arg=0x80069ca00) at
/usr/src/lib/libthr/thread/thr_exit.c:106
#4  thread_unwind () at /usr/src/lib/libthr/thread/thr_exit.c:172
#5  _pthread_exit_mask (status=<optimized out>, mask=<optimized out>) at
/usr/src/lib/libthr/thread/thr_exit.c:254
#6  0x00000008010330db in _pthread_exit (status=0x80069ca00) at
/usr/src/lib/libthr/thread/thr_exit.c:206
#7  0x0000000801025c0d in thread_start (curthread=0x80069ca00) at
/usr/src/lib/libthr/thread/thr_create.c:289
#8  0x00007fffdfbfd000 in ?? ()
Backtrace stopped: Cannot access memory at address 0x7fffdfdfd000

Note #3 -> #4 goes from:

/usr/src/lib/libthr/thread/thr_exit.c:
to:
/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind.inc

So: from system libthr to gcc6's libgcc .

System clang++ 5 with -pthread (link fails without it):

clang++ -std=c++14 -Wpedantic -Wall -pthread cpp_clocks_investigation.cpp 

# ldd a.out
a.out:
        libc++.so.1 => /usr/lib/libc++.so.1 (0x8008a6000)
        libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x800b72000)
        libm.so.5 => /lib/libm.so.5 (0x800d90000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x800fbd000)
        libthr.so.3 => /lib/libthr.so.3 (0x8011d3000)
        libc.so.7 => /lib/libc.so.7 (0x8013fb000)

This a.out runs to completion just fine.

-- 
You are receiving this mail because:
You are the assignee for the bug.