[prev in list] [next in list] [prev in thread] [next in thread]
List: freebsd-hackers
Subject: Re: head -r324071 clang++ 5 for TARGET_ARCH=powerpc64 (e.g.): DW_CFA_offset_extended for r97-r108? H
From: Mark Millard <markmi () dsl-only ! net>
Date: 2017-10-08 23:06:15
Message-ID: B0543889-A626-412D-9C4A-3889222DCA06 () dsl-only ! net
[Download RAW message or body]
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-hackers@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic