powerpc64 /usr/bin/ld crashes during buildworld: ppc64_elf_tls_optimize gets signal 11
Because of the following I've had to use
a ports binutils (such as
devel/powerpc64-binutils ) instead of the
system binutils in order to have a clang-based
powerpc64 world do a gcc 4.2.1 based "cross
build" (buildworld buildkernel).
This was from a clang-based buildworld buildkernel
powerpc64 FreeBSD context. It was an attempt to do a
gcc 4.2.1 "cross-compiler" based buildworld
buildkernel. It did not get very far before
(using one of several ld core files as an
example):
# /usr/libexec/gdb ld /var/crash/ld.26814.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "powerpc64-marcel-freebsd"...
Core was generated by `/usr/bin/ld --eh-frame-hdr -Bstatic -o gperf.full
/usr/lib/crt1.o /usr/lib/crti.'.
Program terminated with signal 11, Segmentation fault.
#0 0x1002e148 in ppc64_elf_tls_optimize (obfd=,
info=) at
/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf64-ppc.c:7172
7172 for (ent = htab->tls_get_addr->elf.plt.plist;
(gdb) bt
#0 0x1002e148 in ppc64_elf_tls_optimize (obfd=,
info=) at
/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf64-ppc.c:7172
#1 0x10001034 in ppc_before_allocation () at eelf64ppc_fbsd.c:204
#2 0x10009be4 in ldemul_before_allocation () at
/usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldemul.c:78
#3 0x10017b00 in lang_process () at
/usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldlang.c:5785
#4 0x10021ce0 in main (argc=0, argv=) at
/usr/src/gnu/usr.bin/binutils/ld/../../../../contrib/binutils/ld/ldmain.c:459
#5 0x14a8 in _start (argc=0, argv=0x50a24fc0, env=0x50f3feb8,
obj=, cleanup=, ps_strings=)
at /usr/src/lib/csu/powerpc64/crt1.c:94
Current language: auto; currently minimal
The source is:
if (expecting_tls_get_addr)
{
struct plt_entry *ent;
for (ent = htab->tls_get_addr->elf.plt.plist;
ent != NULL;
ent = ent->next)
if (ent->addend == 0)
{
if (ent->plt.refcount > 0)
{
ent->plt.refcount -= 1;
expecting_tls_get_addr = 0;
}
break;
}
}
(gdb) print htab->tls_get_addr
$3 = (struct ppc_link_hash_entry *) 0x0
0x1002e124 : beq-0x1002e4ec
0x1002e128 : li r3,18
0x1002e12c : li r14,2
0x1002e130 : li r28,0
0x1002e134 : cmpwi r5,0
0x1002e138 : crnot 4*cr5+lt,eq
0x1002e13c : beq-cr2,0x1002e198
0x1002e140 : bge-cr5,0x1002e330
0x1002e144 : ld r4,544(r22)
0x1002e148 : ld r4,80(r4)
0x1002e14c : cmpldi r4,0
0x1002e150 : beq-0x1002e16c
(gdb) info reg r5
r5 0x1 1
(I expect that means expecting_tls_get_addr==1 .)
(gdb) info reg r4
r4 0x0 0
--- _bootstrap-tools-gnu/usr.bin/gperf ---
Building
/usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/src/tmp/usr/src/gnu/usr.bin/gperf/version.o
Building
/usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/src/tmp/usr/src/gnu/usr.bin/gperf/getline.o
Building
/usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/src/tmp/usr/src/gnu/usr.bin/gperf/hash.o
Building
/usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/src/tmp/usr/src/gnu/usr.bin/gperf/gperf.full
. . .
--- _bootstrap-tools-gnu/usr.bin/gperf ---
--- gperf.full ---
c++: error: unable to execute command: Segmentation fault (core dumped)
c++: error: linker command failed due to signal (use -v to see invocation)
*** [gperf.full] Error code 254
make[3]: stopped in /usr/src/gnu/usr.bin/gperf
.ERROR_TARGET='gperf.full'
.ERROR_META_FILE='/usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/src/tmp/usr/src/gnu/usr.bin/gperf/gperf.full.meta'
.MAKE.LEVEL='3'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose'
_ERROR_CMD='c++ -O2 -pipe -g -Qunused-arguments
-I/usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/src/tmp/legacy/usr/include
-I/usr/src/contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf
-Wno-c++11-extensions -static
-L/usr/obj/powerpc64vtsc_gcc421/powerpc.powerpc64/usr/src/tmp/legacy/usr/lib -o
gperf.full bool-array.o hash-table.o input.o keyword-list.o keyword.o main.o
options.o output.o positions.o search.o version.o getline.o hash.o -legacy;'
.CURDIR='/usr/src/gnu/usr.bin/gperf'
.MAKE='make
[Bug 222641] www/firefox: OPTIMIZED_CFLAGS=off build fails: libgkrust.a: could not read symbols
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222641 --- Comment #26 from Kurt Jaeger --- (In reply to Kurt Jaeger from comment #18) I was not able to catch the libgkrust file as of now. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
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. . .)
>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? Does FreeBSD's libgcc_s design and implementation handle these additional logical registers? (I've no clue what the logical registers r97-r108 are supposed to match up with in powerpc64 terms.) Supporting notes: r46-r63 are for floating point registers (that have been around for a long time: older powerpc family members). r70 is for having/using the value from "mfcr". r2(?)-r6 are scratch for C++ exception handling. (I originally identified r3-r6. r2 might have a somewhat distinct status?) r14-r31 are for the normal r14 through r31 registers. r65 is standard and heavily used on all(?) routines, not just some libgcc_s ones. (So r65 is not listed below.) 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 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) 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 yet what r9[7-9],r10[0-8] are for. _Unwind_Backtrace suggests that none of them are alternate names for scratch registers r[2-6]. 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
Re: 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. . .)
[Looks like r97-r108 are for vr20-vr31 (AltiVec Registers).] On 2017-Oct-8, at 4:34 AM, Mark Millard 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 Fre
Re: 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. . .)
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 wrote: > [Looks like r97-r108 are for vr20-vr31 (AltiVec > Registers).] > > On 2017-Oct-8, at 4:34 AM, Mark Millard 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:
Re: 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. . .)
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 0x50530c20 in _Unwind_SetGR (context=,
index=, val=1342447712) at unwind-dw2-fde.h:162
162 {
(gdb) bt
#0 0x50530c20 in _Unwind_SetGR (context=,
index=, val=1342447712) at unwind-dw2-fde.h:162
#1 0x50190194 in __gxx_personality_v0 (version=,
actions=, exceptionClass=,
exceptionObject=0x50042060,
context=0xcc70) at /usr/src/contrib/libcxxrt/exception.cc:1203
#2 0x50531a60 in _Unwind_RaiseException_Phase2 (exc=0x50042060,
context=0xcc70) at unwind.inc:66
#3 0x50531548 in _Unwind_RaiseException (exc=) at
unwind.inc:135
#4 0x5018f4f4 in __cxa_throw (thrown_exception=,
tinfo=, dest= 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 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 wrote:
>
>> [Looks like r97-r108 are for vr20-vr31 (AltiVec
>> Registers).]
>>
>> On 2017-Oct-8, at 4:34 AM, Mark Millard 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 --possi
