From owner-freebsd-ppc@freebsd.org Sat May 6 09:59:43 2017 Return-Path: Delivered-To: freebsd-ppc@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 A0F6CD5D7F4 for ; Sat, 6 May 2017 09:59:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-77.reflexion.net [208.70.210.77]) (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 4A605D79 for ; Sat, 6 May 2017 09:59:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 18798 invoked from network); 6 May 2017 09:59:40 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 6 May 2017 09:59:40 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Sat, 06 May 2017 05:59:40 -0400 (EDT) Received: (qmail 25212 invoked from network); 6 May 2017 09:59:40 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 6 May 2017 09:59:40 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id A2B16EC7DD3; Sat, 6 May 2017 02:59:39 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: llvm FreeBSD powerpc ABI target bug fix: Re: [Bug 26519] Clang 4.0.0's "Target: powerpc-unknown-freebsd11.0" code generation is violating the SVR4 ABI (SEGV can result) From: Mark Millard In-Reply-To: Date: Sat, 6 May 2017 02:59:39 -0700 Cc: Dimitry Andric Content-Transfer-Encoding: quoted-printable Message-Id: <528DD22A-D880-4BA1-8FA8-BB9CC5004434@dsl-only.net> References: <0103401A-CEEA-4992-A45E-E60EA151119B@dsl-only.net> <893ECA11-7C80-4D24-A496-92ADC7978A07@FreeBSD.org> <8F708AD1-055E-41BD-BD92-6A87C5FBAA60@dsl-only.net> <78CD5050-2B2B-4213-AF11-7EF744F608B2@dsl-only.net> To: FreeBSD Toolchain , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 09:59:43 -0000 [I'm top posting a find of another stack handling failure example from the updated compiler for TARGET_ARCH=3Dpowerpc .] Bad news: Another code generation error, this time demonstrated in compiling part of perl5. . . (I tried to build a port that indirectly tried build perl5 but perl5's miniperl crashes.) /usr/obj/portswork/usr/ports/lang/perl5.24/work/perl-5.24.1/numeric.c has Perl_cast_iv(NV f) for which clang double stores two different things to one address [24(r1)]. Below the =3D> lines are the double store, the second destroying the r30 value that was saved in the first: Dump of assembler code for function Perl_cast_iv: 0x0196a114 <+0>: mflr r0 0x0196a118 <+4>: stw r0,4(r1) 0x0196a11c <+8>: stwu r1,-32(r1) 0x0196a120 <+12>: stw r31,28(r1) =3D> 0x0196a124 <+16>: stw r30,24(r1) 0x0196a128 <+20>: mr r31,r1 0x0196a12c <+24>: mfcr r12 =3D> 0x0196a130 <+28>: stw r12,24(r31) Note: r31 =3D=3D r1 for that second "=3D>" line. The return code sequence has a similar problem: two loads from the same address for what should be distinct values. Note: r31 =3D=3D r1 here too. =3D> 0x0196a1bc <+168>: lwz r12,24(r31) 0x0196a1c0 <+172>: lwz r0,36(r1) 0x0196a1c4 <+176>: lwz r31,28(r1) =3D> 0x0196a1c8 <+180>: lwz r30,24(r1) 0x0196a1cc <+184>: mtcrf 32,r12 0x0196a1d0 <+188>: addi r1,r1,32 0x0196a1d4 <+192>: mtlr r0 0x0196a1d8 <+196>: blr The Perl_cast_iv source code looks like: IV Perl_cast_iv(NV f) { if (f < IV_MAX_P1) return f < IV_MIN ? IV_MIN : (IV) f; if (f < UV_MAX_P1) { #if CASTFLAGS & 2 /* For future flexibility allowing for sizeof(UV) >=3D sizeof(IV) = */ if (f < UV_MAX_P1_HALF) return (IV)(UV) f; f -=3D UV_MAX_P1_HALF; return (IV)(((UV) f) | (1 + (UV_MAX >> 1))); #else return (IV)(UV) f; #endif } return f > 0 ? (IV)UV_MAX : 0 /* NaN */; } This sort of thing might explain the occasional panic that names ffs_truncate if there is some infrequently used routine that messes up the stack. On 2017-May-6, at 12:06 AM, Mark Millard wrote: > On 2017-May-5, at 10:13 PM, Mark Millard = wrote: >=20 >=20 >> On 2017-May-5, at 6:11 PM, Mark Millard = wrote: >>=20 >>>>> . . . >>>>>=20 >>>>> For the gcc 4.2.1 based kernel boot I have >>>>> had one odd fatal kernel trap (0x903a64a, >>>>> "unknown") where the lr showed 0x907f . It >>>>> reported being stopped at: >>>>>=20 >>>>> ffs_truncate+0x1080 >>>>>=20 >>>>> It appears that "call doadump" worked but >>>>> I've not looked at what was put in >>>>> /var/crash/ . >>>>=20 >>>> If I leave the PowerMac idle running: >=20 > It also happens when busy. >=20 >>>> # uname -paKU >>>> FreeBSD FBSDG4S 12.0-CURRENT FreeBSD 12.0-CURRENT r317820M = powerpc powerpc 1200030 1200030 >>>>=20 >>>> it eventually gets the same ffs_truncate-tied fatal >>>> kernel trap, with the same odd lr and the like. >>>>=20 >>>> So, while I cannot directly cause the problem >>>> at a specific time, the problem is repeatable. >>>>=20 >>>> . . . >>>=20 >>> The ffs_truncate issue is odd: >>>=20 >>> A) It was gcc 4.2.1 based for both kernel and world. >>> B) I built a gcc 4.2.1 based debug kernel and >>> installed it but that does not get the problem. >>>=20 >>> I sam trying the gcc 4.2.1 debug kernel with the >>> system clang 4 world now and will later switch >>> to the gcc 4.2.1 non-debug kernel to see what >>> happens. >>>=20 >>> But being a pure gcc 4.2.1 environment originally >>> suggests that the ffs_truncate issue is not >>> clang-toolchain related. >>=20 >> I found a bad (old) kernel module in /boot/kernel/ >> and eliminating it appears to have removed the >> ffs_truncate problem. >>=20 >> . . . >=20 > For the ffs_truncate problem I spoke too > soon: It happened again, this time while > the old PowerMac was busy. >=20 > The detail numbers and such were again the > same. =3D=3D=3D Mark Millard markmi at dsl-only.net