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 21:24:11 UTC 2017

Quick top note: clang 5 does generate code sequences
with AltiVec stvx and lvx instructions where r97-r108
are listed but powerpc64-gcc is not doing so in those
same sorts of places. This appears to be a ABI
variation across toolchains to me, unless such is
fully optional in the ABI somehow.

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

> [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