C++ in jemalloc

[Mark Millard]

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/libgcc_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/libgcc_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/libgcc_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/libgcc_s.so.1 | grep "\<r3\>" | wc
      27    2571   17800
# dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | grep "\<r4\>" | wc
      27    2571   17800
# dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | grep "\<r5\>" | wc
      27    2571   17800
# dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_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/libgcc_s.so.1 | grep "\<r7\>" | wc
       0       0       0
# dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_s.so.1 | grep "\<r8\>" | wc
       0       0       0
# dwarfdump -v -v -F /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/lib/libgcc_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/libgcc_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/libgcc_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/libgcc_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/libgcc_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/libgcc_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/libgcc_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/libgcc_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/libgcc_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?


===
Mark Millard
markmi at dsl-only.net