Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 08 Aug 2017 18:52:05 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-toolchain@FreeBSD.org
Subject:   [Bug 221288] lang/gcc5 links against libsupc++ when compiling
Message-ID:  <bug-221288-29464-bgWHSIZkNL@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-221288-29464@https.bugs.freebsd.org/bugzilla/>
References:  <bug-221288-29464@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221288

--- Comment #5 from Mark Millard <markmi@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=3Dc++14 -Wpedantic -Wall -Wl,-rpath=3D/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 =3D> /usr/local/lib/gcc6/libstdc++.so.6 (0x800844000)
        libm.so.5 =3D> /lib/libm.so.5 (0x800bd9000)
        libgcc_s.so.1 =3D> /usr/local/lib/gcc6/libgcc_s.so.1 (0x800e06000)
        libc.so.7 =3D> /lib/libc.so.7 (0x80101d000)

leads to:

static inline int
__gthread_create (__gthread_t *__threadid, void *(*__func) (void*),
                  void *__args)
{=20
  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=3Dc++14 -Wpedantic -Wall -pthread -Wl,-rpath=3D/usr/local/lib/gcc=
6 -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 =3D> /usr/local/lib/gcc6/libstdc++.so.6 (0x800844000)
        libm.so.5 =3D> /lib/libm.so.5 (0x800bd9000)
        libgcc_s.so.1 =3D> /usr/local/lib/gcc6/libgcc_s.so.1 (0x800e06000)
        libthr.so.3 =3D> /lib/libthr.so.3 (0x80101d000)
        libc.so.7 =3D> /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=3Dcontext@entry=3D0x7fffdfdfce20,
fs=3Dfs@entry=3D0x7fffdfdfcb70) at
/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind-dw2.c:1=
249
1249          return MD_FALLBACK_FRAME_STATE_FOR (context, fs);
(gdb) bt
#0  uw_frame_state_for (context=3Dcontext@entry=3D0x7fffdfdfce20,
fs=3Dfs@entry=3D0x7fffdfdfcb70) at
/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind-dw2.c:1=
249
#1  0x0000000800e1602b in _Unwind_ForcedUnwind_Phase2
(exc=3Dexc@entry=3D0x80069cc30, context=3Dcontext@entry=3D0x7fffdfdfce20) at
/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind.inc:155
#2  0x0000000800e16364 in _Unwind_ForcedUnwind (exc=3D0x80069cc30,
stop=3D0x801033450 <thread_unwind_stop>, stop_argument=3D<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=3D<optimized out>,
stop_func=3D0x7fffdfdfc948, stop_arg=3D0x80069ca00) 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=3D<optimized out>, mask=3D<optimized out>) at
/usr/src/lib/libthr/thread/thr_exit.c:254
#6  0x00000008010330db in _pthread_exit (status=3D0x80069ca00) at
/usr/src/lib/libthr/thread/thr_exit.c:206
#7  0x0000000801025c0d in thread_start (curthread=3D0x80069ca00) 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=3Dc++14 -Wpedantic -Wall -pthread cpp_clocks_investigation.cpp=
=20

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

This a.out runs to completion just fine.

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-221288-29464-bgWHSIZkNL>