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 Fre
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.
>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 -44
[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
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 20
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:
