Another ABI variation/violation. I top post them
because it is largely separate from the AltiVec
Registers issue and is probably more important.
Summary:
Lack of r2-r6 save/restore (and so its
matching DW_CFA_<?> material) so lack
of places for the like of _Unwind_SetGR
to work with.
More detail:
Beyond the AltiVec Registers issue it turns out that
for:
_Unwind_RaiseException
_Unwind_ForcedUnwind
_Unwind_Resume
_Unwind_Resume_or_Rethrow
the code generation from clang 5 for them does
not save/restore the ABI's "scratch registers"
involved in the exception handling: r2-r6. But
they are in the code from powerpc64-gcc.
In FreeBSD's libgcc_s.so.1 and libcxxrt.so.1
terms:
This means that _Unwind_SetGR and _Unwind_GetGR
have no place to set or access the value of
the r2-r6 GR in question. It currently
crashes as the first attempt, which happens
to be for setting r3 (as a scratch value).
This in turn prevents __gxx_personality_v0
from working. That in turn prevents throwing
exceptions from working.
Without the code generation, it makes sense
to not have the DW_CFA_<?>'s as well. The
code generation (or lack of it) is a bigger
deal.
It appears that in this area clang 5 simply
does not currently match the ABI that
powerpc64-gcc is generating code for and
that FreeBSD's libgcc_s.so.1 and libcxxrt.so.1
are designed for. That is why throwing a C++
exception gets the failure at:
Loaded symbols for /libexec/ld-elf.so.1
#0 0x0000000050530c20 in _Unwind_SetGR (context=<value optimized out>,
index=<value optimized out>, val=1342447712) at unwind-dw2-fde.h:162
162 {
(gdb) bt
#0 0x0000000050530c20 in _Unwind_SetGR (context=<value optimized out>,
index=<value optimized out>, val=1342447712) at unwind-dw2-fde.h:162
#1 0x0000000050190194 in __gxx_personality_v0 (version=<value optimized out>,
actions=<value optimized out>, exceptionClass=<value optimized out>,
exceptionObject=0x50042060,
context=0xffffffffffffcc70) at /usr/src/contrib/libcxxrt/exception.cc:1203
#2 0x0000000050531a60 in _Unwind_RaiseException_Phase2 (exc=0x50042060,
context=0xffffffffffffcc70) at unwind.inc:66
#3 0x0000000050531548 in _Unwind_RaiseException (exc=<value optimized out>) at
unwind.inc:135
#4 0x000000005018f4f4 in __cxa_throw (thrown_exception=<value optimized out>,
tinfo=<value optimized out>, dest=<value
Clang does save and restore other special
registers (special in DW_CFA_<?> terms):
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)
By contrast for powerpc64-gcc:
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
On 2017-Oct-8, at 2:24 PM, Mark Millard <markmi at dsl-only.net> wrote:
> 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
_______________________________________________
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
