head -r324071 clang++ 5 for TARGET_ARCH=powerpc64 (e.g.): DW_CFA_offset_extended for r97-r108? Handled by FreeBSD's libgcc_s.so.1 ? (more. . .)

Sun Oct 8 13:34:49 UTC 2017

[Looks like r97-r108 are for vr20-vr31 (AltiVec
Registers).]

On 2017-Oct-8, at 4:34 AM, Mark Millard <markmi at dsl-only.net> wrote:

> From a dwarfdump's _Unwind_RaiseException information
> from a clang/clang++ 5 based compile:
> 
>        91 DW_CFA_offset_extended r97 -496  (62 * -8)
>        94 DW_CFA_offset_extended r98 -480  (60 * -8)
>        97 DW_CFA_offset_extended r99 -464  (58 * -8)
>        100 DW_CFA_offset_extended r100 -448  (56 * -8)
>        103 DW_CFA_offset_extended r101 -432  (54 * -8)
>        106 DW_CFA_offset_extended r102 -416  (52 * -8)
>        109 DW_CFA_offset_extended r103 -400  (50 * -8)
>        112 DW_CFA_offset_extended r104 -384  (48 * -8)
>        115 DW_CFA_offset_extended r105 -368  (46 * -8)
>        118 DW_CFA_offset_extended r106 -352  (44 * -8)
>        121 DW_CFA_offset_extended r107 -336  (42 * -8)
>        124 DW_CFA_offset_extended r108 -320  (40 * -8)
> 
> By contrast devel/powerpc64-gcc does not produce any
> of those. Is this lack of support of some part of an
> ABI? Is clang going outside the range of the intended
> ABI?

ABI64BitOpenPOWERv1.1_16July2015_pub.pdf indicates
that r97-r108 are for vr20-vr31 (AltiVec Registers).
[Is AltiVec optional --possibly missing?]

So the questions translate into questions about
AltiVec support/handling for C++ exceptions.

[Note: R70 is supposed to be specific to CR2.]

> Does FreeBSD's libgcc_s design and implementation handle
> these additional logical registers?
. . .

So the libgcc_s question traces back to: does it
handle AltiVec Registers vr20-vr31 if they are
referenced (clang)? Is it well behaved if r97-r108
are not referenced (powerpc64-gcc)?

> Supporting notes:
> 
> r46-r63 are for floating point registers (that
> have been around for a long time: older
> powerpc family members).

r46-r63 are for f14-f31.

> r70 is for having/using the value from "mfcr".

Apparently r70 is supposed to be specific to CR2.

> r2(?)-r6 are scratch for C++ exception handling.
> (I originally identified r3-r6. r2 might have a
> somewhat distinct status?)

In normal functions r2-r6 do not get
DW_CFA_offset_extended_sf or
DW_CFA_offset entries. They are special
to some internal exception handling
routines. (See later.)

> r14-r31 are for the normal r14 through r31
> registers.

r97-r108 are for AltiVec Registers vr20-vr31.

> r65 is standard and heavily used on all(?)
> routines, not just some libgcc_s ones. (So
> r65 is not listed below.)

r65 for lr.

> In libgcc_s.so.1.full (via powerpc64-gcc):
> 
> uw_update_context_1:           r70
> _Unwind_RaiseException:        r[2-6],r4[6-9],r5[0-9],r6[0-3],r70
> _Unwind_RaiseException_Phase2: (nothing special matched)
> _Unwind_ForcedUnwind:          r[2-6],r4[6-9],r5[0-9],r6[0-3],r70
> _Unwind_Resume:                r[2-6],r4[6-9],r5[0-9],r6[0-3],r70
> _Unwind_Resume_or_Rethrow:     r[2-6],r4[6-9],r5[0-9],r6[0-3],r70
> _Unwind_Backtrace:                    r4[6-9],r5[0-9],r6[0-3],r70
> __deregister_frame_info_bases: r70
> _Unwind_Find_FDE:              r70

So no AltiVec Registers listed.

> In libgcc_s.so.1.full (via clang):
> 
> uw_update_context_1:           r70 (uw_update_context_1 was actually later in the file)
> _Unwind_RaiseException:        r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8]
> _Unwind_RaiseException_Phase2: r70
> _Unwind_ForcedUnwind:          r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8]
> _Unwind_Resume:                r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8]
> _Unwind_Resume_or_Rethrow:     r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8]
> _Unwind_Backtrace:             r4[6-9],r5[0-9],r6[0-3],r70,r9[7-9],r10[0-8]
> __deregister_frame_info_bases: (nothing special matched)
> _Unwind_Find_FDE:              (nothing special matched)

So no internal, special-for-excpetion-routines
scratch register usage listed (r2-r6).

> clang is missing all the r[2-6] references but
> the code generated does have the registers in
> use. Thrown C++ exceptions crash because of
> the lack of the r2-r6's, dying on a r3 attempt.
> 
. . .
> 
> I have no clue why _Unwind_RaiseException_Phase2
> has a r70 for clang but not for powerpc64-gcc.
> Or the other way around for __deregister_frame_info_bases
> and _Unwind_Find_FDE.
> 
> Which file's implementations are used from
> what I can tell :
> 
> uw_update_context_1:           /usr/src/contrib/gcc/unwind-dw2.c
> _Unwind_RaiseException:        /usr/src/contrib/gcc/unwind.inc
> _Unwind_RaiseException_Phase2: /usr/src/contrib/gcc/unwind.inc
> _Unwind_ForcedUnwind:          /usr/src/contrib/gcc/unwind.inc
> _Unwind_Resume:                /usr/src/contrib/gcc/unwind.inc
> _Unwind_Resume_or_Rethrow:     /usr/src/contrib/gcc/unwind.inc
> _Unwind_Backtrace:             /usr/src/contrib/gcc/unwind.inc
> __deregister_frame_info_bases: /usr/src/contrib/gcc/unwind-dw2-fde.c
> _Unwind_Find_FDE:              /usr/src/contrib/gcc/unwind-dw2-fde*.c (unsure)
> 
> An implication is that GPL Version 2 source code
> is involved even when clang is the system compiler.
> Is that what FreeBSD intends for the powerpc
> families?
> 
> /* Exception handling and frame unwind runtime interface routines. -*- C -*-
>   Copyright (C) 2001, 2003 Free Software Foundation, Inc.
> 
>   This file is part of GCC.
> 
>   GCC is free software; you can redistribute it and/or modify it
>   under the terms of the GNU General Public License as published by
>   the Free Software Foundation; either version 2, or (at your option)
>   any later version.
> 
>   In addition to the permissions in the GNU General Public License, the
>   Free Software Foundation gives you unlimited permission to link the
>   compiled version of this file into combinations with other programs,
>   and to distribute those combinations without any restriction coming
>   from the use of this file.  (The General Public License restrictions
>   do apply in other respects; for example, they cover modification of
>   the file, and distribution when not linked into a combined
>   executable.)
> 
> . . .
> 
> Does libgcc_s.so.1 with its type of use form a "combined executable"?
> 

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