Date: Sat, 7 Oct 2017 23:36:15 -0700 From: Mark Millard <markmi@dsl-only.net> To: Roman Divacky <rdivacky@vlakno.cz>, Justin Hibbits <jrh29@alumni.cwru.edu>, Warner Losh <imp@bsdimp.com>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: C++ in jemalloc Message-ID: <08CBC862-4EAB-4864-B689-1949329EF3CE@dsl-only.net> In-Reply-To: <A4251FF5-7193-49D7-B083-DEF986D3A524@dsl-only.net> References: <BDC9F954-D0C5-4D7A-9CEA-D4FCA595B2FD@dsl-only.net> <CAHSQbTB76OJYGtwzRRFfThJB5mYOKHi_BC9Eefc7Mn1A0-6sWg@mail.gmail.com> <528ED3CD-8A4B-4F00-8728-7D231DB0811A@dsl-only.net> <20171007064249.GA73770@vlakno.cz> <A47AA10A-550B-4E12-97DE-440F892EE7FC@dsl-only.net> <EEE4D3F8-59C5-41C3-8E5D-148A1ECD45D3@dsl-only.net> <CA477B6C-9F32-4F54-A7BE-74B6137DDC1B@dsl-only.net> <FBA4BD2F-1074-4516-B368-9F39583B3200@dsl-only.net> <934C1C1A-1303-4A8C-9E80-4259E475220A@dsl-only.net> <20171007102151.GA84155@vlakno.cz> <A4251FF5-7193-49D7-B083-DEF986D3A524@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 "\<r[2-6]\>" | wc
43 2683 18432
vs.
# dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "\<r[2-6]\>" | 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 "\<r2\>" | 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 "\<r3\>" | 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 "\<r4\>" | 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 "\<r5\>" | 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 "\<r6\>" | 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 "\<r7\>" | 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 "\<r8\>" | 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\>" | 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?08CBC862-4EAB-4864-B689-1949329EF3CE>