[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
_______________________________________________
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"
