On 2016-Feb-28, at 12:39 AM, Roman Divacky <rdivacky at vlakno.cz> wrote: > > Mark, > > __builtin_dwarf_cfa() is lowered in clang to llvm intrinsic eh_dwarf_cfa. > There's a depth argument (which defaults to 0, saying it's correct for most > targets). > > Then the intrinsic gets lowered in SelectionDAG using > PPCTargetLowering::LowerFRAMEADDR() > > > Can you check that 1) the depth should be 0 for ppc64/ppc32 2) that > LowerFRAMEADDR() does something sensible? > > There's a loop depth-times, so I wonder if that makes a difference. > > Thanks, Roman
"Lowered"? I'm not familiar with the clang code base or its terminology. Handed off to a lower level interface, may be? As near as I can tell libgcc_s could be made to deal with clang 3.8.0's way of __builtin_dwarf_cfa() working for powerpc/powerpc64. But then use with g++ would be broken on powerpc/powerpc64 unless there were some sort of live "which compiler's type of code" test also involved. Having only one libgcc_s and multiple compilers using it for a given TARGET_ARCH= (for example, devel/powerpc64-xtoolchain-gcc like uses) suggests sticking to one convention per TARGET_ARCH= for __builtin_dwarf_cfa(). I would guess that g++ conventions win in this type of context for FreeBSD, under the guideline of trying to be gcc 4.2.1 "ABI" compatible. libgcc_s from FreeBSD works for C++ exceptions with its gcc 4.2.1 for powerpc and powerpc64 as things are as far as I know. But for clang++ FreeBSD is one context among many and other libraries may be based on clang 3.8.0's existing interpretation, without gcc/g++ compatibility constraints. (I've no experience with earlier clang vintages for the issue.) It may be that any change needs to be FreeBSD target-triple specific for all I know. In essence: making the convention part of the ABI chosen. I'll probably get some sleep before looking much at the code that you reference. A quick look at part of it suggests a fair amount of research/study for me to interpret things reliably. The loop may be somewhat analogous to _Unwind_RaiseException's loop, but for a specific depth. I would currently guess that depth 1 would match gcc 4.2.1's result for __builtin_dwarf_cfa(). But there was also some other "address"(?) builtin support routine nearby that seemed to call into LowerFRAMEADDR() and I've no clue if g++ 4.2.1 uses the same depth-figure standard for both sorts of things or not. For all I know both types of builtins(?) might have mismatches with gcc/g++ 4.2.1 and both might need fixes. I do vaguely remember seeing a builtin in FreeBSD code for something that had an explicit number in the argument list, possibly __builtin_frame_address(n)(?). But I only saw __builtin_dwarf_cfa() with no argument in the argument list as far as I remember. If clang 3.8.0 and gcc 4.2.1 disagreed about what the numbering standard referred to for __builtin_frame_address(n) (or whatever it was), that would not be good and compatibility would imply conversions between the conventions for the 2 FreeBSD contexts. I have not checked for armv6 related clang++ vs. g++ compatibility for C++ exception-handling. If anything is not operating for that context I expect that it would be g++ that generated buildworld code that did not work based on the FreeBSD source code: clang/clang++ is the normal compiler and kyua seemed to operate, unlike on the powerpc/powerpc64. I've never tried to build armv6 via an equivalent of devel/powerpc64-gcc. I do not know if armv6 even uses the same sort of C++ exception-handling ABI or not. But I do know that __builtin_dwarf_cfa() is not compatible between clang++ and g++ from the 2-line source and comparing objdump -d results. So more than powerpc/powerpc64 might be involved overall. === 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"