clang 3.8.0 can mess up __builtin_dwarf_cfa (), at least for TARGET_ARCH=armv6, powerpc, powerpc64: a bug 207325 update

[Mark Millard]

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