From owner-freebsd-toolchain@freebsd.org Wed Mar 9 19:23:32 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 88507AC9D1B for ; Wed, 9 Mar 2016 19:23:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-4.reflexion.net [208.70.210.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3E0D91A5C for ; Wed, 9 Mar 2016 19:23:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14490 invoked from network); 9 Mar 2016 19:17:10 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 9 Mar 2016 19:17:10 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Wed, 09 Mar 2016 14:16:55 -0500 (EST) Received: (qmail 8681 invoked from network); 9 Mar 2016 19:16:55 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 9 Mar 2016 19:16:55 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id C25F91C43CC; Wed, 9 Mar 2016 11:16:47 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Ulrich Weigand has confirmed 3 of my 4 llvm bug submittals for clang 3.8.0 targeting powerpc/powerpc64. . . Date: Wed, 9 Mar 2016 11:16:50 -0800 Message-Id: Cc: Roman Divacky To: FreeBSD PowerPC ML , FreeBSD Toolchain Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 19:23:32 -0000 [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 >=20 > Yes, there's indeed a couple of problems here, which affect different = areas. >=20 > 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. >=20 > 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). >=20 > 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: >=20 > void func (void); >=20 > void test (void) > { > func (); > asm ("nop" : : : "31"); > } >=20 > 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. >=20 > 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. >=20 > 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. =3D=3D=3D Mark Millard markmi at dsl-only.net