Ulrich Weigand has confirmed 3 of my 4 llvm bug submittals for clang 3.8.0 targeting powerpc/powerpc64. . .

[Mark Millard]

[He also includes a note about ELFV2 ABI for powerpc64le.]

Quoting llvm 26856 Comment 6 (he put the text in the 26856 submittal but the content also covers 26519 and most of 26844):

> Ulrich Weigand 2016-03-09 11:53:17 CST
> 
> Yes, there's indeed a couple of problems here, which affect different areas.
> 
> 1) On 32-bit ppc, LLVM violates the ABI by storing below the stack pointer even though the ABI does not provide a "red zone".  This affects every function with a stack frame, and could in theory lead to spurious crashes when an asynchronous signal overwrites this area.  This seems to be a known issue; the source code contains FIXME lines:
>     // FIXME: On PPC32 SVR4, we must not spill before claiming the stackframe.
> 
> 2) In some scenarios, registers may be spilled/restored twice to the stack.  This happens because while most of the spilling happens in PPCFrameLowering::spillCalleeSavedRegisters, a few selected registers are also spilled in PPCFrameLowering::emitPrologue.  Those registers are the frame pointer, base pointer, PIC base pointer, link register, and condition code register.  For the latter two, code ensures that they can never be spilled in both places (for CR, there is extra code in spillCalleeSavedRegisters; for LR, the register is removed from SavedRegs in determineCalleeSaves).
> 
> However, for FP, BP, and PBP, nothing ensures the registers are not spilled twice.  It is probably *rare* for this to happen, because the register allocator will not use those registers within the function if they're needed for their special purpose, but it can happen in rare cases.  This includes the case of a system unwinder routine that uses __builtin_unwind_init, but could also include other routines that clobber one of those registers, e.g. the following case:
> 
> void func (void);
> 
> void test (void)
> {
>   func ();
>   asm ("nop" : : : "31");
> }
> 
> When it happens that a register is spilled twice, the code as such still works correctly, but the DWARF CFI unwind info associated with the routine will be broken, which can mess up both C++ exception handling and debugging.
> 
> 3) For the specific case of system unwinder routines that use __builtin_unwind_init and/or __builtin_eh_return, special things need to happen in the prolog and epilog that are not required for any other routine.  This in particular includes setting up save areas and CFI records for the EH data registers (r3 ... r6).  [See bug #26844. ]  For the ELFv2 ABI (powerpc64le), it also include using three separate save areas for the three caller-saved condition register fields, so that the EH logic can overwrite their values independently.
> 
> None of this is currently implemented in LLVM, since on Linux generally GCC is used to build the system unwind libraries, and no other code in the system ever needs those special constructs.


===
Mark Millard
markmi at dsl-only.net