Date: Sun, 8 Oct 2017 00:28:29 -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: <EF1F5F18-5371-49DA-8784-B3EE2480B86C@dsl-only.net> In-Reply-To: <08CBC862-4EAB-4864-B689-1949329EF3CE@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> <08CBC862-4EAB-4864-B689-1949329EF3CE@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[I should have checked for 3 digit numerals in r<?> notation.]
On 2017-Oct-7, at 11:36 PM, Mark Millard <markmi at dsl-only.net> wrote:
> 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:
>=20
> 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.
>=20
> 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.
>=20
>=20
> So the compare/contrast is of:
> (shown as seen in my context)
>=20
> # 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
>=20
> (That last being from a clang-based buildworld and the
> first being from a devel/powerpc64-xtoolchain-gcc
> material based buildworld.)
>=20
> Using r2 through r6 as initial examples:
>=20
> # 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
>=20
> vs.
>=20
> # dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "\<r[2-6]\>" | wc
> 0 0 0
>=20
> That is an example of missing information from clang.
>=20
> For powerpc64-gcc it is interesting that. . .
>=20
> # 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
>=20
> but:
>=20
> # 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
>=20
> and:
>=20
> # 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
>=20
> Looks like r2 might sometimes be a scratch or otherwise
> special register during C++ exception handling --but not
> everyplace that r3-r6 are.
>=20
> There are lots of other special r<?> names with numerals
> beyond that in the name r31 (powerpc64-gcc context):
>=20
> # 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
>=20
> Overall for > 31:
>=20
> # 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
>=20
>=20
> By contrast from clang for > 31:
>=20
> # dwarfdump -v -v -F /lib/libgcc_s.so.1 | egrep =
"(r3[2-9]|r[4-9][0-9])" | wc
> 254 3110 21110
>=20
> with the more detailed split out being:
>=20
> # 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
>=20
> WARNING:
> That last means that clang is using some r<?>'s that
> devel/powerpc64-gcc is not.
>=20
> 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)?
>=20
> 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?
clang is also using r<?> with <?> in the 10x's:
# dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r10[0-9]" | wc
45 315 2205
# dwarfdump -v -v -F /lib/libgcc_s.so.1 | grep "r[0-9][0-9][0-9]" | wc
45 315 2205
By contrast powerpc64-gcc is not:
# dwarfdump -v -v -F =
/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/li=
bgcc_s.so.1 | grep "r[0-9][0-9][0-9]" | wc
0 0 0
=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?EF1F5F18-5371-49DA-8784-B3EE2480B86C>