From owner-freebsd-current@freebsd.org Sun Oct 8 06:36:19 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 2B6D4E29A47 for ; Sun, 8 Oct 2017 06:36:19 +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 958DB6F0B9 for ; Sun, 8 Oct 2017 06:36:18 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 25026 invoked from network); 8 Oct 2017 06:36:17 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 8 Oct 2017 06:36:17 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 08 Oct 2017 02:36:17 -0400 (EDT) Received: (qmail 28899 invoked from network); 8 Oct 2017 06:36:16 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 8 Oct 2017 06:36:16 -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 0D120EC90BC; Sat, 7 Oct 2017 23:36:16 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: C++ in jemalloc Date: Sat, 7 Oct 2017 23:36:15 -0700 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 , Justin Hibbits , Warner Losh , FreeBSD Current In-Reply-To: Message-Id: <08CBC862-4EAB-4864-B689-1949329EF3CE@dsl-only.net> 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: Sun, 08 Oct 2017 06:36:19 -0000 With a fresh day after sleep and some pondering I finally am thinking straight for where things are in files for C++ scratch register usage and such: It is libgcc_s.so.1 that has all the extra use of scratch registers for C++ exception handling --and lots of other special stuff as well. This note is just about overall counts of example usages in devel/powerpc64-gcc vs. clang processing the same libgcc_s source. it gives a clue about what coverage is going to be necessary. So the compare/contrast is of: (shown as seen in my context) # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 vs. # dwarfdump -v -v -F /lib/libgcc_s.so.1 (That last being from a clang-based buildworld and the first being from a devel/powerpc64-xtoolchain-gcc material based buildworld.) Using r2 through r6 as initial examples: # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 | grep "\" | wc 43 2683 18432 vs. # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "\" | wc 0 0 0 That is an example of missing information from clang. For powerpc64-gcc it is interesting that. . . # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 | grep "\" | wc 23 2063 14308 but: # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 | grep "\" | wc 27 2571 17800 # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 | grep "\" | wc 27 2571 17800 # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 | grep "\" | wc 27 2571 17800 # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 | grep "\" | wc 27 2571 17800 and: # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 | grep "\" | wc 0 0 0 # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 | grep "\" | wc 0 0 0 # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 | grep "\" | wc 0 0 0 Looks like r2 might sometimes be a scratch or otherwise special register during C++ exception handling --but not everyplace that r3-r6 are. There are lots of other special r names with numerals beyond that in the name r31 (powerpc64-gcc context): # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 | grep "r3[2-9]" | wc 0 0 0 # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 | grep "r4[0-9]" | wc 64 3248 22391 # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 | grep "r5[0-9]" | wc 124 3548 24183 # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 | grep "r6[0-9]" | wc 344 6978 49690 # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 | grep "r7[0-9]" | wc 46 2314 16176 # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 | grep "r8[0-9]" | wc 0 0 0 # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 | grep "r9[0-9]" | wc 0 0 0 Overall for > 31: # dwarfdump -v -v -F = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li= bgcc_s.so.1 | egrep "(r3[2-9]|r[4-9][0-9])" | wc 505 7867 55379 By contrast from clang for > 31: # dwarfdump -v -v -F /lib/libgcc_s.so.1 | egrep "(r3[2-9]|r[4-9][0-9])" = | wc 254 3110 21110 with the more detailed split out being: # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r3[2-9]" | wc 0 0 0 # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r4[0-9]" | wc 25 775 5190 # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r5[0-9]" | wc 55 985 6265 # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r6[0-9]" | wc 152 2396 17011 # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r7[0-9]" | wc 24 828 5747 # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r8[0-9]" | wc 0 0 0 # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r9[0-9]" | wc 20 740 5135 WARNING: That last means that clang is using some r's that devel/powerpc64-gcc is not. Is libgcc_s ready to deal with those extras that are in the 90s? Is this an ABI difference between clang (as configured) and powerpc64-gcc (as configured)? Is there a problem based on powerpc64-gcc not generating examples of those 90s "extras"? Is this lack of support for some part of some ABI? =3D=3D=3D Mark Millard markmi at dsl-only.net