From owner-freebsd-current@freebsd.org Sat Oct 7 15:40:09 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82703E3AEFF for ; Sat, 7 Oct 2017 15:40:09 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-18.reflexion.net [208.70.210.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E1F897409A for ; Sat, 7 Oct 2017 15:40:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 29345 invoked from network); 7 Oct 2017 15:40:06 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 7 Oct 2017 15:40:06 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 07 Oct 2017 11:40:06 -0400 (EDT) Received: (qmail 31464 invoked from network); 7 Oct 2017 15:40:06 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 7 Oct 2017 15:40:06 -0000 Received: from [192.168.1.26] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 01030EC8559; Sat, 7 Oct 2017 08:40:05 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: C++ in jemalloc From: Mark Millard In-Reply-To: <20171007102151.GA84155@vlakno.cz> Date: Sat, 7 Oct 2017 08:40:05 -0700 Cc: Justin Hibbits , Warner Losh , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <528ED3CD-8A4B-4F00-8728-7D231DB0811A@dsl-only.net> <20171007064249.GA73770@vlakno.cz> <934C1C1A-1303-4A8C-9E80-4259E475220A@dsl-only.net> <20171007102151.GA84155@vlakno.cz> To: Roman Divacky X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 15:40:09 -0000 On 2017-Oct-7, at 3:21 AM, Roman Divacky wrote: > Answers inline. >=20 > On Sat, Oct 07, 2017 at 03:13:43AM -0700, Mark Millard wrote: >> Just a short top-post as this does not fit well with the >> other material: >>=20 >> I believe Roman only built his example program >> with clang, not the world that the program was >> being run under. >=20 > I used a machine with gcc built world and compiled the test program = using=20 >=20 > clang -stdlib=3Dlibstdc++ There is (and was) no libstdc++ in my context. So I'd have to build a clang based world that had it first. Note: Nothing that I've been saying indicates if what you found earlier was a separate issue as far as I know. >> The gcc 4.2.1 based code that is analogous to >> __cxa_begin_catch (scratch register initialization) >> in a clang based build world has the scratch >> register CFI material and the same clang produced >> a.out file works fine under such a system (simply >> copied over and run). >>=20 >> And that is why Roman's context did not SIGSEGV but >> mine did: I used clang for the buildworld for >> the world that was being used and so >> __cxa_begin_catch was missing CFI information in >> my build. >>=20 >> In fact the a.out built by gcc 4.2.1 fails under >> the clang based buildworld with the bad >> __cxa_begin_catch . >>=20 >> The only thing that matters is the system library >> code involved, not which a.out (from which compiler). >=20 > Ah. I see... Is it possible to isolate a small example > that shows the missing CFI info from clang so that I can > try to fix it without having to build world etc. ? >=20 > It should be reasonably simple. The following (using lang/gcc7 as an example) in a clang-built world also gets a SIGSEGV: # env C_INCLUDE_PATH=3D/usr/include = CPLUS_INCLUDE_PATH=3D/usr/include/c++/v1 /usr/local/bin/g++7 -std=3Dc++11 = -nostdinc++ -L/usr/lib -g -O2 exception_test.cpp # ldd a.out a.out: libc++.so.1 =3D> /usr/lib/libc++.so.1 (0x5004f000) libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x5017c000) libm.so.5 =3D> /lib/libm.so.5 (0x501a3000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x501db000) libc.so.7 =3D> /lib/libc.so.7 (0x50200000) # ./a.out Segmentation fault (core dumped) #0 0x00000000501dfc20 in _Unwind_SetGR (context=3D, index=3D, val=3D1342451808) at = unwind-dw2-fde.h:162 162 { (gdb) bt #0 0x00000000501dfc20 in _Unwind_SetGR (context=3D, index=3D, val=3D1342451808) at = unwind-dw2-fde.h:162 #1 0x0000000050191194 in __gxx_personality_v0 (version=3D, actions=3D, exceptionClass=3D, exceptionObject=3D0x50043060,=20 context=3D0xffffffffffffcc80) at = /usr/src/contrib/libcxxrt/exception.cc:1203 #2 0x00000000501e0a60 in _Unwind_RaiseException_Phase2 (exc=3D0x50043060,= context=3D0xffffffffffffcc80) at unwind.inc:66 #3 0x00000000501e0548 in _Unwind_RaiseException (exc=3D) at unwind.inc:135 #4 0x00000000501904f4 in __cxa_throw (thrown_exception=3D, tinfo=3D, dest=3D) at /usr/src/contrib/libcxxrt/exception.cc:774 #5 0x0000000010000898 in ?? () compared to system-clang's: #0 0x0000000050530c20 in _Unwind_SetGR (context=3D, index=3D, val=3D1342447712) at = unwind-dw2-fde.h:162 162 { (gdb) bt #0 0x0000000050530c20 in _Unwind_SetGR (context=3D, index=3D, val=3D1342447712) at = unwind-dw2-fde.h:162 #1 0x0000000050190194 in __gxx_personality_v0 (version=3D, actions=3D, exceptionClass=3D, exceptionObject=3D0x50042060,=20 context=3D0xffffffffffffcc60) at = /usr/src/contrib/libcxxrt/exception.cc:1203 #2 0x0000000050531a60 in _Unwind_RaiseException_Phase2 (exc=3D0x50042060,= context=3D0xffffffffffffcc60) at unwind.inc:66 #3 0x0000000050531548 in _Unwind_RaiseException (exc=3D) at unwind.inc:135 #4 0x000000005018f4f4 in __cxa_throw (thrown_exception=3D, tinfo=3D, dest=3D) at /usr/src/contrib/libcxxrt/exception.cc:774 #5 0x0000000010000d74 in main () at exception_test.cpp:5 #6 0x0000000010000ae8 in _start (argc=3D1342447624, argv=3D0x50042060, = env=3D0xffffffffffffcc60, obj=3D, cleanup=3D, ps_strings=3D) at /usr/src/lib/csu/powerpc64/crt1.c:94 #7 0x0000000050017b70 in .text () at = /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 Current language: auto; currently minimal The code generation involved is tied to (driven by) the use of builtins, not just normal C/C++ code. Inlining is also mixed in. There could be more wrong than I've noticed. At some point comparing the dwarfdump output for gcc and clang for the same "interesting" source(s) being compiled would be appropriate, looking for mismatches that are not equivalent. (Unfortunately equivalence need not be a trivial judgment to make since CFI is a programming language of its own and the code being described is not identical, possibly inlined differently even.) So I'm building based on devel/powerpc64-xtoolchain-gcc using WITH_LIBCPLUSPLUS=3D to compare against. (I've not done a powerpc64-xtoolchain-gcc based build in a long time. Hopefully it still builds to completion.) It is far enough along now to have built a libcxxrt.so.1 so. . . But I need sleep. (It is well after 8am here.) All I'm managing to do is confuse myself at this point. I may have been wrong about where the scratch register initialization is inside the library, I'm not sure. =3D=3D=3D Mark Millard markmi at dsl-only.net