From owner-freebsd-ppc@freebsd.org Sun Oct 14 05:59:46 2018 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45AD210C685F for ; Sun, 14 Oct 2018 05:59:46 +0000 (UTC) (envelope-from cam@neo-zeon.de) Received: from neo-zeon.de (neo-zeon.de [96.90.244.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.neo-zeon.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C7BEE7AA69 for ; Sun, 14 Oct 2018 05:59:45 +0000 (UTC) (envelope-from cam@neo-zeon.de) Received: from [192.168.0.2] (amuro.nerv.lan [192.168.0.2]) (authenticated bits=0) by neo-zeon.de (8.15.2/8.15.2) with ESMTPSA id w9E5xhJS010465 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sat, 13 Oct 2018 22:59:44 -0700 (PDT) (envelope-from cam@neo-zeon.de) Subject: Re: FreeBSD 12.0-ALPHA4 fails to boot on POWER9/KVM From: Cameron Berkenpas To: freebsd-ppc@freebsd.org References: <5d84652d-8b54-19f9-1396-e7c9acbe6c03@neo-zeon.de> <5f44c6d6-7eec-6732-6fef-123e7e0d3292@freebsd.org> <2b4455f4-37f6-5645-dcba-2cc41c845ae8@neo-zeon.de> <0a970b75-160a-e40e-b360-1b73a753f701@freebsd.org> <573eb381-35f0-5523-3d6a-77a01174bdc8@blastwave.org> <557519fc-a1f7-4a78-ee77-eae6f96d3a5e@freebsd.org> <341c38b5-d319-226c-946e-ecdbeaae1d0c@neo-zeon.de> Message-ID: <46e403ec-b5db-a706-2002-7783413d8c97@neo-zeon.de> Date: Sat, 13 Oct 2018 22:59:43 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <341c38b5-d319-226c-946e-ecdbeaae1d0c@neo-zeon.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2018 05:59:46 -0000 In order to get this working with libvirt/virt-manager, simply do: virsh edit And add the following under your "" line.         Apparently you can turn this further, but this little snippet is enough. I had to use "virsh edit" to force remove the VGA device to get a serial console to see what was going on. I/O seems really slow... I booted into a non-debug kernel, but that didn't seem to make much of a difference. Anyone know how much of this due to not supporting virtio yet vs lack of optimization for PPC/PPC64? Anyway, the last issue for me, and it's not major, is that shutting down doesn't work. Ie, "virsh shutdown " simply doesn't do anything. Shutting down from within the guest itself works fine though, so I guess this isn't a HUGE issue. Anyway, I hope this all eventually helps someone. Thanks! -Cameron On 10/13/2018 04:18 PM, Cameron Berkenpas wrote: > Whoops, that would be: > > make buildworld buildkernel TARGET=powerpc TARGET_ARCH=powerpc64 > make cdrom TARGET=powerpc TARGET_ARCH=powerpc64 > > > Good catch. Turns out that's the bootloader of my install that no > longer boots... > > So you can either manually select to boot from the cd-rom in the > firmware, or here's how to boot from the cd-rom via kvm/qemu: > qemu-system-ppc64 -enable-kvm -m 2048 -nographic -vga none -boot > order=d -cdrom bootonly.iso -drive > file=/var/lib/libvirt/images/freebsd-ppc.qcow2,format=qcow2 > -mem-prealloc -mem-path /dev/hugepages -smp 2 > > Then after installing, of course remove the '-boot' option and its > argument to boot from the disk. > > Interestingly, disc1.iso still won't boot: > Trying to load:  from: /vdevice/v-scsi@71000003/disk@8200000000000000 > ... failed to load CHRP boot loader.failed to load CHRP boot loader. > E3404: Not a bootable device! > > There's probably something wrong with my disc1.iso. > FreeBSD-12.0-ALPHA9-powerpc-powerpc64-20181009-r339271-disc1.iso boots > successfully in spite of the "NOT FOUND" errors. > > My earlier attempts with bootonly.iso failed due to some foolishness > on my part. The above examples will work. > > However, during the install, I'm getting a checksum error with > base.txz. Looking at the MANIFEST, it seems correct. > > I used the ALPHA9 ISO and was able to install successfully. Anyway, > just remember to use the MBR partition scheme or your install won't boot. > > I still can't get FreeBSD to boot through virt-manager/libvirt, but > I'm still trying to see if I get that working too. > > -Cameron > > On 10/13/2018 01:08 PM, Nathan Whitehorn wrote: >> >> On 10/13/18 12:53 PM, Cameron Berkenpas wrote: >>> Hello, >>> >>> Finally had some time to spin up my own ISO from 12-CURRENT. >>> Unfortunately, it still fails. Looks like there's no real change from >>> before. >>> >>> # This is how I built the cdrom image: >>> make cdrom TARGET=powerpc TARGET_ARCH=powerpc64 >>> make cdrom TARGET=powerpc TARGET_ARCH=powerpc64 >>> >>> I tried this with revision r339340. >> [...] >> >>>>> FreeBSD/powerpc Open Firmware boot block >>>     Boot path: /pci@800000020000000/scsi@7/disk@100000100000000 >>>     Boot loader: /boot/loader >>>     Boot volume: /pci@800000020000000/scsi@7/disk@100000100000000:2 >>> Consoles: Open Firmware console >>> >>> FreeBSD/powerpc64 Open Firmware loader, Revision 0.1 >>> (Sun Aug 19 13:30:54 PDT 2018 root@freebsd-ppc) >> >> I think you aren't using the loader you think you are using judging by >> the date above. >> -Nathan >> >>> Memory: 2097152KB >>> Booted from: /pci@800000020000000/scsi@7/disk@100000100000000 >>> >>> >>> block-size NOT FOUND >>> #blocks NOT FOUND| >>> block-size NOT FOUND >>> #blocks NOT FOUND\ >>> block-size NOT FOUND >>> #blocks NOT FOUND >>> >>> ( 700 ) Program Exception [ 0 ] >>> >>> >>>      R0 .. R7           R8 .. R15         R16 .. R23 R24 .. R31 >>> 0000000000000040   000000000345cdc4   ffffffffffffffff 0000000002c50468 >>> 0000000002c548c0   0000000000000000   0000000002c56ba0 0000000002c513a0 >>> 0000000000000000   0000000002c67780   0000000002c56b98 0000000002c51c18 >>> 000000000345d8f0   0000000002c67300   0000000002c62200 000000000345d8f0 >>> 0000000002c67340   0000000020000048   000000000040e78e 0000000000000000 >>> 0000000000000000   0000000000000000   0000000001802118 0000000000000000 >>> 0000000000000040   0000000002c4baec   0000000002c71980 0000000000000000 >>> 0000000000000040   000000007fffffff   0000000002c5bb84 000000000345d8f0 >>> >>>      CR / XER           LR / CTR          SRR0 / SRR1 DAR / DSISR >>>          80000044   0000000002c02938   0000000000000000 >>> 0000000000000000 >>> 0000000020040000   0000000000000000   0000000000083000 00000000 >>> >>> >>> e > >>> >>> Hope this is helpful! >>> >>> On 10/11/2018 12:00 PM, Dennis Clarke wrote: >>>> On 10/11/2018 02:50 PM, Mark Millard wrote: >>>>> On 2018-Oct-11, at 11:19 AM, Dennis Clarke >>>> blastwave.org> wrote: >>>>> >>>>>> On 10/10/2018 11:59 PM, Nathan Whitehorn wrote: >>>>>>> The first part of this (all the errors about "NOT FOUND") I just >>>>>>> fixed >>>>>>> and the fixes will be included in BETA1 and subsequent builds. The >>>>>>> remaining issue is that virtio SCSI is not part of the standard >>>>>>> kernel >>>>>>> on PPC (there are some endian and DMA bugs), so you will need to >>>>>>> use an >>>>>>> alternative storage backend. The default storage backend (VSCSI) is >>>>>>> fine, as are more PC-ish things like AHCI emulation. >>>>>>> This command line will work and is otherwise equivalent to the >>>>>>> below: >>>>>>> qemu-system-ppc64 -enable-kvm -m 2048 -nographic -vga none -cdrom >>>>>>> FreeBSD-12.0-ALPHA9-powerpc-powerpc64-20181009-r339271-disc1.iso >>>>>>> /var/lib/libvirt/images/freebsd-ppc.qcow2 -mem-prealloc -mem-path >>>>>>> /dev/hugepages -smp 2 >>>>>>> -Nathan >>>>>> >>>>>> Has anyone tried this on a PowerMac G5 yet ? >>>>> "this"? I'm unsure if the following is addressing what you are >>>>> referring to or not. But it might be. >>>>> >>>>> Until the problems with -r334498 's adjustment to >>>>> VM_MAX_KERNEL_ADDRESS >>>>> are dealt with, PowerMac G5's have boot problems (and possibly other >>>>> problems), at least those with multiple sockets (for what I can >>>>> test). >>>>> (I've no access to other forms of PowerMac G5's.) >>>>> >>>>> See: >>>>> >>>>> https://lists.freebsd.org/pipermail/freebsd-ppc/2018-October/009669.html >>>>> >>>>> >>>>> >>>>> and later in that thread. (Earlier in the thread is likely a waste >>>>> of time >>>>> to read, given what is now known.) >>>>> >>>>> My G5 contexts are operational by reverting -r334498 . The >>>>> contexts are >>>>> otherwise based on -r339076 currently. >>>>> >>>>> >>>>> Note: >>>>> >>>>> My boot test on a 8 GiByte, dual-socket, one "CPU" per socket, >>>>> PowerMac G5 met the conditions of Andreas Tobler's requested test >>>>> conditions and the machine boot fine (VM_MAX_KERNEL_ADDRESS near >>>>> the RAM size, on the low side). >>>>> >>>>> The G5 so-called "Quad Core"s, 4 cores total in each system but >>>>> split evenly across 2 sockets in each), one with 12 GiByte and >>>>> one with 16 GiByte of RAM, booted fine as well. But >>>>> VM_MAX_KERNEL_ADDRESS was somewhat under 8GiByte and so not near >>>>> those sizes. >>>>> >>>> >>>> OKay ... that is a lot of good information and I'll sum up as "no". >>>> >>>> Was merely curious if I should give it a try. >>>> >>>> Dennis >>>> >>>> >>>> _______________________________________________ >>>> freebsd-ppc@freebsd.org mailing list >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-ppc >>>> To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" >>> _______________________________________________ >>> freebsd-ppc@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-ppc >>> To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" >>> >> _______________________________________________ >> freebsd-ppc@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-ppc >> To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" >> > From owner-freebsd-ppc@freebsd.org Sun Oct 14 07:40:34 2018 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91EDB10C9152 for ; Sun, 14 Oct 2018 07:40:34 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-22.consmr.mail.gq1.yahoo.com (sonic317-22.consmr.mail.gq1.yahoo.com [98.137.66.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 19CD37D737 for ; Sun, 14 Oct 2018 07:40:33 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: QSoO_Z4VM1nJy_Bs7OO3WE7VxJkvYHYJus4MXHY_JnzUBd8R6HpF56Nyqqfp8Lk 8r5E3dlwbIIC.J4Wo78c2xNx_NuThsALUopdrdZQArggSO9aQAC1mYCgx5Ar_Gnu9oLUhPrsfYLU WEfGyyrqc4vca0_oLnfozcQXbuC8d3XvzXfeOgiwm9KK20ktdrLsWuqRJYm.4gdXYPlFh3pN7QxA p2aFCfRXI63rTggXNqP8K5CgAY2iM9Ax2CeTrqDfFTWncmDlNR3VSC3cv33X_rhKFbxA.YQHW_Kn FVt5md81DGSo1Pv9nW6fzFyFAr2DFyyxceq8K_QHPa2zlN5XSuBsSQ0XmYVAmDv3olkY6LoLNDyN wgH1BKDOVIFQ2RBq0w4TTPtQQq.9Nax4beY8gPOaBP8eVa4lvGWiGLjcDhJ0SCP5yy_.1tH0bcHA 6OrjcRgbrI81aEJtMj6n_qDfb_fNrAgsHBHembqMTmK_Ov_sHTQxqnnqCzdNWhmfztiRbD_cVSki qdICkFLoYy0ZK796BYoFDiI5MdRx4ccHBLrFTR_2qQy6i01yFuYz1cJsNDtUlFakBFtKB0f0liyW HcHHQZ1oAFTvs6kdgXXFS5_D76CupV5ty_8gbend5lAPPl8N782k.gfCgoDiTTwoes6.Kgo96rWy PRcIsTIatUnJc0NABpL0xyIDcRnj97L5KowAvWzBYT1IvE1FOHHMVBbo6Ch6n7WUITCIM5JMJNAf iIDYiG8Hai7aFz08L64jixb64F6o2xgTankg_dkZXO5ETp2KQRMJvbbGVvPp8bTtaXVkLI03gIwx Zc9kAIopMqIn.0se4ajePj.EygruiPriYVQ3cPk08Qe1khEFSOIiJK6FxsaXxUxiPhHwyVZMtHM3 Mroqk39FCPZjxqXHEuIRHEdoafJKWTJkNenbvS8wUBXn9_FsDgv4Gs2_nO4Roh.2CyEB.5AyEYLb kGoWq0IUy94_8exQGTkwUFRSo_spbbshDm_kz31H2VmuPZ7Nlc52yomwGPXRHLP5zuuefvrTbyJz UkOkfKKTt3zbvHjMPYtV8cUbR5LPO4SB70FEVuJmDbVf92We07EDz2co5oECvmBnVsg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.gq1.yahoo.com with HTTP; Sun, 14 Oct 2018 07:40:31 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp405.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID c6881e5bb5193b8e3e3578a39f1f6be7 for ; Sun, 14 Oct 2018 07:40:28 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: FYI: powerpc64 headbuilt via devel/powerpc64-xtoolchain-gcc and C++ exceptions for user code built by system-clang or devel/powerpc64-gcc (as of head -r339076 and ports -r480180) Date: Sun, 14 Oct 2018 00:40:27 -0700 References: To: FreeBSD PowerPC ML In-Reply-To: Message-Id: <0539C16B-1603-4639-914A-0308578C7262@yahoo.com> X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2018 07:40:34 -0000 On 2018-Oct-12, at 1:59 PM, Mark Millard wrote: > I built a powerpc64 head -r339076 via devel/powerpc64-gcc > and the like that built clang as cc as well (and > WITHOUT_LIB32). This included use of base/binutils to > the the powerpc64 set up. The system and kernel are > non-debug builds (but with symbols). [system-clang is not > used for buildworld buildkernel because of known > issues (last I tried).] >=20 > booting, buildworld, buildkernel, poudriere building > what totaled to be somewhat under 400 ports all seem > to work. But . . . >=20 > It been a long time since I've done something analogous > and a significant item in the result is different than in > the past once I started testing the throwing of C++ > exceptions in code produced by system-clang or by > devel/powerpc64-gcc : >=20 > Such code ends up stuck using around 100% of a CPU. > An example is the program: >=20 > # more exception_test.cpp > #include >=20 > int main(void) > { > try { throw std::exception(); } > catch (std::exception& e) {} > return 0; > } >=20 > For system-clang it ended up with: >=20 > # ldd a.out > a.out: > libc++.so.1 =3D> /usr/lib/libc++.so.1 (0x81006d000) > libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x810184000) > libm.so.5 =3D> /lib/libm.so.5 (0x8101ab000) > libc.so.7 =3D> /lib/libc.so.7 (0x8101eb000) > libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x810554000) >=20 > That program goes into an possibly unbounded execution. > (Historically when this program had problems it would > stop and produce a core file.) >=20 > When compiled by devel/powerpc64-gcc the a.out that results > does the same thing. ( = /usr/local/bin/powerpc64-unknown-freebsd12.0-c++=20 > as the compiler path ) So this is not really clang specific > in any way. This ended up with: >=20 > # ldd a.out > a.out: > libc++.so.1 =3D> /usr/lib/libc++.so.1 (0x81006d000) > libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x810184000) > libm.so.5 =3D> /lib/libm.so.5 (0x8101ab000) > libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x8101eb000) > libc.so.7 =3D> /lib/libc.so.7 (0x810211000) >=20 > (That should not have involved clang or llvm at all.) >=20 > But compiled by lang/gcc8's g++8 the a.out that results works > fine. This ends up with: >=20 > # ldd a.out > a.out: > libstdc++.so.6 =3D> /usr/local/lib/gcc8/libstdc++.so.6 = (0x81006e000) > libm.so.5 =3D> /lib/libm.so.5 (0x8102c7000) > libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x810307000) > libc.so.7 =3D> /lib/libc.so.7 (0x81032d000) >=20 > It is not clear if using base/gcc as system cc > would do any better than using system-clang does > or than devel/powerpc64-gcc does: it is sort of > a variant of devel/powerpc64-gcc . >=20 > It will probably be some time before I figure out > much about what is going on. >=20 > Two things common to the problem cases are: >=20 > libc++.so.1 =3D> /usr/lib/libc++.so.1 (0x81006d000) > libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x810184000) >=20 > lang/gcc8 avoids those being involved. >=20 >=20 > Notes: >=20 > Some time ago I'd used system-clang to build such > programs in an environment built via devel/powerpc64-gcc > and devel/powerpc64-binutils and the programs worked. > The same for devel/powerpc64-gcc use: the code it > produced for the programs also worked. At this point > I've no clue what changed or when. >=20 > WITHOUT_LIB32=3D is because, for every post-gcc 4.2.1 > that I've tried, the lib32 produced misuses R30 in > crtbeginS code (vs. the ABI for FreeBSD) and 32-bit > code just produces core files from the bad so-called > address dereference that results. >=20 > I'd rather have throwing C++ exceptions working and > lack of lib32 than have lib32 but not have throwing > C++ exceptions working. But at the moment how to have > such is not obvious when fairly modern compilers > and toolchains are involved.=20 Here is what I've found so far. The code is looping in the following routine. (I've inserted 2 NOTE: lines for what the sustained looping is like.) _Unwind_Reason_Code _Unwind_RaiseException(struct _Unwind_Exception *exc) { struct _Unwind_Context this_context, cur_context; _Unwind_Reason_Code code; =20 /* Set up this_context to describe the current stack frame. */ uw_init_context (&this_context); cur_context =3D this_context; =20 /* Phase 1: Search. Unwind the stack, calling the personality routine with the _UA_SEARCH_PHASE flag set. Do not modify the stack yet. = */ while (1) { _Unwind_FrameState fs; =20 /* Set up fs to describe the FDE for the caller of cur_context. = The first time through the loop, that means __cxa_throw. */ code =3D uw_frame_state_for (&cur_context, &fs); NOTE: code =3D=3D _URC_NO_REASON always results if (code =3D=3D _URC_END_OF_STACK) /* Hit end of stack with no handler found. */ return _URC_END_OF_STACK; if (code !=3D _URC_NO_REASON) /* Some error encountered. Ususally the unwinder doesn't diagnose these and merely crashes. */ return _URC_FATAL_PHASE1_ERROR; /* Unwind successful. Run the personality routine, if any. */ if (fs.personality) NOTE: fs.personality never evaluates to true { code =3D (*fs.personality) (1, _UA_SEARCH_PHASE, = exc->exception_class, exc, &cur_context); if (code =3D=3D _URC_HANDLER_FOUND) break; else if (code !=3D _URC_CONTINUE_UNWIND) return _URC_FATAL_PHASE1_ERROR; } /* Update cur_context to describe the same frame as fs. */ uw_update_context (&cur_context, &fs); } /* Indicate to _Unwind_Resume and associated subroutines that this is not a forced unwind. Further, note where we found a handler. = */ exc->private_1 =3D 0; exc->private_2 =3D uw_identify_context (&cur_context); cur_context =3D this_context; code =3D _Unwind_RaiseException_Phase2 (exc, &cur_context); if (code !=3D _URC_INSTALL_CONTEXT) return code; uw_install_context (&this_context, &cur_context); } =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Tue Oct 16 04:00:26 2018 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D7FFB10DFE7A for ; Tue, 16 Oct 2018 04:00:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-21.consmr.mail.gq1.yahoo.com (sonic306-21.consmr.mail.gq1.yahoo.com [98.137.68.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C93A678E49 for ; Tue, 16 Oct 2018 04:00:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: z17AQoIVM1mbFSZ8AMx5keokcT1PbUjyxr1ezsLrKpbUDw5qAmuAM.VMo5Gik4t N4sE2VL7jB8Ygf0FccRtQ1TUoLmCWb_5hIVIfvJPbxR16N7VSVKW03uZ9QHA1.kz7nQE8wGVI_GP JY__t3tiCQSCIXa7WdwG5.RJxL8QgO.fR4WJ2QdrT4sokem.XdoMSVpu_UUBCUJ1hGgMBWOkyWsU eTRS9VvmxrEpYqYSOpkfe11kL_ILSVqrSVT2PmHYMGt7TT3aya0ksou.7jFUXl.Hc2ZO1sGYjms6 Wf56SBolvP0hXq34x0jKKu43HjWtibzwXjjuGr28IXEvxt.anLH1_0CDbzLUZVYWhXcO9RuqKAXR bMCJhTBRh1ru2iSiZPGWzkM.MWcdnjOF.VcPr4y.qAQNFdqDiG6LeppiIMta6wueo1SdAufDW8PV .dkSXVwdCc_lVQTeXRGyIY21V1J_KmyiuigFMZ6mdWmrP99dpsFXp52BylCfibqIdW.VQ55AcKQv CXBkHd9fXPbcwP.njaV7SZywy2UqrxB9AUWjJppbVVHO0BGvB9yK.pHZvsD8ZG1w8nhc7roWL0WF ArMFytAZut2mWOHTcNZ6jqKXcDnE41fh.If0YtpslBt0HFqfyv.vnIlsZOuM.WbRjGO0hzziRyIq 8VTwaDICKgwR8v4Imp4nEyQxYvFHd6o12SAT4nLpCrH.6sV73sPHYo6nQrTDX8_F_.9xDn.ojwk8 uKufXRQexAnhyQMv7f_DOtRDrF3kwjzX1Aoaq7vBU9XXcKMnX4BSYNfgr9vhJJqYtYiFtAUPUWMO ho3NherbyWZlGpbo6OkKmh0w_hvkod2BIdi5y5jJsQF2Qi990FmZP3rlWTEVFGJF4zw.PF5LNVfv ROek40xAQgUI3LV7ka7iEl48dTcPvxarkbzSma.FtL3tDP2DenTktDUUHdJHMjvwtkse6_iPFqJa 1D2HQxyURmkF6CXsXMHgba0wgF7wEHQ_00FMYTJVgPRE_ein_dxqoBmCD4Hiedjoo6GdzPZ62ook skq.TEmJN93Mehsc0Q_1.zMLK9efPp8TUnm55OmqyJj4H_pQuiXRgvdSoOWi_oUZmVCNUefNRgzl NoJszC.0dXmfNYA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Tue, 16 Oct 2018 04:00:18 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp431.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID dd93d55728f71f0de1169e4749adc2d5; Tue, 16 Oct 2018 04:00:17 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: FYI: powerpc64 headbuilt via devel/powerpc64-xtoolchain-gcc and C++ exceptions for user code built by system-clang or devel/powerpc64-gcc (as of head -r339076 and ports -r480180) From: Mark Millard In-Reply-To: <0539C16B-1603-4639-914A-0308578C7262@yahoo.com> Date: Mon, 15 Oct 2018 21:00:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3B69D483-AEBA-47CA-B140-7445089EB064@yahoo.com> References: <0539C16B-1603-4639-914A-0308578C7262@yahoo.com> To: FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD Mailing List X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 04:00:26 -0000 [I've found the problem at the low level for my context of using WITH_LIBCPLUSPLUS=3D with the likes of devel/powerpc64-gcc but I do not have a solution for WITH_LIBCPLUSPLUS=3D so far. I give details of what I found.] On 2018-Oct-14, at 12:40 AM, Mark Millard wrote: > On 2018-Oct-12, at 1:59 PM, Mark Millard wrote: >=20 >> I built a powerpc64 head -r339076 via devel/powerpc64-gcc >> and the like that built clang as cc as well (and >> WITHOUT_LIB32). This included use of base/binutils to >> the the powerpc64 set up. The system and kernel are >> non-debug builds (but with symbols). [system-clang is not >> used for buildworld buildkernel because of known >> issues (last I tried).] >>=20 >> booting, buildworld, buildkernel, poudriere building >> what totaled to be somewhat under 400 ports all seem >> to work. But . . . >>=20 >> It been a long time since I've done something analogous >> and a significant item in the result is different than in >> the past once I started testing the throwing of C++ >> exceptions in code produced by system-clang or by >> devel/powerpc64-gcc : >>=20 >> Such code ends up stuck using around 100% of a CPU. >> An example is the program: >>=20 >> # more exception_test.cpp >> #include >>=20 >> int main(void) >> { >> try { throw std::exception(); } >> catch (std::exception& e) {} >> return 0; >> } >>=20 >> For system-clang it ended up with: >>=20 >> # ldd a.out >> a.out: >> libc++.so.1 =3D> /usr/lib/libc++.so.1 (0x81006d000) >> libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x810184000) >> libm.so.5 =3D> /lib/libm.so.5 (0x8101ab000) >> libc.so.7 =3D> /lib/libc.so.7 (0x8101eb000) >> libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x810554000) >>=20 >> That program goes into an possibly unbounded execution. >> (Historically when this program had problems it would >> stop and produce a core file.) >>=20 >> When compiled by devel/powerpc64-gcc the a.out that results >> does the same thing. ( = /usr/local/bin/powerpc64-unknown-freebsd12.0-c++=20 >> as the compiler path ) So this is not really clang specific >> in any way. This ended up with: >>=20 >> # ldd a.out >> a.out: >> libc++.so.1 =3D> /usr/lib/libc++.so.1 (0x81006d000) >> libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x810184000) >> libm.so.5 =3D> /lib/libm.so.5 (0x8101ab000) >> libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x8101eb000) >> libc.so.7 =3D> /lib/libc.so.7 (0x810211000) >>=20 >> (That should not have involved clang or llvm at all.) >>=20 >> But compiled by lang/gcc8's g++8 the a.out that results works >> fine. This ends up with: >>=20 >> # ldd a.out >> a.out: >> libstdc++.so.6 =3D> /usr/local/lib/gcc8/libstdc++.so.6 = (0x81006e000) >> libm.so.5 =3D> /lib/libm.so.5 (0x8102c7000) >> libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x810307000) >> libc.so.7 =3D> /lib/libc.so.7 (0x81032d000) >>=20 >> It is not clear if using base/gcc as system cc >> would do any better than using system-clang does >> or than devel/powerpc64-gcc does: it is sort of >> a variant of devel/powerpc64-gcc . >>=20 >> It will probably be some time before I figure out >> much about what is going on. >>=20 >> Two things common to the problem cases are: >>=20 >> libc++.so.1 =3D> /usr/lib/libc++.so.1 (0x81006d000) >> libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x810184000) >>=20 >> lang/gcc8 avoids those being involved. >>=20 >>=20 >> Notes: >>=20 >> . . . >>=20 >> WITHOUT_LIB32=3D is because, for every post-gcc 4.2.1 >> that I've tried, the lib32 produced misuses R30 in >> crtbeginS code (vs. the ABI for FreeBSD) and 32-bit >> code just produces core files from the bad so-called >> address dereference that results. >>=20 >> I'd rather have throwing C++ exceptions working and >> lack of lib32 than have lib32 but not have throwing >> C++ exceptions working. But at the moment how to have >> such is not obvious when fairly modern compilers >> and toolchains are involved.=20 >=20 > Here is what I've found so far. >=20 > The code is looping in the following routine. > (I've inserted 2 NOTE: lines for what the > sustained looping is like.) >=20 . . . (the routine was _Unwind_RaiseException) . . . So far I've found that the following in _Unwind_RaiseException stays invariant once initialized --despite the uw_frame_state_for and uw_update_context calls in _Unwind_RaiseException 's loop that normally update fs: (gdb) print fs $15 =3D {regs =3D {reg =3D {{loc =3D {reg =3D 0, offset =3D 0, exp =3D = 0x0}, how =3D REG_UNSAVED} , {loc =3D {reg =3D = 18446744073709551608, offset =3D -8,=20 exp =3D 0xfffffffffffffff8 }, how =3D REG_SAVED_OFFSET}, {loc =3D = {reg =3D 0, offset =3D 0, exp =3D 0x0}, how =3D REG_UNSAVED} , { loc =3D {reg =3D 16, offset =3D 16, exp =3D 0x10 }, how =3D REG_SAVED_OFFSET}, {loc =3D {reg =3D = 0, offset =3D 0, exp =3D 0x0}, how =3D REG_UNSAVED} },=20= prev =3D 0x0}, cfa_offset =3D 0, cfa_reg =3D 1, cfa_exp =3D 0x0, = cfa_how =3D CFA_REG_OFFSET, pc =3D 0x8101999f8, personality =3D 0, = data_align =3D -8, code_align =3D 4, retaddr_column =3D 65,=20 fde_encoding =3D 27 '\033', lsda_encoding =3D 255 '?', saw_z =3D 1 = '\001', signal_frame =3D 0 '\0', eh_ptr =3D 0x0} It turns out that pc value 0x8101999f8 is a little after the libcxxrt.so call to _Unwind_RaiseException that is in throw_exception. But _Unwind_RaiseException returning would be a failure and would end up in a non-returning, error-reporting code path. In other words: this is not an appropriate context for following the return path to unwind out of _Unwind_RaiseException and its internal caller (throw_exception). It got to that address from lr containing the address of the instruction after the one that does bl to the _Unwind_RaiseException routine. Overall it needs to unwind past this in the normal case but is stuck handling the error/no-return case as "the" case. Supporting details follow. What lead up to 0x8101999f8 for initialization was the lr value related to calling _Unwind_RaiseException (see the address in lr below, also copied to r5): . . . (gdb) c Continuing. Breakpoint 9, 1: x/i $pc 0x8101f35d8 <_Unwind_RaiseException+216>: bl = 0x8101f2bc0 Current language: auto; currently minimal where the register values being supplied are (see r5 and lr): (gdb) info reg r0 0x8101999f0 34629851632 r1 0x3fffffffffffc320 4611686018427372320 r2 0x810217900 34630367488 r3 0x3fffffffffffd280 4611686018427376256 r4 0x3fffffffffffd930 4611686018427377968 r5 0x8101999f0 34629851632 r6 0xa0 160 r7 0x0 0 r8 0x1 1 r9 0x8101aac10 34629921808 r10 0x1 1 r11 0x28 40 r12 0x28000282 671089282 r13 0x81005d020 34628554784 r14 0x0 0 r15 0x0 0 r16 0x0 0 r17 0x0 0 r18 0x0 0 r19 0x0 0 r20 0x0 0 r21 0x0 0 r22 0x0 0 r23 0x0 0 r24 0x0 0 r25 0x0 0 r26 0x0 0 r27 0x3fffffffffffd280 4611686018427376256 r28 0x810041060 34628440160 r29 0x3fffffffffffc390 4611686018427372432 r30 0x3fffffffffffcd10 4611686018427374864 r31 0x810041008 34628440072 pc 0x8101f35d8 34630219224 ps 0x0 0 cr 0x0 0 lr 0x8101999f0 34629851632 ctr 0x8101f3500 34630219008 xer 0x0 0 fpscr 0xfff80000 -524288 vscr 0x0 0 vrsave 0x0 0 The pc listed in print fs (0x8101999f8) is in the following from libcxxrt, as is the value in r5 and lr (0x8101999f0): (some blank lines inserted to help identify the area and some related material) (gdb) disass throw_exception Dump of assembler code for function throw_exception: 0x0000000810199960 : mflr r0 0x0000000810199964 : std r31,-8(r1) 0x0000000810199968 : mr r31,r3 0x000000081019996c : std r0,16(r1) 0x0000000810199970 : stdu r1,-128(r1) 0x0000000810199974 : bl 0x810197ab0 = 0x0000000810199978 : ld r10,8(r3) 0x000000081019997c : mr r9,r3 0x0000000810199980 : cmpdi cr7,r10,0 0x0000000810199984 : std r10,24(r31) 0x0000000810199988 : beq- cr7,0x810199a10 = 0x000000081019998c : ld r10,0(r9) 0x0000000810199990 : cmpdi cr7,r10,0 0x0000000810199994 : std r10,32(r31) 0x0000000810199998 : beq- cr7,0x8101999d0 = 0x000000081019999c : lwz r10,48(r9) 0x00000008101999a0 : addi r3,r31,88 0x00000008101999a4 : addi r10,r10,1 0x00000008101999a8 : stw r10,48(r9) 0x00000008101999ac : bl 0x81018e500 = <00000018.plt_call._Unwind_RaiseException@@GCC_3.0> 0x00000008101999b0 : ld r2,40(r1) 0x00000008101999b4 : addi r1,r1,128 0x00000008101999b8 : mr r4,r31 0x00000008101999bc : ld r0,16(r1) 0x00000008101999c0 : ld r31,-8(r1) 0x00000008101999c4 : mtlr r0 0x00000008101999c8 : b 0x8101996b0 = 0x00000008101999cc : nop 0x00000008101999d0 : nop 0x00000008101999d4 : addi r3,r31,88 0x00000008101999d8 : ld r10,-30008(r2) 0x00000008101999dc : std r10,32(r31) 0x00000008101999e0 : lwz r10,48(r9) 0x00000008101999e4 : addi r10,r10,1 0x00000008101999e8 : stw r10,48(r9) 0x00000008101999ec : bl 0x81018e500 = <00000018.plt_call._Unwind_RaiseException@@GCC_3.0> 0x00000008101999f0 : ld r2,40(r1) 0x00000008101999f4 : addi r1,r1,128 0x00000008101999f8 : mr r4,r31 0x00000008101999fc : ld r0,16(r1) 0x0000000810199a00 : ld r31,-8(r1) 0x0000000810199a04 : mtlr r0 0x0000000810199a08 : b 0x8101996b0 = 0x0000000810199a0c : nop 0x0000000810199a10 : nop 0x0000000810199a14 : ld r10,-30000(r2) 0x0000000810199a18 : std r10,24(r31) 0x0000000810199a1c : b 0x81019998c = 0x0000000810199a20 : .long 0x0 0x0000000810199a24 : .long 0x90001 0x0000000810199a28 : lwz r0,0(r1) End of assembler dump. For: 0x00000008101999f8 (above) objdump shows: 00000000000159f8 (below): 0000000000015960 <.__cxa_end_catch+0x460> mflr r0 0000000000015964 <.__cxa_end_catch+0x464> std r31,-8(r1) 0000000000015968 <.__cxa_end_catch+0x468> mr r31,r3 000000000001596c <.__cxa_end_catch+0x46c> std r0,16(r1) 0000000000015970 <.__cxa_end_catch+0x470> stdu r1,-128(r1) 0000000000015974 <.__cxa_end_catch+0x474> bl 0000000000013ab0 = <._ZdaPv+0x590> 0000000000015978 <.__cxa_end_catch+0x478> ld r10,8(r3) 000000000001597c <.__cxa_end_catch+0x47c> mr r9,r3 0000000000015980 <.__cxa_end_catch+0x480> cmpdi cr7,r10,0 0000000000015984 <.__cxa_end_catch+0x484> std r10,24(r31) 0000000000015988 <.__cxa_end_catch+0x488> beq cr7,0000000000015a10 = <.__cxa_end_catch+0x510> 000000000001598c <.__cxa_end_catch+0x48c> ld r10,0(r9) 0000000000015990 <.__cxa_end_catch+0x490> cmpdi cr7,r10,0 0000000000015994 <.__cxa_end_catch+0x494> std r10,32(r31) 0000000000015998 <.__cxa_end_catch+0x498> beq cr7,00000000000159d0 = <.__cxa_end_catch+0x4d0> 000000000001599c <.__cxa_end_catch+0x49c> lwz r10,48(r9) 00000000000159a0 <.__cxa_end_catch+0x4a0> addi r3,r31,88 00000000000159a4 <.__cxa_end_catch+0x4a4> addi r10,r10,1 00000000000159a8 <.__cxa_end_catch+0x4a8> stw r10,48(r9) 00000000000159ac <.__cxa_end_catch+0x4ac> bl 000000000000a500 = 00000000000159b0 <.__cxa_end_catch+0x4b0> ld r2,40(r1) 00000000000159b4 <.__cxa_end_catch+0x4b4> addi r1,r1,128 00000000000159b8 <.__cxa_end_catch+0x4b8> mr r4,r31 00000000000159bc <.__cxa_end_catch+0x4bc> ld r0,16(r1) 00000000000159c0 <.__cxa_end_catch+0x4c0> ld r31,-8(r1) 00000000000159c4 <.__cxa_end_catch+0x4c4> mtlr r0 00000000000159c8 <.__cxa_end_catch+0x4c8> b 00000000000156b0 = <.__cxa_end_catch+0x1b0> 00000000000159cc <.__cxa_end_catch+0x4cc> nop 00000000000159d0 <.__cxa_end_catch+0x4d0> nop 00000000000159d4 <.__cxa_end_catch+0x4d4> addi r3,r31,88 00000000000159d8 <.__cxa_end_catch+0x4d8> ld r10,-30008(r2) 00000000000159dc <.__cxa_end_catch+0x4dc> std r10,32(r31) 00000000000159e0 <.__cxa_end_catch+0x4e0> lwz r10,48(r9) 00000000000159e4 <.__cxa_end_catch+0x4e4> addi r10,r10,1 00000000000159e8 <.__cxa_end_catch+0x4e8> stw r10,48(r9) 00000000000159ec <.__cxa_end_catch+0x4ec> bl 000000000000a500 = 00000000000159f0 <.__cxa_end_catch+0x4f0> ld r2,40(r1) 00000000000159f4 <.__cxa_end_catch+0x4f4> addi r1,r1,128 00000000000159f8 <.__cxa_end_catch+0x4f8> mr r4,r31 00000000000159fc <.__cxa_end_catch+0x4fc> ld r0,16(r1) 0000000000015a00 <.__cxa_end_catch+0x500> ld r31,-8(r1) 0000000000015a04 <.__cxa_end_catch+0x504> mtlr r0 0000000000015a08 <.__cxa_end_catch+0x508> b 00000000000156b0 = <.__cxa_end_catch+0x1b0> 0000000000015a0c <.__cxa_end_catch+0x50c> nop 0000000000015a10 <.__cxa_end_catch+0x510> nop 0000000000015a14 <.__cxa_end_catch+0x514> ld r10,-30000(r2) 0000000000015a18 <.__cxa_end_catch+0x518> std r10,24(r31) 0000000000015a1c <.__cxa_end_catch+0x51c> b 000000000001598c = <.__cxa_end_catch+0x48c> 0000000000015a20 <.__cxa_end_catch+0x520> .long 0x0 0000000000015a24 <.__cxa_end_catch+0x524> .long 0x90001 0000000000015a28 <.__cxa_end_catch+0x528> lwz r0,0(r1) And dwarfdump shows starting at 0x00015960 as: < 117><0x00015960:0x00015a2c><> 0x00015960: =20 0x00015968: =20 0x00015974: =20 0x000159b8: =20 0x000159c8: =20 0x000159d0: =20 0x000159f8: =20 0x00015a08: =20 0x00015a10: =20 fde section offset 4120 0x00001018 cie offset for fde: 4124 0x0000101c 0 DW_CFA_advance_loc 8 (2 * 4) 1 DW_CFA_register r65 =3D r0 4 DW_CFA_offset r31 -8 (1 * -8) 6 DW_CFA_advance_loc 12 (3 * 4) 7 DW_CFA_def_cfa_offset 128 10 DW_CFA_offset_extended_sf r65 16 (-2 * -8) 13 DW_CFA_advance_loc 68 (17 * 4) 14 DW_CFA_remember_state 15 DW_CFA_def_cfa_offset 0 17 DW_CFA_advance_loc 16 (4 * 4) 18 DW_CFA_restore_extended r65 20 DW_CFA_restore r31 21 DW_CFA_advance_loc 8 (2 * 4) 22 DW_CFA_restore_state 23 DW_CFA_advance_loc 40 (10 * 4) 24 DW_CFA_remember_state 25 DW_CFA_def_cfa_offset 0 27 DW_CFA_advance_loc 16 (4 * 4) 28 DW_CFA_restore_extended r65 30 DW_CFA_restore r31 31 DW_CFA_advance_loc 8 (2 * 4) 32 DW_CFA_restore_state 33 DW_CFA_nop 34 DW_CFA_nop /usr/src/contrib/libstdc++/libsupc++/eh_throw.cc has something that /usr/src/contrib/libcxxrt/exception.cc does not have in its error handling code path: a use of __cxa_begin_catch=20 in __cxxabiv1::__cxa_throw : #ifdef _GLIBCXX_SJLJ_EXCEPTIONS _Unwind_SjLj_RaiseException (&header->unwindHeader); #else _Unwind_RaiseException (&header->unwindHeader); #endif // Some sort of unwinding error. Note that terminate is a handler. __cxa_begin_catch (&header->unwindHeader); std::terminate (); It looks to me like __cxa_begin_catch might do either of terminate or _Unwind_Resume and that the (conditional) _Unwind_Resume case is possibly needed here for the normal execution. There are also no other calls (bl's) before the terminate: more directly indicated to not return. I do not know if one or both of those points helped the code unwind correctly or not. But it seems suggestive. Other notes: I've demonstrated the problem on my prior head -r333594 environment that had been build via a 6.3 vintage of devel/powerpc64-gcc (but that was then updated to ports -r469844 and so had 6.4 of devel/powerpc64-gcc installed). Also: base/binutils was of a 2.30 vintage and base/gcc was of a 6.3 vintage. (system-clang was not cc, base/gcc provided system-cc.) Compiling to produce the a.out via: /usr/bin/powerpc64-unknown-freebsd12.0-g++ (and so via a 6.3 vintage g++) made no difference. It still had the problem. I have taken to having buildworld buildkernel use -gdwarf-2 so that /usr/libexec/gdb has access to the information in a format it is (mostly) designed for. (/usr/local/bin/gdb is broken by the thrown-C++-exception problem that I'm investigating: gdb internally throws exceptions in normal operation.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Tue Oct 16 22:29:56 2018 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2D65210E3B47 for ; Tue, 16 Oct 2018 22:29:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-21.consmr.mail.ne1.yahoo.com (sonic314-21.consmr.mail.ne1.yahoo.com [66.163.189.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A81F082EE5 for ; Tue, 16 Oct 2018 22:29:55 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: H3tKvo8VM1lL61yMh6CAH_DAz0RjTyHGHoAL3Cl41607ETYPC6GQ4Ay.ZiIddB3 lwDmt6xgyj1vd27RIk_uht3rn2WaTSqkjfIlNGCS2h1fOkH16zcXkwkQE4Nab4QZU3yrfLhON7I9 fPRzZxgv_XdMMKaHoE7A1y9Gq3UmCuguJtgU0qkOeuGBjosvCbK.8_JlrkfPDogmAJmgKAWgguZp CTf_j3qBWQT77b3yTwWZH9KjTMvwNPFPA9hT5rW.ntq.mf8eKpvdVMefPATec02BFPCXGzFUvo.g 3QAOuuiMgsl5BhAhcgunQ50kG0mBLbFYbE62ts8P7ZLzT6193MBbsTFIeZcSVaprvDA9uWKMokQ4 SonwpY1ctf95rU7f7roYBa5MQ4VgT0SjJRWa1rlQtInql9SRVNbfCUSO11bqOZDSdVzwiuKQ9iD5 IyJ1QMNpfHVW.AqAAxq_YYEO4Ut3NYR2piJhtmsLXlvSbGX99Lf8jS5n6ztnwjNcCLsAgrfMKFAx Bh45DK4JA6Vj3a.VuvscMmUVG8x0Qafbz1MaHB_XkvBonwKefZ8FrB2gDvWaJ3z7i2Bc_WRE5sPA 2NJ_LICzvuWO1flzNOxVW9368VA4ldM90BdwjN_BwbBtxFfKQqxU3kLNFVzOx5BSfkEvrdVNmtf1 FWZuEgB2.u3Kd_t1NgWPYLEK6vXOweuKvWT65QJubcE3TKgiGmfdDsAWkiScalJZHu_KEhopJqUh bfN13MlcezuRAQAPtm4wcAOSZ1chlKeKyJ.iQ5jVIozGT8YVI6LfoSljXOpOxOhQIyUwzNh6oCkp BnbFqGyZjjij9SdI4ziNf.dSpFVI19xxF..WAKbDAnYzTLaix.zmctf_E04UOlIAcCktfhafISrF DXpcsQie2tVifS2dXLqWBtfUONWm7y.FC_IaYFQHCISddhjO5CZ8Kphp_L2uEIg.5obJlX5fw0kp Qca3bLjPnNU.Yw1qjrFvYAnprzJ_cZhBlXHEvuKC_9cFMx6zHf9rwnVFAumuU5pjec_oQw5HEBFJ z3HTRXahguBEb.kkXixI3DE4x_zrprV7EM_YG1hB475iqsKySkvKeIzXuXonh4VPFaNdGYaARzmZ o6SHQABNiz3SjrVga7Q-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ne1.yahoo.com with HTTP; Tue, 16 Oct 2018 22:29:48 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp412.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 513438678ecee606fe797d481f79ca2e; Tue, 16 Oct 2018 22:29:46 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: How to get devel/powerpc-gcc based WITH_LIBCPLUSPLUS= buildworld to have some throwing of C++ exceptions work (patch) Message-Id: <86E4687B-280A-4625-A56E-8D6FC4C4675B@yahoo.com> Date: Tue, 16 Oct 2018 15:29:45 -0700 Cc: Justin Hibbits To: FreeBSD PowerPC ML , FreeBSD Toolchain , FreeBSD X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 22:29:56 -0000 I now have a patch that gets some basic C++ exception throwing going for WITH_LIBCPLUSPLUS=3D use when building via devel/powerpc64-gcc . But the overall mechanism seems to mess up the handling of powerpc64's "red zone" style of stack processing in various cases. I've had recent list submittals reporting that buildworld using WITH_LIBCPLUSPLUS=3D based on devel/powerpc64-gcc would get stuck looping in _Unwind_RaiseException. This prevented use of devel/gdb --which makes extensive use of throwing C++ exceptions in normal operation. Well, I now have a patch that avoids the problem in libcxxrt's throw_exception itself that made all throws get stuck --and so allows some C++ exceptions to be thrown. See below. (I'm not sure leading spaces will all be preserved.) Most of text is commentary, not code. # svnlite diff /usr/src/contrib/libcxxrt/ Index: /usr/src/contrib/libcxxrt/exception.cc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/contrib/libcxxrt/exception.cc (revision 339076) +++ /usr/src/contrib/libcxxrt/exception.cc (working copy) @@ -772,10 +772,71 @@ info->globals.uncaughtExceptions++; =20 _Unwind_Reason_Code err =3D = _Unwind_RaiseException(&ex->unwindHeader); +#if !defined(__powerpc64__) && !defined(__ppc64__) // The _Unwind_RaiseException() function should not return, it = should // unwind the stack past this function. If it does return, then = something // has gone wrong. report_failure(err, ex); +#else +// NOTE: Only tested for devel/powerpc64-gcc based buildworld +// because clang still silently ignores +// __builtin_eh_return(offset,handler) for powerpc64 +// (and powerpc), thus not generating correct output. +// +// NOTE: I've no clue if other archtiectures might have +// analogous issues to powerpc64. I'm not sure +// about powerpc because of it still being stuck +// at gcc 4.2.1 . (clang problems and no devel/powerpc-gcc .) +// +// The above/normal code produced the following sort of structure +// for throw_exception. r1 is the stack pointer, note its adjustments +// via stdu r1,-128(r1) and via addi r1,r1,128 . +// +// : mflr r0 +// : std r31,-8(r1) +// : mr r31,r3 +// : std r0,16(r1) +// : stdu r1,-128(r1) +// . . . +// : bl = <00000018.plt_call._Unwind_RaiseException@@GCC_3.0> +// : ld r2,40(r1) +// : addi r1,r1,128 +// : mr r4,r31 +// : ld r0,16(r1) +// : ld r31,-8(r1) +// : mtlr r0 +// : b +// +// The loop in __Unwind_RaiseException had its "fs" +// used with uw_frame_state_for and uw_update_context get +// stuck with the pc field having the address for +// throw_exception+152 (just after the stack adjustment +// addi r1,r1,128). Effectively, throw_exception unwinds +// its stack use before calling report_failure in a +// way that throw_exception is no longer on the stack. +// The exception unwinding logic did not handle this +// correctly and got stuck looping. +// +// The below avoids having any such stack adjustment here +// by avoiding the report_failure call and directly doing +// what case _URC_END_OF_STACK in report_failure does for +// its first couple of lines. (It is also the kind of +// thing that src/contrib/libstdc++/libsupc++/eh_throw.cc +// has in its __cxxabiv1::__cxa_throw after the +// _Unwind_RaiseException call.) +// +// Another option could be to turn report_failure into +// a macro so that no subroutine call could be involved. +// That should avoid the early stack pointer kadjsutment. +// +// Also: For the other archtiectures that I looked at, no +// such stack adjsutments were involved in the code +// generated (or the matching dwarfdump output). +// But I did not look at many. + + __cxa_begin_catch (&(ex->unwindHeader)); + std::terminate(); +#endif } =20 =20 However, code such as the following from devel/kyua leads to other examples of _Unwind_RaiseException looping without making progress. Note the stdu r1,-368(r1) and the addi r1,r1,368 stack pointer adjustments and their timing relative to stack usage (the "red zone" style used for FreeBSD's powerpc64 ABI): (gdb) x/64i 0x100a8528-88 0x100a84d0 : mflr = r0 0x100a84d4 : = std r30,-16(r1) 0x100a84d8 : = std r31,-8(r1) 0x100a84dc : = std r29,-24(r1) 0x100a84e0 : = mr r31,r4 0x100a84e4 : = std r0,16(r1) 0x100a84e8 : = stdu r1,-368(r1) 0x100a84ec : = mr r30,r3 0x100a84f0 : = bl 0x100abab0 0x100a84f4 : = nop 0x100a84f8 : = clrlwi r4,r31,16 0x100a84fc : = bl 0x10009fc0 <000000af.plt_call.mkdir@@FBSD_1.0> 0x100a8500 : = ld r2,40(r1) 0x100a8504 : = cmpwi cr7,r3,-1 0x100a8508 : = beq cr7,0x100a8528 0x100a850c : = addi r1,r1,368 0x100a8510 : = ld r0,16(r1) 0x100a8514 : = ld r29,-24(r1) 0x100a8518 : = ld r30,-16(r1) 0x100a851c : = ld r31,-8(r1) 0x100a8520 : = mtlr r0 0x100a8524 : = blr 0x100a8528 : = bl 0x10009d40 <000000af.plt_call.__error@@FBSD_1.0> . . . (more not shown here) . . . This goes along with (darfdump -v -v -F output): < 1323><0x100a84d0:0x100a8670> 0x100a84d0: =20 0x100a84e0: =20 0x100a84ec: =20 0x100a8510: =20 0x100a8524: =20 0x100a8528: =20 fde section offset 62424 0x0000f3d8 cie offset for fde: 61696 = 0x0000f100 0 DW_CFA_advance_loc 16 (4 * 4) 1 DW_CFA_register r65 =3D r0 4 DW_CFA_offset r30 -16 (2 * -8) 6 DW_CFA_offset r31 -8 (1 * -8) 8 DW_CFA_offset r29 -24 (3 * -8) 10 DW_CFA_advance_loc 12 (3 * 4) 11 DW_CFA_def_cfa_offset 368 14 DW_CFA_offset_extended_sf r65 16 (-2 * -8) 17 DW_CFA_advance_loc 36 (9 * 4) 18 DW_CFA_remember_state 19 DW_CFA_def_cfa_offset 0 21 DW_CFA_advance_loc 20 (5 * 4) 22 DW_CFA_restore_extended r65 24 DW_CFA_restore r31 25 DW_CFA_restore r30 26 DW_CFA_restore r29 27 DW_CFA_advance_loc 4 (1 * 4) 28 DW_CFA_restore_state 29 DW_CFA_nop 30 DW_CFA_nop The _Unwind_RaiseException's fs ends up reaching and the holding the following value in my attempted devel/kyua run for FreeBSD's test suite: (gdb) print fs $9 =3D {regs =3D {reg =3D {{loc =3D {reg =3D 0, offset =3D 0, exp =3D = 0x0}, how =3D REG_UNSAVED} , {loc =3D {reg =3D = 18446744073709551592, offset =3D -24,=20 exp =3D 0xffffffffffffffe8 }, how =3D REG_SAVED_OFFSET}, {loc =3D {reg =3D= 18446744073709551600, offset =3D -16,=20 exp =3D 0xfffffffffffffff0 }, how =3D REG_SAVED_OFFSET}, {loc =3D {reg =3D= 18446744073709551608, offset =3D -8,=20 exp =3D 0xfffffffffffffff8 }, how =3D REG_SAVED_OFFSET}, {loc =3D {reg =3D= 0, offset =3D 0, exp =3D 0x0},=20 how =3D REG_UNSAVED} , {loc =3D {reg =3D 16, = offset =3D 16, exp =3D 0x10 }, how =3D REG_SAVED_OFFSET}, {loc =3D {reg =3D 0, offset =3D 0,=20 exp =3D 0x0}, how =3D REG_UNSAVED} }, prev =3D= 0x0}, cfa_offset =3D 0, cfa_reg =3D 1, cfa_exp =3D 0x0, cfa_how =3D = CFA_REG_OFFSET,=20 pc =3D 0x100a8528 ,=20= personality =3D @0x810549c40: 0x81053c900 <__gxx_personality_v0(int, = _Unwind_Action, uint64_t, _Unwind_Exception*, _Unwind_Context*)>, = data_align =3D -8, code_align =3D 4, retaddr_column =3D 65,=20 fde_encoding =3D 27 '\033', lsda_encoding =3D 20 '\024', saw_z =3D 1 = '\001', signal_frame =3D 0 '\000', eh_ptr =3D 0x0} Note the invariant value it is looping with (fs.pc value): pc =3D 0x100a8528 But the routine is at 0x00000000100a85ec : (gdb) bt #0 _Unwind_RaiseException (exc=3D0x8109582e0) at = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind.inc:103 #1 0x000000081053d704 in throw_exception (ex=3D0x810958288) at = /usr/src/contrib/libcxxrt/exception.cc:774 #2 0x00000000100a85ec in utils::fs::mkdir (dir=3D..., = mode=3Dmode@entry=3D493) at utils/fs/operations.cpp:484 #3 0x00000000100a8694 in utils::fs::mkdir_p (dir=3D..., mode=3D) at utils/fs/operations.cpp:502 #4 0x000000001000cbf4 in (anonymous namespace)::safe_main = (mock_command=3D..., argv=3D0x3fffffffffffdb88, argc=3D4, = ui=3D0x3fffffffffffd960, this=3D, this=3D) = at cli/main.cpp:207 #5 cli::main (ui=3Dui@entry=3D0x3fffffffffffd960, argc=3Dargc@entry=3D4, = argv=3Dargv@entry=3D0x3fffffffffffdb88, mock_command=3D...) at = cli/main.cpp:280 #6 0x000000001000e9dc in cli::main (argc=3D, = argv=3D0x3fffffffffffdb88) at cli/main.cpp:353 #7 0x000000001000c570 in main (argc=3D, argv=3D) at main.cpp:49 where utils::fs::mkdir: 0x00000000100a85d0 <+256>: bne 0x100a85f0 = 0x00000000100a85d4 <+260>: addis r9,r2,-1 0x00000000100a85d8 <+264>: addis r10,r2,-1 0x00000000100a85dc <+268>: mr r3,r29 0x00000000100a85e0 <+272>: addi r5,r9,20864 0x00000000100a85e4 <+276>: addi r4,r10,-12216 0x00000000100a85e8 <+280>: bl 0x1000a140 = <000000af.plt_call.__cxa_throw@@CXXABI_1.3> =3D> 0x00000000100a85ec <+284>: ld r2,40(r1) 0x00000000100a85f0 <+288>: ld r3,320(r1) 0x00000000100a85f4 <+292>: bl 0x1000a8c0 = <000000af.plt_call._ZdlPv> 0x00000000100a85f8 <+296>: ld r2,40(r1) 0x00000000100a85fc <+300>: b 0x100a85d4 = This is for the devel/kyua code: void fs::mkdir(const fs::path& dir, const int mode) { if (::mkdir(dir.c_str(), static_cast< mode_t >(mode)) =3D=3D -1) { const int original_errno =3D errno; throw fs::system_error(F("Failed to create directory %s") % dir, original_errno); } } I've not figured out how to make general throwing of C++ exceptions avoid this _Unwind_RaiseException unbounded looping with a fixed fs.pc value. But at least now I can use devel/gdb for some of the investigation's activity. Other notes: WITH_LLVM_LIBUNWIND=3D does not even compile for targeting powerpc64 --so that is not currently a way around the problem. WITHOUT_LIB32=3D yse is because, for every post-gcc 4.2.1 that I've tried, the lib32 produced misuses R30 in crtbeginS code (vs. the ABI for FreeBSD) and 32-bit code just produces core files from a bad so-called address that is dereferenced via R30 content. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Wed Oct 17 10:00:03 2018 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2003A10D03EE for ; Wed, 17 Oct 2018 10:00:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-20.consmr.mail.bf2.yahoo.com (sonic312-20.consmr.mail.bf2.yahoo.com [74.6.128.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B392C7A000 for ; Wed, 17 Oct 2018 10:00:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: lj3DrygVM1loCiK1nJl0qzBV9C7DR93JYWzQuICiHW5eOr3RPSrmmwVqIkGk7Ed Pd0QcZHUZmBlE8GvI8I2OJd6uX.kHMeBJu3129C1oJwETOXNxd7ATit7nPsqpH5qxro98mjoddF7 a2YeDO5xNOvKchvetxS6O3emKOWLz_GplLVRM9ftc5QaVXWhZ.DG919S3_mmRdpRerYtoa4bgv2T xQ1Xeib_OMD8bXlTT_v4v7A1gLbbUDVN2tyvqX7iKyEHWkNjLlMgpNZM6Rq3dGDNxfaygkMCo.JE EHc980a0fa7z2QmIVnBdTj1bwjr2OdAKDeID217wGx6oddxVOYZdebTttWE.EaA9ff2m6uu880Tg gG7U5I3p64ZgRbPz5ildOnhrLvaRnSm_dXMUZxJX1y4RLUlrRcpjrpQRhAjSHYMP1845lCx9Jcdt QBe6HAFmqohoSiV11TerE_JdnN3EnObyMTe.8.UkaY3sL3cCmax5ZK0lLWvtQFnIiSWIbsBwnOmN q340PFUk3qN5Z5ChlYK4DbmZKwHtYOOrdmosLnm8pIDBMKo9n78ttC54dnLPK8rtYvKCUU_A_8as q7uZTxHYU1CBNxVNAqxvdrq6fHOlFBoxdByLh8VianBzVO_75CC6oS26R5qwVfD4AND3fEJqVAQX qNUyvwWmOcOKJQQfBFpyMehYe.qVzO2l3HuObLWM60IvYt3gMaWaABfx4UCkx7nwjwTVPflOxlrF 8444mJUFyGSF.pDhe8D7h8U5.r7hODbTWmr9A00AMaDMxzuYoBsmwOKKgLBphjOru1jdfusNuPLg .PyX.y8CMO.2Z3HC.JIw01mrX8BMdG8sritfRHQjY12.qaOMf15qLE7fLitYbdESZR3lvqPPKOEZ TLO7gvRS4EhsTLt0lstGUw57RuZwsHLrkiZovM7NlfsxM75kbUdy0zZCsiQGsYiZnYx0NW0jJUAo uslixYASSVQS5Vbu1MHAtxAFC5jzp0LiBqYeJi8i_M.ZZsOF9HI4sMrji0F0sf_KVlbQrOyIH8_3 sZEl2Br.2atceKMnOUtnb9fWPJlUlqpqucmrr83lXwDvuYHXyo8DmyzQHMnzaABHDiWINGSht_f7 NJpuv0JOiltqRpOxmBw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.bf2.yahoo.com with HTTP; Wed, 17 Oct 2018 09:59:56 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp402.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 262adbda998196774548452c497e7325; Wed, 17 Oct 2018 09:59:54 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: /lib/libgcc_s.so.1 mishandles eh_frame information that /usr/local/lib/gcc8/libgcc_s.so.1 handles (powerpc64 test context): a simple example program Message-Id: <4D444DB3-A472-42BC-973E-3E468C07757B@yahoo.com> Date: Wed, 17 Oct 2018 02:59:51 -0700 Cc: Justin Hibbits To: FreeBSD Toolchain , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 10:00:03 -0000 (I happen to be using head -r339076 and ports -r480180 vintage materials, not that I expect such narrow vintage ties.) I finally have a simple example of the issue on powerpc64 . . . The following simple C++ program shows a significant difference for powerpc64 depending on which libgcc_s.so is used (system's vs. gcc8's): # more exception_test1.cpp=20 #include // -O2 context used. volatile unsigned int v =3D 1; extern int f() { volatile unsigned char c =3D 'a'; v++; // Despite "volatile" the access to v in g // was otherwise optimized out and the // std::exception was not followed by // code for f(). So force g's use. return c; } extern void g() { if (v) throw std::exception(); f(); // ends up inlined but the problem is demonstrated. } int main(void) { try {g();} // Used a separate function to avoid any potential // special handling of code in main. Call not // optimized out. catch (std::exception& e) {} return 0; } (gcc8 just happens to be the lang/gcc* that I have installed. Similar points likely apply to gcc[?-8]. The same problem can be demonstrated by devel/powerpc64-gcc use, which ends up using /lib/libgcc_s.so.1 as well --but does not provide the contrasting "it works" case.) The only reason for the try/catch is to avoid the "it works" case from doing: # ./a.out terminate called after throwing an instance of 'std::exception' what(): std::exception Abort trap (core dumped) Just calling g() is enough to have the problem with /lib/libgcc_s.so.1 . The program works fine for being built via: # g++8 -Wl,-rpath=3D/usr/local/lib/gcc8 -g -O2 exception_test1.cpp # ldd a.out a.out: libstdc++.so.6 =3D> /usr/local/lib/gcc8/libstdc++.so.6 = (0x81006e000) libm.so.5 =3D> /lib/libm.so.5 (0x8102c7000) libgcc_s.so.1 =3D> /usr/local/lib/gcc8/libgcc_s.so.1 = (0x810307000) libc.so.7 =3D> /lib/libc.so.7 (0x810330000) But fails, stuck looping in _Unwind_RaiseException, for being built via: # g++8 -g -O2 exception_test1.cpp # ldd a.out a.out: libstdc++.so.6 =3D> /usr/local/lib/gcc8/libstdc++.so.6 = (0x81006e000) libm.so.5 =3D> /lib/libm.so.5 (0x8102c7000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x810307000) libc.so.7 =3D> /lib/libc.so.7 (0x81032d000) The only difference (other than detailed addresses) is: libgcc_s.so.1 =3D> /usr/local/lib/gcc8/libgcc_s.so.1 = (0x810307000) vs. libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x810307000) The dwarfdump -v -v -F reports match exactly for the two builds of the program, as does the code for the function g where the problem is observed. What is different is that /lib/libgcc_s.so.1 misinterprets the .eh_frame information (disagreeing with the dwarfdump report and with /usr/local/lib/gcc8/libgcc_s.so.1 behavior). # dwarfdump -v -v -F a.out | more .eh_frame fde: < 0><0x100007a0:0x10000840><> 0x100007a0: =20 fde section offset 20 0x00000014 cie offset for fde: 24 0x00000018 0 DW_CFA_nop 1 DW_CFA_nop 2 DW_CFA_nop < 1><0x10000840:0x10000894>
0x10000840: =20 0x1000084c: =20 0x10000854: =20 0x10000860: =20 0x10000864: =20 fde section offset 152 0x00000098 cie offset for fde: 36 0x00000024 0 DW_CFA_advance_loc 12 (3 * 4) 1 DW_CFA_def_cfa_offset 112 3 DW_CFA_offset_extended_sf r65 16 (-2 * -8) 6 DW_CFA_advance_loc 8 (2 * 4) 7 DW_CFA_remember_state 8 DW_CFA_def_cfa_offset 0 10 DW_CFA_advance_loc 12 (3 * 4) 11 DW_CFA_restore_extended r65 13 DW_CFA_advance_loc 4 (1 * 4) 14 DW_CFA_restore_state < 2><0x10000db0:0x10000ddc> 0x10000db0: =20 fde section offset 64 0x00000040 cie offset for fde: 68 0x00000044 0 DW_CFA_nop 1 DW_CFA_nop 2 DW_CFA_nop < 3><0x10000de0:0x10000e5c> 0x10000de0: =20 0x10000de8: =20 0x10000e14: =20 0x10000e18: =20 0x10000e1c: =20 0x10000e24: =20 fde section offset 84 0x00000054 cie offset for fde: 88 0x00000058 0 DW_CFA_advance_loc 8 (2 * 4) 1 DW_CFA_def_cfa_offset 128 4 DW_CFA_advance_loc 44 (11 * 4) 5 DW_CFA_remember_state 6 DW_CFA_def_cfa_offset 0 8 DW_CFA_advance_loc 4 (1 * 4) 9 DW_CFA_restore_state 10 DW_CFA_advance_loc 4 (1 * 4) 11 DW_CFA_register r65 =3D r0 14 DW_CFA_advance_loc 8 (2 * 4) 15 DW_CFA_offset_extended_sf r65 16 (-2 * -8) 18 DW_CFA_nop < 4><0x10000ee0:0x10000f34><> 0x10000ee0: =20 0x10000ee4: =20 0x10000ef8: =20 fde section offset 40 0x00000028 cie offset for fde: 44 0x0000002c 0 DW_CFA_advance_loc 4 (1 * 4) 1 DW_CFA_register r65 =3D r12 4 DW_CFA_advance_loc 20 (5 * 4) 5 DW_CFA_restore_extended r65 cie: < 0> version 1 cie section offset 0 0x00000000 augmentation zR code_alignment_factor 4 data_alignment_factor -8 return_address_register 65 eh aug data len 0x1 bytes 0x1b=20 bytes of initial instructions 3 cie length 16 initial instructions 0 DW_CFA_def_cfa r1 0 < 1> version 1 cie section offset 120 0x00000078 augmentation zPLR code_alignment_factor 4 data_alignment_factor -8 return_address_register 65 eh aug data len 0xb bytes 0x94 00 00 00 00 00 01 04 c9 14 1b=20 bytes of initial instructions 3 cie length 28 initial instructions 0 DW_CFA_def_cfa r1 0 In: < 3><0x10000de0:0x10000e5c> 0x10000de0: =20 0x10000de8: =20 0x10000e14: =20 0x10000e18: =20 0x10000e1c: =20 0x10000e24: =20 The last 3 128's are from the DW_CFA_restore_state from the sequence: 1 DW_CFA_def_cfa_offset 128 . . . 5 DW_CFA_remember_state . . . 9 DW_CFA_restore_state But with /lib/libgcc_s.so.1 the 128 is not saved and restored, leaving default 0's in place instead. And use of the wrong stack addresses results, which in turn prevents the stack from unwinding past g()'s frame. [Note: For FreeBSD on powerpc64 r1 is the stack-pointer.] The code described by the: < 3><0x10000de0:0x10000e5c> . . . is as follows. Note the stdu r1,-128(r1) and the addi r1,r1,128 and what code only used via bne cr7,0x10000e18 and that it has the stdu r1,-128(r1) prior context, not addi r1,r1,128: (gdb) disass g Dump of assembler code for function g(): 0x0000000010000de0 <+0>: nop 0x0000000010000de4 <+4>: stdu r1,-128(r1) 0x0000000010000de8 <+8>: lwz r9,-32536(r2) 0x0000000010000dec <+12>: cmpdi cr7,r9,0 0x0000000010000df0 <+16>: bne cr7,0x10000e18 0x0000000010000df4 <+20>: li r9,97 0x0000000010000df8 <+24>: nop 0x0000000010000dfc <+28>: stb r9,112(r1) 0x0000000010000e00 <+32>: lwz r9,-32536(r2) 0x0000000010000e04 <+36>: addi r9,r9,1 0x0000000010000e08 <+40>: stw r9,-32536(r2) 0x0000000010000e0c <+44>: lbz r9,112(r1) 0x0000000010000e10 <+48>: addi r1,r1,128 0x0000000010000e14 <+52>: blr 0x0000000010000e18 <+56>: mflr r0 0x0000000010000e1c <+60>: li r3,8 0x0000000010000e20 <+64>: std r0,144(r1) 0x0000000010000e24 <+68>: bl 0x100007a0 = <0000004b.plt_call.__cxa_allocate_exception@@CXXABI_1.3> 0x0000000010000e28 <+72>: ld r2,40(r1) 0x0000000010000e2c <+76>: nop 0x0000000010000e30 <+80>: nop 0x0000000010000e34 <+84>: ld r9,-32720(r2) 0x0000000010000e38 <+88>: ld r5,-32712(r2) 0x0000000010000e3c <+92>: nop 0x0000000010000e40 <+96>: ld r4,-32704(r2) 0x0000000010000e44 <+100>: std r9,0(r3) 0x0000000010000e48 <+104>: bl 0x10000820 = <0000004b.plt_call.__cxa_throw@@CXXABI_1.3> 0x0000000010000e4c <+108>: ld r2,40(r1) 0x0000000010000e50 <+112>: .long 0x0 0x0000000010000e54 <+116>: .long 0x90001 0x0000000010000e58 <+120>: lwz r0,0(0) [Note: more than the 128's might not be handled right for more general code, but the example only shows the 128's issue (i.e., the cfa_offset mishandling issue).] I'll note that throw_exception in /lib/libgcc_s.so.1 has the same sort of machine-code structure as g relative to cfa_offset's and that, without a workaround to avoid that structure being generated, all thrown C++ exceptions fail by _Unwind_RaiseException being stuck in a loop for powerpc64. In order to test the simple program I used the workaround: # svnlite diff /usr/src/contrib/libcxxrt/ Index: /usr/src/contrib/libcxxrt/exception.cc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/contrib/libcxxrt/exception.cc (revision 339076) +++ /usr/src/contrib/libcxxrt/exception.cc (working copy) @@ -772,10 +772,71 @@ info->globals.uncaughtExceptions++; _Unwind_Reason_Code err =3D = _Unwind_RaiseException(&ex->unwindHeader); +#if !defined(__powerpc64__) && !defined(__ppc64__) // The _Unwind_RaiseException() function should not return, it = should // unwind the stack past this function. If it does return, then = something // has gone wrong. report_failure(err, ex); +#else +// NOTE: Only tested for devel/powerpc64-gcc based buildworld +// because clang still silently ignores +// __builtin_eh_return(offset,handler) for powerpc64 +// (and powerpc), thus not generating correct output. +// +// NOTE: I've no clue if other archtiectures might have +// analogous issues to powerpc64. I'm not sure +// about powerpc because of it still being stuck +// at gcc 4.2.1 . (clang problems and no devel/powerpc-gcc .) +// +// The above/normal code produced the following sort of structure +// for throw_exception. r1 is the stack pointer, note its adjustments +// via stdu r1,-128(r1) and via addi r1,r1,128 . +// +// : mflr r0 +// : std r31,-8(r1) +// : mr r31,r3 +// : std r0,16(r1) +// : stdu r1,-128(r1) +// . . . +// : bl = <00000018.plt_call._Unwind_RaiseException@@GCC_3.0> +// : ld r2,40(r1) +// : addi r1,r1,128 +// : mr r4,r31 +// : ld r0,16(r1) +// : ld r31,-8(r1) +// : mtlr r0 +// : b +// +// The loop in __Unwind_RaiseException had its "fs" +// used with uw_frame_state_for and uw_update_context get +// stuck with the pc field having the address for +// throw_exception+152 (just after the stack adjustment +// addi r1,r1,128). Effectively, throw_exception unwinds +// its stack use before calling report_failure in a +// way that throw_exception is no longer on the stack. +// The exception unwinding logic did not handle this +// correctly and got stuck looping. +// +// The below avoids having any such stack adjustment here +// by avoiding the report_failure call and directly doing +// what case _URC_END_OF_STACK in report_failure does for +// its first couple of lines. (It is also the kind of +// thing that src/contrib/libstdc++/libsupc++/eh_throw.cc +// has in its __cxxabiv1::__cxa_throw after the +// _Unwind_RaiseException call.) +// +// Another option could be to turn report_failure into +// a macro so that no subroutine call could be involved. +// That should avoid the early stack pointer kadjsutment. +// +// Also: For the other archtiectures that I looked at, no +// such stack adjsutments were involved in the code +// generated (or the matching dwarfdump output). +// But I did not look at many. + + __cxa_begin_catch (&(ex->unwindHeader)); + std::terminate(); +#endif } =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Wed Oct 17 20:25:50 2018 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 03DBB10DE806 for ; Wed, 17 Oct 2018 20:25:50 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-22.consmr.mail.gq1.yahoo.com (sonic301-22.consmr.mail.gq1.yahoo.com [98.137.64.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 093E8905D7 for ; Wed, 17 Oct 2018 20:25:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: .17zpVUVM1mNnfw6qZnnlw061.Segc8FdcVUgNsvTmB9z6anzaXPsRxzu.xUlWG XoykGuRCrwNL0IpO90jz27_P3TFPN9lLo7HRFoBWQVpXmz7Yd6WfYkXvtjCexuDIzNKyUW0ucnkO OBAnbi4xXmqsDGTcLVfe4lc7CW90AyQPvGnVrxJGSVCQxTSBKX2j7723LSPb5dBOcF0bi7vHs7x2 dD6KRV.mrt8tR.m6ki7PMkCWqzyOUIt_wXUUslaUcpE5aGbIJS92M.CXPybvCePGE0646iFSu_ka giF0dGnTpUD5fw6Hi.6i1kP4rPBx7ZJeRxLpS4cBgdNW3iciKzzDmapspgPWsP0CHn.9jqVN9JKB 64Vv3xWglFOOvTnYEQUgnV_LGHm9SFFWBCEGjI.1Vqjl5tYnzDq816F0FngxTJqbK_Bx9eOHha1e 2tdJ_PIJNj6V3pxEsDQZ12D8E2HDuF7Ix2E8RkTMPHDVOB2R9rMQXWRaw9jxJECUUAuc7Ul27iYG plKsEYS2L_bLTdVORUnPFDqUfx6XHJ9aXvLW2uJRe76pc6MKxevZnIxACvEiB9tQBQIKsZFQswJo 3bRnmyvPRzzyVwP0he80jLvT4MXIe6Fsg2GTyO4fiYolX07fig1KnIZYq27HhbxlJC_P4k1._FlZ L0HtMQTHGGr9ggWvww7w7mYe0ecyEGxq4Q8moct1WsQWhrOf4rxGCLIfZWnu75P5MGvLVAvkVNCO DpSa01D8nx44xnRoMQA1gpMuW5G2_OUbLLRLeKUfKyEeysslm4fSmF__JtdzYKXN9QnJ6YWfgB1C 9Ea1mApJvKPxEqbViksKSxu7ZzTSUlOXBX4sXkgzBIVEGshktXq2v644DcxnIUzfdDGLia6WS_zw aZhT9rj8cjy48hIFaa7YlSjRQWLT938oSOcdFNuRkv2KgHIudc1o5mXC4Q6Eh.sp6nNxWIzboF2x CLPkdN8PcPbSfJpl.GfEXSE4Sz3IhNfLGXLQzk6UG9AMiopmJFbsZsDW7oHJSaRwtPZT.uKAjfBy jgtyAU_d4.ohptH4OsDwIYIdQbRjLTU9gEoGmIIucszgdt0YlN6oYYz6en_sMqVzPbMeowXQX9iV LMhA3zBqH9RSen_4- Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.gq1.yahoo.com with HTTP; Wed, 17 Oct 2018 20:25:42 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp428.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 80e922adb91863636bdf56988756cc64; Wed, 17 Oct 2018 20:25:40 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: What is incomplete for /lib/libgcc_s.so-based C++ exception handling (where WITH_LLVM_LIBUNWIND= and /usr/local/lib/gcc*/libgcc_s.so are not used) Message-Id: <0379371E-0541-42DD-93EF-BEE2E9DE3FBC@yahoo.com> Date: Wed, 17 Oct 2018 13:25:39 -0700 Cc: FreeBSD PowerPC ML To: FreeBSD Toolchain , FreeBSD , freebsd-arch@freebsd.org X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 20:25:50 -0000 [This summarizes other results without the code and debugger evidence and such from my recent explorations. It should be much easier to follow than my exploration reports.] Documents like DWARF5.pdf document the "row" vs. Location information for Call Frame Information as (also used for .eh_frame like materials for C++ exception handling): (CFA: Cannonical Frame Address) QUOTE ("Structure of Call Frame Information") LOC CFA R0 R1...RN L0 L1 ... LN END QUOTE Note that the CFA is conceptually one of the registers in each row, even though it is not a machine register but a way to calculate the conceptual register's value from machine registers. The information for the machine registers are typically based on the earlier CFA value (from the same row!). Absent a correct CFA cell in a row, most potential use of that row is likely messed up. One way CFA is found is by adding an offset to the value of a machine register for the range in question, Ln up to L(n+1) [or based on the end of the overall range for the last Ln]. I will use that for illustration because there are examples of this in my testing. /lib/libgcc_s.so.1 does not implement this fully for some DW_CFA_* operations: QUOTE (note the "every register" reference, so including CFA) DW_CFA_remember_state The DW_CFA_remember_state instruction takes no operands. The required = action is to push the set of rules for every register onto an implicit = stack. DW_CFA_restore_state The DW_CFA_restore_state instruction takes no operands. The required = action is to pop the set of rules off the implicit stack and place them = in the current row. END QUOTE In other words: push and pop a complete row, not just machine registers information from the row. For example, the the "cfa_offset" for computing the CFA value from from a register is not saved and restored. Nor is which register the offset is based on. (This can vary, though not in my examples.) In general the CFA cell is not saved and restored, what ever its contents. So any compiler that produces code depending on DW_CFA_remember_state and DW_CFA_restore_state for .eh_frame like material ends up with C++ exception handling messed up when the DW_CFA_restore_state should change the CFA to a=20 non-default one (from the prior DW_CFA_remember_state). This prevents reliable use of throwing C++ exceptions when building via the likes of devel/powerpc64-gcc or lang/gcc8 ( when not using -Wl,-rpath=3D-Wl,-rpath=3D/usr/local/lib/gcc8 so that /lib/libgcc_s.so.1 ends up being used). One result can be _Unwind_RaiseException looping looking at the same frame over and over instead of progressing to the next frame. For example, this happens via cfa_offset 0 being used. devel/powerpc64-gcc -O2 code tends to get that. Notes: For powerpc64, clang++ tends to use another register (%r31) with the old value (of %r1, the stack pointer) instead of involving the DW_CFA_remember_state/DW_CFA_restore_state pair based on just %r1. (clang has other problems relative to sue for buildworld buildkernel.) Code generation styles matter for if the incomplete coverage by /lib/libgcc_s.so will be visible or not. At this stage, WITH_LLVM_LIBUNWIND=3D builds targeting powerpc64 do not even compile/assemble the relevant code, apparently both because of darwin specific assembler code and FreeBSD's build not using the C-preprocessor on the .S file as required. (There could be more to getting it working.) I do not know about other architecture/compiler (or toolchain) combinations that may not yet be able to use WITH_LLVM_LIBUNWIND=3D . But I'd expect a potentially similar status from some. A range of modern /usr/local/lib/gcc*/libgcc_s.so do implement DW_CFA_remember_state/DW_CFA_restore_state operations and they are put to use. So using the likes of -Wl,-rpath=3D/usr/local/lib/gcc8 works for g++8 C++ exception handling (but is problematical for buildworld buildkernel). I made a similar exploration of the issue in around early 2016 and got basically the same results, not that I remembered much. But I now have a small source code example that shows the cfa_offset issue for the likes of devel/powerpc64-gcc output. The standard source for throw_exception in /lib/libgcc_s.so produces the cfa_offset problem when devel/powerpc64-gcc is used to buildworld. This turns all thrown C++ exceptions in to unbounded looping in _Unwind_RaiseException for that kind of context. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Wed Oct 17 22:27:03 2018 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DECE110E0804 for ; Wed, 17 Oct 2018 22:27:02 +0000 (UTC) (envelope-from al@datazap.net) Received: from agnus.datazap.net (agnus.datazap.net [209.160.43.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5C410935FA for ; Wed, 17 Oct 2018 22:27:02 +0000 (UTC) (envelope-from al@datazap.net) Received: from [127.0.0.1] (localhost [127.0.0.1]) by agnus.datazap.net (Postfix) with ESMTP id 0CC80B7951; Wed, 17 Oct 2018 18:26:49 -0400 (EDT) From: Al Subject: Re: Best PowerPC hardware To: Justin Hibbits Cc: freebsd-ppc@freebsd.org References: <1cb6deb1-5448-819a-3d01-9ba747dad6b9@datazap.net> <20181009092640.039299b3@ralga.knownspace> Message-ID: <33c5d19e-bae8-0e3c-63c3-8afe0231fb0e@datazap.net> Date: Thu, 18 Oct 2018 00:26:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux ppc64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20181009092640.039299b3@ralga.knownspace> Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 22:27:03 -0000 On 09/10/18 16:26, Justin Hibbits wrote: > On Tue, 9 Oct 2018 15:01:07 +0200 > Al wrote: > >> Hello, >> >> I have an AmigaOne X5000 and I was wondering what would be the best >> supported raid controller and ethernet card. I would like to have a >> dual port ethernet card, not really sure about the raid controller. >> >> Kind Regards, >> Al > Hi Al, > > I don't know about a RAID card, but the onboard ethernet is fully > supported already by FreeBSD. However, a minor change needs to be made > to the FDT. A sample device tree is located at > https://people.freebsd.org/~jhibbits/cyrus_p5020_amiga.dts or > https://people.freebsd.org/~jhibbits/cyrus_p5020_amiga2.dtb > > Instructions can be found at > http://forum.hyperion-entertainment.biz/viewtopic.php?f=58&t=3948 > > - Justin > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to"freebsd-ppc-unsubscribe@freebsd.org" > Hello Justin, I would like to have 10GB ethernet and at least 3 drives (it is the only way to get enough disk space). Kind Regards, Al From owner-freebsd-ppc@freebsd.org Wed Oct 17 23:58:47 2018 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DE72D10E216C for ; Wed, 17 Oct 2018 23:58:46 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3D3AF960D3 for ; Wed, 17 Oct 2018 23:58:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: PPteCJUVM1ksqxca1Nb25pD5wYsH5IO2NftvasuIgZByx9Ycr65msez1gVmaPo7 wZ2eLYJgNFq7tispBNBYQyLtV6OBHUP1CobFKSj5XhXkhhv.kriUwcnkKG1dboSDDoRnSE6jUk0C VntvyKzgwlraKeo8XKYhznJMlygi32Sz5ShGPdGL4m1N7LI8xHMIjgPFwaVCNIRbf8KZ2CxwzUMQ iAiXDZ3o762UP8hhXysimYQdeeTtgfvYiIEpCDiSg9thuijIU52ziA9r1Y.0tqjX3tt0AyxmgeEw 7t3i9RkNmhu2.zhsPhPbwr41kPyrfTtUZZzLiwneSkk.eH.0R7zhPbPD69FEsNZHDfOeAeXGvkct Ne.W510_SlS4.nlguBFcRRtYVetVOgMuc4i1ZXe6672ju3wCyaKH31LT4g7LpY9LoqPDgMT7Ob_3 Bfi9SjIvg2B5bCqscmngok.dVh1d7vY3XxXjHVjobXWbdaikA5yUcs7wAOBwKsPKsn3KB3aohn4. ZjWvWwf6KGpFGYN1IVYCUcRhoYj6WopPb_o7t1s9Pb6vLWi.xcbwvnsj7gGRG24ERP9Qj28c_TYg X4gSdYQ5iuEfyZQhnbsfVntOoSGjxwfLtSrVrYqD_V0EdyLzhpGPFBq356AXjztvbsQqHeGvg.Td HnTRDBAJWQjzYb0327AEGdwU4Dz8Gl2jNmJLcRnVEqAWeWdb4gIR3dCjn1FM0I1RNn8GiotrHQf6 S.Ath1r5sN2uNzwPuBMpMWR9VTSR8XSYPGh8r7GuOuzmSWPywXTOH3dWbnWod2jXAB2_lQ5dRkhC jl5xowEaqRsEni7.eN7PCdEG0lJmKFaNLU_.tNGGIaJbhsIPrZsX3yJrd8cLPuy92p8apz0hzM3f Q0ZlGnP5zaGZFnJuFEyj4Klikozk1QOPJiz5IQn1faRbM3wiZ0OMhD7W6u9PTiS4QGm_78ewL6Wi 8sBz.k2q3yW.lW0zFo.7LflWtU37un88a.hmLPmq3vKVMRsXhf8qYUhfyUf_AA4r36ePNhSOBfUQ FZThkFyOhxJ7IEdoXGgZUJlhbF1gFlC71bOGw0ajJHvBB2DrkkByS9eDmc.YUenHRs0xYC0QwsC2 AAnUNaFip Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Wed, 17 Oct 2018 23:58:44 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp430.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 4fd2a5038af2887d49a08e8b1f10a004; Wed, 17 Oct 2018 23:58:40 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: head -r339076 based powerpc64 context: fatal kernel trap Stopped at lock_init+0x78 stw r9,0x8(r3) Message-Id: <99B35B13-29AA-406D-941B-95408C603FEF@yahoo.com> Date: Wed, 17 Oct 2018 16:58:40 -0700 To: FreeBSD Current , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 23:58:47 -0000 On a powerpc64 with builworld buildkernel built via devel/powerpc64-xtoolchain-gcc for head -r339076 (some source adjustments), and a system-cc-is-clang I attempted a: # kyua test -k /usr/tests/Kyuafile It got to: sys/netinet/reuseport_lb:basic_ipv4 -> failed: = /usr/src/tests/sys/netinet/reuseport_lb.c:165: bind() failed: Address = already in use [0.014s] sys/netinet/reuseport_lb:basic_ipv6 -> failed: = /usr/src/tests/sys/netinet/reuseport_lb.c:221: bind() failed: Address = already in use [0.014s] sys/netipsec/tunnel/aes_cbc_128_hmac_sha1:v4 -> =20 and then the system crashed. I am re-running to see what happens. The context has a non-debug kernel (but with symbols). Hand transcribed from a picture . . . fatal kernel trap: exception =3D 0x300 (data storage interrupt) virtual address =3D 0xbfffffffffba8530 dsisr =3D 0x42000000 srr0 =3D 0x72b054 srr1 =3D 0x9000000000009032 current msr =3D 0x9000000000009032 lr =3D 0x69948c curthread =3D 0xc000000036f7f000 pid =3D 12798, comm =3D ifconfig [ thread pid 12798 tid 100312 ] Stopped at lock_init+0x78 stw r9,0x8(r3) db:0:kdb.enter.default> bt Tracing pid 12798 tid 100312 td 0xc000000036f7f000 0xe00000004646e330: at 0xe00000004646e36c 0xe00000004646e360: at epair_modevent+0xf0 0xe00000004646e410: at module_register_init+0xe8 0xe00000004646e4a0: at linker_laod_module+0x6f8 0xe00000004646e580: at kern_kldload+0x150 0xe00000004646e5e0: at sys_kldload+0xb80 0xe00000004646e630: at trap+0xef4 0xe00000004646e790: at powerpc_interrupt+0x12c 0xe00000004646e820: user sc trap by 0x81017fcf8 srr1 =3D 0x900000000000f032 r1 =3D 0x3fffffffffffcfe0 cr =3D 0x28022482 xer =3D 0x20000000 ctr =3D 0x81017fcf0 r2 =3D 0x810336300 # uname -apKU FreeBSD FBSDG5L 12.0-ALPHA8 FreeBSD 12.0-ALPHA8 #4 r339076M: Mon Oct 15 = 13:19:35 PDT 2018 = markmi@FBSDG5L:/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr= /src/powerpc.powerpc64/sys/GENERIC64vtsc-NODBG powerpc powerpc64 = 1200084 1200084 ports was at -r480180. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Thu Oct 18 01:29:45 2018 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8BEA710E5304 for ; Thu, 18 Oct 2018 01:29:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-23.consmr.mail.ne1.yahoo.com (sonic311-23.consmr.mail.ne1.yahoo.com [66.163.188.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 247C771CD4 for ; Thu, 18 Oct 2018 01:29:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 6sTlYNYVM1kYwbCbf_VP5UAOl7yLCXZt0sxsHujtldrioEkg9nVXOCTkXY29tnK mnQHoz9h06umJDLK81gQK9tqgUKpXSUDfEEyzcTMvtLOc8phu4jZUnS_XG5obHsB3is7bLq9qj99 y_eWrG3upxjZIc3P2eJbNm14pJsXbAvtWaJMjjSnb1jQtLzPsu7.ExAMZ_teY7Ay9G3sci.3rbVd ii7KmRKSZA325R51voAoenb17ac6ym58xXbsWomjhe8eduMIkCKpCT1NRwhJiPhlmseviZUtLcq6 NQttnA4q7BfR5b81fzrU.ioJwiOE5x9nMo4PSSFj8DYfc57_kI6k.BLOx0_URLbWNoZjbnOB1PPz rGB.Ae8mIO8mtLfXhHhwOELrvXhFKuD1C9Oo_CBKJhZ8g9t570hFgrai5TEuOAF0RhYde7lpxlJe n3veX2zJoOk712YwjwTwon7CaUQgeFWiHFgPQTmKXBDqStDC.PDQrkBxCr8vGXBbCKPVaQ6mAGcs 6bOB8x3UQNKejG9J.kg4jnUpPFwwgKxG8ZYsUB3o4i0xqpHFijUprpRPlZkLjkcIddsNKhKNXWzz .h.sD.IoZRu5iqz2FJF0LA5NVNc52AzqJK_WqdA_E33qK7CzYI9y.uh_ZWwU0KsxY69fBDcVB0wM mtC.MVnzT6EC.nvKfI9zuPKFcNlXkEeRA9SzqzkWh2HunNqv3elijHtXdHH9GScl2VH3cfYSLuZH qkTpusxAOw.TdtoVkarzdsNqStdzcI5DOtxslLGq9Dj8.BjhwgKx2j66lHo0l13vGu2c4OAwZcG_ lXttVpisekrjX.CMULXu7j5zzkgHH5jvCd1qRTYXyHELPNlsEkDli0bA.nksatHeF_TX6cQKY9A. 5ecwhsDo62o1.HKOWoeUzx2_PPz1oewUMbKTGpBxXitrposkbSIoJ.0kH9o98fPZlJl_LpfGuJPm i52R0UP8nJfkMOMawGFuq_DoGKfaFjYuvgBYsCY5esxxbizAPBulFTIt1i4lq_hGwGYn88nEjN8J V.V2cDv8zrsJaReXrqnXrn2VSJt0crCEOJQYYRNljpfl5aKHUVyBIMipLrGdOzx2eBLun82daKh7 Rza5.MIGIJA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.ne1.yahoo.com with HTTP; Thu, 18 Oct 2018 01:29:38 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp428.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 916d410345b2b90fbfd77f42c4df7e11; Thu, 18 Oct 2018 01:29:33 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: head -r339076 based powerpc64 context: fatal kernel trap [ during /usr/tests/Kyuafile's sys/netipsec/tunnel/aes_cbc_128_hmac_sha1:v4 ] Date: Wed, 17 Oct 2018 18:29:32 -0700 References: <99B35B13-29AA-406D-941B-95408C603FEF@yahoo.com> To: FreeBSD Current , FreeBSD PowerPC ML In-Reply-To: <99B35B13-29AA-406D-941B-95408C603FEF@yahoo.com> Message-Id: <184CA6E2-AA51-4DE3-A3AA-1E9901316050@yahoo.com> X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 01:29:45 -0000 [I got another data storage interrupt failure, again during kyaua showing: sys/netipsec/tunnel/aes_cbc_128_hmac_sha1:v4 -> but the backtrace looks different. See below.] On 2018-Oct-17, at 4:58 PM, Mark Millard wrote: > On a powerpc64 with builworld buildkernel built via > devel/powerpc64-xtoolchain-gcc for head -r339076 > (some source adjustments), and a system-cc-is-clang > I attempted a: >=20 > # kyua test -k /usr/tests/Kyuafile >=20 > It got to: >=20 > sys/netinet/reuseport_lb:basic_ipv4 -> failed: = /usr/src/tests/sys/netinet/reuseport_lb.c:165: bind() failed: Address = already in use [0.014s] > sys/netinet/reuseport_lb:basic_ipv6 -> failed: = /usr/src/tests/sys/netinet/reuseport_lb.c:221: bind() failed: Address = already in use [0.014s] > sys/netipsec/tunnel/aes_cbc_128_hmac_sha1:v4 -> =20 >=20 > and then the system crashed. I am re-running to > see what happens. >=20 > The context has a non-debug kernel (but with > symbols). >=20 > Hand transcribed from a picture . . . >=20 > fatal kernel trap: >=20 > exception =3D 0x300 (data storage interrupt) > virtual address =3D 0xbfffffffffba8530 > dsisr =3D 0x42000000 > srr0 =3D 0x72b054 > srr1 =3D 0x9000000000009032 > current msr =3D 0x9000000000009032 > lr =3D 0x69948c > curthread =3D 0xc000000036f7f000 > pid =3D 12798, comm =3D ifconfig >=20 > [ thread pid 12798 tid 100312 ] > Stopped at lock_init+0x78 stw r9,0x8(r3) > db:0:kdb.enter.default> bt > Tracing pid 12798 tid 100312 td 0xc000000036f7f000 > 0xe00000004646e330: at 0xe00000004646e36c > 0xe00000004646e360: at epair_modevent+0xf0 > 0xe00000004646e410: at module_register_init+0xe8 > 0xe00000004646e4a0: at linker_laod_module+0x6f8 Should have been: linker_load_module > 0xe00000004646e580: at kern_kldload+0x150 > 0xe00000004646e5e0: at sys_kldload+0xb80 > 0xe00000004646e630: at trap+0xef4 > 0xe00000004646e790: at powerpc_interrupt+0x12c > 0xe00000004646e820: user sc trap by 0x81017fcf8 > srr1 =3D 0x900000000000f032 > r1 =3D 0x3fffffffffffcfe0 > cr =3D 0x28022482 > xer =3D 0x20000000 > ctr =3D 0x81017fcf0 > r2 =3D 0x810336300 >=20 >=20 > # uname -apKU > FreeBSD FBSDG5L 12.0-ALPHA8 FreeBSD 12.0-ALPHA8 #4 r339076M: Mon Oct = 15 13:19:35 PDT 2018 = markmi@FBSDG5L:/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr= /src/powerpc.powerpc64/sys/GENERIC64vtsc-NODBG powerpc powerpc64 = 1200084 1200084 >=20 > ports was at -r480180. >=20 Again failed during: sys/netinet/reuseport_lb:basic_ipv4 -> failed: = /usr/src/tests/sys/netinet/reuseport_lb.c:165: bind() failed: Address = already in use [0.013s] sys/netinet/reuseport_lb:basic_ipv6 -> failed: = /usr/src/tests/sys/netinet/reuseport_lb.c:221: bind() failed: Address = already in use [0.013s] sys/netipsec/tunnel/aes_cbc_128_hmac_sha1:v4 -> =20 The backtrace this time shows (hand transcribed): fatal kernel trap: exception =3D 0x300 (data storage interrupt) virtual address =3D 0xc00000008cab6530 dsisr =3D 0x42000000 srr0 =3D 0xe000000046e5b228 srr1 =3D 0x9000000000009032 current msr =3D 0x9000000000009032 lr =3D 0xe000000046e5b220 curthread =3D 0xc00000000d48e000 pid =3D 9666, comm =3D jail [ thread pid 9666 tid 100185 ] Stopped at vnet_epair_init+0x78: stdx r3,r29,r30 db:0:kdb.enter.default> bt Tracing pid 9666 tid 100185 td 0xc00000000d48e000 0xe0000000470a1240: at vnet_sysinit+0x64 0xe0000000470a1270: at vnet_alloc+0xfc 0xe0000000470a12d0: at kern_jail_set+0x1e30 0xe0000000470a15e0: at sys_jail_set+08c 0xe0000000470a1630: at trap+0xef4 0xe0000000470a1790: at powerpc_interrupt+0x12c 0xe0000000470a1820: user sc trap by 0x81016a888 srr1 =3D 0x900000000000f032 r1 =3D 0x3fffffffffffd090 cr =3D 0x28002482 xer =3D 0x20000000 ctr =3D 0x81016a880 r2 =3D 0x810322300 I got a core.txt.0 this time. it reported: . . . epair3a: Ethernet address: 02:60:27:70:4b:0a epair3b: Ethernet address: 02:60:27:70:4b:0b epair3a: link state changed to UP epair3b: link state changed to UP fatal kernel trap: exception =3D 0x300 (data storage interrupt) virtual address =3D 0xc00000008cab6530 dsisr =3D 0x42000000 srr0 =3D 0xe000000046e5b228 (0xe000000046e5b228) srr1 =3D 0x9000000000009032 current msr =3D 0x9000000000009032 lr =3D 0xe000000046e5b220 (0xe000000046e5b220) curthread =3D 0xc00000000d48e000 pid =3D 9666, comm =3D jail =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Thu Oct 18 04:23:36 2018 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B0FA910C8C21 for ; Thu, 18 Oct 2018 04:23:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-21.consmr.mail.gq1.yahoo.com (sonic314-21.consmr.mail.gq1.yahoo.com [98.137.69.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 33AB67939A for ; Thu, 18 Oct 2018 04:23:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: E4.XtDEVM1l0yha6DF78uxiHMvsXSLu3vK.OSldLbgqrYp6yi9z78qQj8sWFJ6G h.rNb1P_5yfSgYBfIS1.dADpidrakngkM2KWFREM70YGZI6PjORHR.egcx90TE2njkU9EIlCyWyo FJXtqko_ppK2jURUNqFGBxdO_LiR0oBUrgWMbgqDm4k9rQSvxeZ0Zl8iXLR6pOC.6N6AHfqhMmht BDcGQBeGVn.shwZXuwC2tmtYqCu8qVYrILChVQ5aM9dI44jeY_pdpXeF.qI8Tc8WXVt0jVje0YC3 IXKg.i0F.SbIIuk9DmcyG1bVjtfjUfI7GS2lCfu1UJFeckxQxgFWPK9gllxEX9SR_4sJZHkBNDUd 4MVc3uDrdFZXrHVWa.zadxxn9DPPwMxR_g19M1vhj_sgTRRLz2V6ppo_Ov8fF3DwB1HZDy2qIktE P0Zwh1HvfOnMNj.69yTfY5UOLSwGpNv_G38PyPo.TMOL62RmrCYs5QT4iUgpZ8nYhRBRcvyzBnce BMrdnljKrHICHDfx0a9JJmx__H5GHUxwocvUXbDaE.u1GgJXpY303sWMKoNug7taucUY_2eHPlw_ b4cf8e.xZJIrxBwm68FEXU2iZglAHyraQnbuCkDVU49QAPWdguNNiVm6sTN740DCONxX3LNnjVNb L_CG1NFgtdremQJZ9LE4sFIA.2M1KAHdfQCjUK5Y5rY.yXNE.kakRLtqwfhco7AxGzxsFT8b5SvC YZEHLOLSWWdDu_.sbF8MXI0zV.vRjBIKFijY412UnXPXYGUF5M3JZbxyTH_T.ZQTycAj_XvGxeO. M7I3boAgHINypTMOSgh2hLKrCUJ5VsuYwMu5HteFpFZFQBVcss8bWM9EVEQML2WV6hzSP1A2l_4a 2TJTrJHsfu9gmtwxidSmTjBHYOAe.TTjr8oaIcQNK4pvyvItB6WkP5dH4hFpq9E9ObRxbZ1IG40B I1Q6bsKRZqS1y.A1NaXC94TSLGGDto.XD0ruEK9fQHUFFafczxSe.Fdx5IFwZShUbY2Q6Oj9LMME OyuSFwhmEwHCHqqIplgIcN7aMnioMuwXWt0n4tRmyn4dWD_UChuOXX8wJti1Dhu2qKeUNDkD47k6 .svpJ0N_kpNahW2cDhdM8A9xKCDErKUJ0UjEsXFk51w-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Thu, 18 Oct 2018 04:23:28 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp426.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 83a235b65b2c28163d7db5778881d38a; Thu, 18 Oct 2018 04:23:26 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: head -r339076 based powerpc64 context: fatal kernel trap [ during /usr/tests/Kyuafile's sys/netipsec/tunnel/aes_cbc_128_hmac_sha1:v4 ] From: Mark Millard In-Reply-To: <184CA6E2-AA51-4DE3-A3AA-1E9901316050@yahoo.com> Date: Wed, 17 Oct 2018 21:23:26 -0700 Cc: Matthew Macy Content-Transfer-Encoding: quoted-printable Message-Id: <0B19E87B-D44F-4B59-BB5A-0EC31974A1E8@yahoo.com> References: <99B35B13-29AA-406D-941B-95408C603FEF@yahoo.com> <184CA6E2-AA51-4DE3-A3AA-1E9901316050@yahoo.com> To: FreeBSD Current , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 04:23:36 -0000 [Booting a debug kernel reported a lock order reversal that might be relevant. The problem repeated again: seems to always fail in my context. The backtrace is like the prior one, but for the debug kernel build being used this time.] On 2018-Oct-17, at 6:29 PM, Mark Millard wrote: > [I got another data storage interrupt failure, again > during kyaua showing: >=20 > sys/netipsec/tunnel/aes_cbc_128_hmac_sha1:v4 -> >=20 > but the backtrace looks different. See below.] >=20 > On 2018-Oct-17, at 4:58 PM, Mark Millard wrote: >=20 >> On a powerpc64 with builworld buildkernel built via >> devel/powerpc64-xtoolchain-gcc for head -r339076 >> (some source adjustments), and a system-cc-is-clang >> I attempted a: >>=20 >> # kyua test -k /usr/tests/Kyuafile >>=20 >> It got to: >>=20 >> sys/netinet/reuseport_lb:basic_ipv4 -> failed: = /usr/src/tests/sys/netinet/reuseport_lb.c:165: bind() failed: Address = already in use [0.014s] >> sys/netinet/reuseport_lb:basic_ipv6 -> failed: = /usr/src/tests/sys/netinet/reuseport_lb.c:221: bind() failed: Address = already in use [0.014s] >> sys/netipsec/tunnel/aes_cbc_128_hmac_sha1:v4 -> =20 >>=20 >> and then the system crashed. I am re-running to >> see what happens. >>=20 >> The context has a non-debug kernel (but with >> symbols). >>=20 >> Hand transcribed from a picture . . . >>=20 >> fatal kernel trap: >>=20 >> exception =3D 0x300 (data storage interrupt) >> virtual address =3D 0xbfffffffffba8530 >> dsisr =3D 0x42000000 >> srr0 =3D 0x72b054 >> srr1 =3D 0x9000000000009032 >> current msr =3D 0x9000000000009032 >> lr =3D 0x69948c >> curthread =3D 0xc000000036f7f000 >> pid =3D 12798, comm =3D ifconfig >>=20 >> [ thread pid 12798 tid 100312 ] >> Stopped at lock_init+0x78 stw r9,0x8(r3) >> db:0:kdb.enter.default> bt >> Tracing pid 12798 tid 100312 td 0xc000000036f7f000 >> 0xe00000004646e330: at 0xe00000004646e36c >> 0xe00000004646e360: at epair_modevent+0xf0 >> 0xe00000004646e410: at module_register_init+0xe8 >> 0xe00000004646e4a0: at linker_laod_module+0x6f8 >=20 > Should have been: linker_load_module >=20 >> 0xe00000004646e580: at kern_kldload+0x150 >> 0xe00000004646e5e0: at sys_kldload+0xb80 >> 0xe00000004646e630: at trap+0xef4 >> 0xe00000004646e790: at powerpc_interrupt+0x12c >> 0xe00000004646e820: user sc trap by 0x81017fcf8 >> srr1 =3D 0x900000000000f032 >> r1 =3D 0x3fffffffffffcfe0 >> cr =3D 0x28022482 >> xer =3D 0x20000000 >> ctr =3D 0x81017fcf0 >> r2 =3D 0x810336300 >>=20 >>=20 >> # uname -apKU >> FreeBSD FBSDG5L 12.0-ALPHA8 FreeBSD 12.0-ALPHA8 #4 r339076M: Mon Oct = 15 13:19:35 PDT 2018 = markmi@FBSDG5L:/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr= /src/powerpc.powerpc64/sys/GENERIC64vtsc-NODBG powerpc powerpc64 = 1200084 1200084 >>=20 >> ports was at -r480180. >>=20 >=20 > Again failed during: >=20 > sys/netinet/reuseport_lb:basic_ipv4 -> failed: = /usr/src/tests/sys/netinet/reuseport_lb.c:165: bind() failed: Address = already in use [0.013s] > sys/netinet/reuseport_lb:basic_ipv6 -> failed: = /usr/src/tests/sys/netinet/reuseport_lb.c:221: bind() failed: Address = already in use [0.013s] > sys/netipsec/tunnel/aes_cbc_128_hmac_sha1:v4 -> =20 >=20 >=20 > The backtrace this time shows (hand transcribed): >=20 > fatal kernel trap: >=20 > exception =3D 0x300 (data storage interrupt) > virtual address =3D 0xc00000008cab6530 > dsisr =3D 0x42000000 > srr0 =3D 0xe000000046e5b228 > srr1 =3D 0x9000000000009032 > current msr =3D 0x9000000000009032 > lr =3D 0xe000000046e5b220 > curthread =3D 0xc00000000d48e000 > pid =3D 9666, comm =3D jail >=20 > [ thread pid 9666 tid 100185 ] > Stopped at vnet_epair_init+0x78: stdx r3,r29,r30 > db:0:kdb.enter.default> bt > Tracing pid 9666 tid 100185 td 0xc00000000d48e000 > 0xe0000000470a1240: at vnet_sysinit+0x64 > 0xe0000000470a1270: at vnet_alloc+0xfc > 0xe0000000470a12d0: at kern_jail_set+0x1e30 > 0xe0000000470a15e0: at sys_jail_set+08c > 0xe0000000470a1630: at trap+0xef4 > 0xe0000000470a1790: at powerpc_interrupt+0x12c > 0xe0000000470a1820: user sc trap by 0x81016a888 > srr1 =3D 0x900000000000f032 > r1 =3D 0x3fffffffffffd090 > cr =3D 0x28002482 > xer =3D 0x20000000 > ctr =3D 0x81016a880 > r2 =3D 0x810322300 >=20 > I got a core.txt.0 this time. it reported: >=20 > . . . > epair3a: Ethernet address: 02:60:27:70:4b:0a > epair3b: Ethernet address: 02:60:27:70:4b:0b > epair3a: link state changed to UP > epair3b: link state changed to UP >=20 > fatal kernel trap: >=20 > exception =3D 0x300 (data storage interrupt) > virtual address =3D 0xc00000008cab6530 > dsisr =3D 0x42000000 > srr0 =3D 0xe000000046e5b228 (0xe000000046e5b228) > srr1 =3D 0x9000000000009032 > current msr =3D 0x9000000000009032 > lr =3D 0xe000000046e5b220 (0xe000000046e5b220) > curthread =3D 0xc00000000d48e000 > pid =3D 9666, comm =3D jail >=20 >=20 epair3a: Ethernet address: 02:60:27:70:4b:0a epair3b: Ethernet address: 02:60:27:70:4b:0b epair3a: link state changed to UP epair3b: link state changed to UP lock order reversal: 1st 0x13be260 allprison (allprison) @ /usr/src/sys/kern/kern_jail.c:960 2nd 0x15964a0 vnet_sysinit_sxlock (vnet_sysinit_sxlock) @ = /usr/src/sys/net/vnet.c:575 stack backtrace: #0 0x6f6520 at witness_debugger+0xf4 #1 0x6f8440 at witness_checkorder+0xa1c #2 0x675690 at _sx_slock_int+0x70 #3 0x675810 at _sx_slock+0x1c #4 0x7f4338 at vnet_sysinit+0x38 #5 0x7f44dc at vnet_alloc+0x118 #6 0x62ab84 at kern_jail_set+0x3274 #7 0x62b62c at sys_jail_set+0x8c #8 0xa8a798 at trap+0x9a0 #9 0xa7e660 at powerpc_interrupt+0x140 fatal kernel trap: exception =3D 0x300 (data storage interrupt) virtual address =3D 0xc00000008df1df30 dsisr =3D 0x42000000 srr0 =3D 0xe000000047854e98 (0xe000000047854e98) srr1 =3D 0x9000000000009032 current msr =3D 0x9000000000009032 lr =3D 0xe000000047854e90 (0xe000000047854e90) curthread =3D 0xc0000000206b6000 pid =3D 9464, comm =3D jail (Hand transcribed from here on:) [ thread pid 9464 tid 100296 ] Stopped at vnet_epair_init+0x78: stdx r3,r29,r30 db:0:kdb.enter.default> bt Tracing pid 9464 tid 100296 td 0xc0000000206b6000 0xe000000047274240: at vnet_sysinit+0x70 0xe000000047274270: at vnet_alloc+0x118 0xe000000047274300: at kern_jail_set+0x32740 0xe000000047274610: at sys_jail_set+08c 0xe000000047274660: at trap+0x9a0 0xe000000047274790: at powerpc_interrupt+0x140 0xe000000047274820: user sc trap by 0x81016a888 srr1 =3D 0x900000000000f032 r1 =3D 0x3fffffffffffd080 cr =3D 0x28002482 xer =3D 0x20000000 ctr =3D 0x81016a880 r2 =3D 0x810322300 There are past reports of the lock order reversal, such as: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D210907 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Thu Oct 18 15:27:32 2018 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2CFC10DF729 for ; Thu, 18 Oct 2018 15:27:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-13.consmr.mail.bf2.yahoo.com (sonic315-13.consmr.mail.bf2.yahoo.com [74.6.134.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3A2DA8FF6B for ; Thu, 18 Oct 2018 15:27:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: xDy_OXsVM1nWU1xZ.hl3.35PCBK__MVEjZ6y4.DtrC_lnSzi1GLAKIS7H8F6OMy oXYOMlt.herlMhzdknv2hLgSEWL01Ris97r1e_RieSuqk2REO9sl2ftr81hcCagbWuuKAMZRvbpY g485ZE8R2L6m3eykWyjbVz7BLRrPTvmwnGlD4DLZuVloY5YW5mVZbAU_xjx3DODU8RxJpswlY6VC _DiRadEuZ4__svMMSzIZ9.VsBHWSEYJY3000fm0OxkyJPzeUZ9pQfiXpQ1hkzp0egZAANIxJfHFC t3A.Xud8fOOGgN617lGqZW5R0CnWE3msl8AKF18ih3DeysSLIT0CybmQ4U6cogED42OZfAM_gMFX hvlsvIRFmQi7PZWoty.Um6UQ4bslSDJF8GLAZAwKiQqx646Ws43k5k0golc9hNLpgsxSLKwazGZp dkrJewE2fcmMcBeIAtJhrFsop3bG1wbp8DCa5vThGZKWi7nt0y9VRA3PZhxZOTSMXKtdSJGihVw1 .HPk3gghW5AlHnqP4Cvs5EqfRVck41iNvrb1E2gVW7VvMpTa1i9BhzAusmZfSkeCxkNuHzroPOTg XlmYpj4VQJbljjPULKwSL6klj30BkfEg3TkuCRPhE84qLm6opFmm06SzJ6GKnZ7BIYXkOBiWAAgh _gnLpRlCMiA5p81n2nGINUhKiVp.yJY3Z2wuGHgYOW3NZonmcahWh7AZ8TLrEA5VR7p5w3CHq9uj ksRczX8Umb0lPoX9Y9MvZIjPAcmSvTueVPWEUz9Fd9_F0IarVf0CTytMhCJ.l_nsFrjcLDMnwrn3 DHrsbzFzMhAUzXDlCTmSIZ2aD_RWCXrwsgpdvRWl5q7Jv_9ZpvgT3aXFokkqaz91xnmdKGkd.yQv AbiQBfYdvP_N3DIBrCReK.OnFoJ0RBT.Ow3Myc7P9nKJ8wtojxEt2G_.k9kukRnoppZPhJoJWPHU hA6bqasPSqHvVfQsFC.qSnyaOJoprA9VMttPHkyWVYryLGQsyxDTMBxIA8ZeWi5zN6r9l7APHqZI XXZ6DDcjn7FFsZJ04vFVXZKdZbgQ1G4czdWjcSkp0x1eXqTuCcVDX1Uwc0ewIgNkRWfTVxnTrobh H5DPAgmnetQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.bf2.yahoo.com with HTTP; Thu, 18 Oct 2018 15:27:26 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp410.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 69a1cb364fe6e02169fe50961f9109f1; Thu, 18 Oct 2018 15:27:24 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Reasons to still not build buildworld buildkernel via system-clang --John Baldwin notes one I was unaware of Message-Id: <23400842-E5CB-4251-BFE5-78D524A64012@yahoo.com> Date: Thu, 18 Oct 2018 08:27:22 -0700 To: Justin Hibbits , Nathan Whitehorn , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 15:27:32 -0000 I described to John Baldwin what I know of for why clang is not yet appropriate to buildworld buildkernel for powerpc64 and powerpc: QUOTE Unfortunately, clang is broken in other ways for buildworld buildkernel use for targeting powerpc64 or powerpc: A) it silently ignores __builtin_eh_return(offset,handler) and so produces system-library code that is broken relative to handling thrown C++ exceptions. B) it produces types of linkage for buildkernel that FreeBSD does not handle, leading to dynamic loads of .ko files that crash the system. (Back in clang 4 days it did not have this problem and I was running kernels built by clang.) END QUOTE John Baldwin reported back something of which I was unaware: QUOTE It will also get the TLS model wrong for powerpc. Both MIPS and powerpc have an implicit default to PIC mode and llvm interprets this implicit PIC to mean that it should use dynamic TLS models (intended for use in shared libraries) always. GCC only uses dynamic models if -fPIC is explicitly passed on the command line. I have a hack to force the TLS model for static libraries and binaries for MIPS in bsd.*.mk that isn't in-tree, but it really needs to be fixed in clang and llvm. END QUOTE I wonder if there is anything in llvm's bugzilla about this, or FreeBSD's bugzilla for that matter. Are there other known issues not covered by the above 3? === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Thu Oct 18 17:47:57 2018 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3BF87EFC92F for ; Thu, 18 Oct 2018 17:47:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DE35874F1C for ; Thu, 18 Oct 2018 17:47:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id CFF667755; Thu, 18 Oct 2018 17:47:56 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id CB64C7754 for ; Thu, 18 Oct 2018 17:47:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 988F774F1A for ; Thu, 18 Oct 2018 17:47:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id E40CED5B for ; Thu, 18 Oct 2018 17:47:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w9IHltNX062599 for ; Thu, 18 Oct 2018 17:47:55 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w9IHltPX062598 for powerpc@FreeBSD.org; Thu, 18 Oct 2018 17:47:55 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 232387] head -r339076: system crash in vnet_epair_init during kern_jail_set in a kyua test on powerpc64 Date: Thu, 18 Oct 2018 17:47:56 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: vimage X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: bz@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: powerpc@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to keywords Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 17:47:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D232387 Bjoern A. Zeeb changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@FreeBSD.org |powerpc@FreeBSD.org Keywords| |vimage --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-ppc@freebsd.org Thu Oct 18 18:24:52 2018 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4DB75EFDA63 for ; Thu, 18 Oct 2018 18:24:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EE85876831 for ; Thu, 18 Oct 2018 18:24:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id DFD39864; Thu, 18 Oct 2018 18:24:51 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id D9EEE863 for ; Thu, 18 Oct 2018 18:24:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A724A7682E for ; Thu, 18 Oct 2018 18:24:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id F37ED131F for ; Thu, 18 Oct 2018 18:24:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w9IIOork060352 for ; Thu, 18 Oct 2018 18:24:50 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w9IIOovr060351 for powerpc@FreeBSD.org; Thu, 18 Oct 2018 18:24:50 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 232387] head -r339076: system crash in vnet_epair_init during kern_jail_set in a kyua test on powerpc64 Date: Thu, 18 Oct 2018 18:24:51 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: vimage X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: marklmi26-fbsd@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: powerpc@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 18:24:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D232387 --- Comment #3 from Mark Millard --- (In reply to Bjoern A. Zeeb from comment #2) show reg will require crashing again. But you might be initially more interested in an official kernel build's behavior. The official powerpc64 and powerpc builds are via gcc 4.2.1 toolchain builds. For powerpc64 I can try substituting kernel materials from, say, somewhere like: https://artifact.ci.freebsd.org/snapshot/stable-11/r*/powerpc/powerpc64/ker= nel*.txz or https://download.freebsd.org/ftp/snapshots/powerpc/powerpc64/12.0-*/kernel*= .txz (assuming that you do not care about the buildworld/ports side of things). It will be a while before I have such results. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-ppc@freebsd.org Thu Oct 18 19:37:35 2018 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3BCB7F71513 for ; Thu, 18 Oct 2018 19:37:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DBACD7A620 for ; Thu, 18 Oct 2018 19:37:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id D3BD7276B; Thu, 18 Oct 2018 19:37:34 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id D18BC276A for ; Thu, 18 Oct 2018 19:37:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9F3797A61E for ; Thu, 18 Oct 2018 19:37:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id E83541CF6 for ; Thu, 18 Oct 2018 19:37:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w9IJbXLQ031386 for ; Thu, 18 Oct 2018 19:37:33 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w9IJbXRL031385 for powerpc@FreeBSD.org; Thu, 18 Oct 2018 19:37:33 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 232387] head -r339076: system crash in vnet_epair_init during kern_jail_set in a kyua test on powerpc64 Date: Thu, 18 Oct 2018 19:37:34 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: vimage X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: marklmi26-fbsd@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: powerpc@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 19:37:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D232387 --- Comment #4 from Mark Millard --- (In reply to Bjoern A. Zeeb from comment #2) stable-11 was the wrong path. More like: https://artifact.ci.freebsd.org/snapshot/head/r*/powerpc/powerpc64/kernel*.= txz But, unfortunately, -r339076 vintage official builds do not boot old PowerMac G5 so-called "Quad Core"s. I'm trying to find some official vintage that works via just a kernel substitution instead of needing to set up a private gcc 4.2.1 based build with patches. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-ppc@freebsd.org Thu Oct 18 22:02:06 2018 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C7345F76B0C for ; Thu, 18 Oct 2018 22:02:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 713CA80E40 for ; Thu, 18 Oct 2018 22:02:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id 677A75C15; Thu, 18 Oct 2018 22:02:06 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 600A55C14 for ; Thu, 18 Oct 2018 22:02:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 36B6E80E3D for ; Thu, 18 Oct 2018 22:02:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 853E831AC for ; Thu, 18 Oct 2018 22:02:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w9IM25Dl096939 for ; Thu, 18 Oct 2018 22:02:05 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w9IM25Kc096938 for powerpc@FreeBSD.org; Thu, 18 Oct 2018 22:02:05 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 232387] head -r339076: system crash in vnet_epair_init during kern_jail_set in a kyua test on powerpc64 Date: Thu, 18 Oct 2018 22:02:05 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: vimage X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: marklmi26-fbsd@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: powerpc@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 22:02:07 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D232387 --- Comment #5 from Mark Millard --- (In reply to Bjoern A. Zeeb from comment #2) -r339269 (the last version before the opensll update and bump of __FreeBSD_version) does not boot the old PowerMac G5 "Quad Core". In my context, simply setting up a test of an officially-built-kernel seems problematical. So it looks like I'll just build from my test environment's sources via gcc 4.2.1 . . . . And the result was no crash but the test failed: sys/netipsec/tunnel/aes_cbc_128_hmac_sha1:v4 -> failed: atf-check failed;= see the output of the test for details [0.652s] But for all I know the failure could be before the activity that was leading to crashes, possibly there by skipping the internal step that has the problem. So I view this as inconclusive. I'm not sure that you want to be looking into devel/powerpc64-xtoolchain-gcc styles of builds if that is the only context that I get the crashes with. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-ppc@freebsd.org Thu Oct 18 23:43:53 2018 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C696AF78C7B for ; Thu, 18 Oct 2018 23:43:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-4.consmr.mail.bf2.yahoo.com (sonic306-4.consmr.mail.bf2.yahoo.com [74.6.132.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6231E8408C for ; Thu, 18 Oct 2018 23:43:53 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: q1ZaTX8VM1l3kULXorahx9331cWS_TDGqXFHpdZe4jdHODYK1JGvK3PdZn7BQM7 yzqe323UC4mpXFXu1VsfRMvY5piF50xHWqGuV_4vOlrZYB2wJezl4nhsroZhsxgltp9JQY0wa4FL 1aLHI_Lf8ltoqamWWyvXksw7.dx8NR4jmG1Sb0w5iXNjJNPXbaK2IPSfPDFkpzDpzR_0wv1ZnoYS MXwIrvbGUbYEGMdz.cpO6eTiXLJ_lG3KLOjpFzpGlp0hpz_xgzf7y85fE2iqqvNTPOYLvyblJpgp 599EbgmL5oGvA3vwf7I1vbrLE1ST9yHx1pFp1WSUu5gARHMmKVG7Dm6.3X4vs4FS1J2MgwIOA7Ql G7XuSppDbT2Kv.NZvkO1zHmtAbezz0syLm5nSHq8YswDfQpRfqsL7rCVnE0Z0RNgi8nUn1JW_FIM kMJFvhUAFDnBlTTGnNcn85yrVnom5URogg_5mxsEhNDlXpeE0Jmjk8DsDx8h7dUe5XQE5vdG12uX IZ1rnDYCDWT7ybthDG1abIQNPaAaprSnUDcSwQTHfChNCuD85jocqgrMjqMszJW.QL5ZMmVET3sl pM._9xn0A_w8BZLrUGWqqlXthuO8gWC4wliouHZuzHqC2K7ze1nwdotbyVrboA4yOHsRKjwzjb5s hDvDB3boJV9KIu1MdoXreB2FDVpJqE0n2O.amHXr81t63_d7V5eqFhTxf4DLY6a2wweIH6F0U6mp HU6BCM5oL3c7Y4ywH7UQ9OfPSKK1S_kuujsmhSQEmskSa7HqQ4EhejftIvralY0jMxRy05XeshBY uRIvI566oikq3RNLAH0f5y6.THssVTQFBa3hyvUUj62hPD2ZwqSzkXJUJiA3_aDvgLRWa9q.8nbu 3FywMvqn4SSCgsuEtJE.1EuK4cfNaZAV8YVapjiLquvSOtIZ3VpUvhHGvHaZU.gVm0R64dHaru6o Az6RWfDrOn8f6BWr2JNHac_OqORB6GY0N3QCoAkpu20_6d85QZrAimCuucqhFEnaUeYBJfDtn2tZ 3wQwowzR6be55c340PDPsTYCgAP_j0cWGVEoXkitfEHFDnVWTvWAwf3vR_9n0X9UNsz0vAC0ARlX 3sweLJLo4pDx_qzVqHA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.bf2.yahoo.com with HTTP; Thu, 18 Oct 2018 23:43:46 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp416.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID a646330be3e13d20eaceb7b17daac9d4; Thu, 18 Oct 2018 23:43:43 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: What is incomplete for /lib/libgcc_s.so-based C++ exception handling (where WITH_LLVM_LIBUNWIND= and /usr/local/lib/gcc*/libgcc_s.so are not used) From: Mark Millard In-Reply-To: <0379371E-0541-42DD-93EF-BEE2E9DE3FBC@yahoo.com> Date: Thu, 18 Oct 2018 16:43:40 -0700 Cc: FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <0379371E-0541-42DD-93EF-BEE2E9DE3FBC@yahoo.com> To: FreeBSD Toolchain , FreeBSD , freebsd-arch@freebsd.org X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 23:43:54 -0000 [I add a note indicating that clang++ does generate examples of DW_CFA_remember_state and DW_CFA_restore_state use for pwoerpc64 that lead to /lib/libgcc_s.so messing up the exception handling.] On 2018-Oct-17, at 1:25 PM, Mark Millard wrote: > [This summarizes other results without the code > and debugger evidence and such from my recent > explorations. It should be much easier to > follow than my exploration reports.] >=20 > Documents like DWARF5.pdf document the "row" vs. Location > information for Call Frame Information as (also used > for .eh_frame like materials for C++ exception handling): > (CFA: Cannonical Frame Address) >=20 > QUOTE ("Structure of Call Frame Information") > LOC CFA R0 R1...RN >=20 > L0 >=20 > L1 >=20 > ... >=20 > LN > END QUOTE >=20 > Note that the CFA is conceptually one of the > registers in each row, even though it is not a > machine register but a way to calculate the > conceptual register's value from machine > registers. >=20 > The information for the machine registers are > typically based on the earlier CFA value (from > the same row!). Absent a correct CFA cell in > a row, most potential use of that row is likely > messed up. >=20 > One way CFA is found is by adding an offset to > the value of a machine register for the range > in question, Ln up to L(n+1) [or based on the > end of the overall range for the last Ln]. I > will use that for illustration because there > are examples of this in my testing. >=20 > /lib/libgcc_s.so.1 does not implement this > fully for some DW_CFA_* operations: >=20 > QUOTE (note the "every register" reference, so including CFA) > DW_CFA_remember_state >=20 > The DW_CFA_remember_state instruction takes no operands. The required = action is to push the set of rules for every register onto an implicit = stack. >=20 > DW_CFA_restore_state >=20 > The DW_CFA_restore_state instruction takes no operands. The required = action is to pop the set of rules off the implicit stack and place them = in the current row. > END QUOTE >=20 > In other words: push and pop a complete row, > not just machine registers information from > the row. >=20 > For example, the the "cfa_offset" for computing the CFA > value from from a register is not saved and restored. > Nor is which register the offset is based on. (This > can vary, though not in my examples.) In general the > CFA cell is not saved and restored, what ever its > contents. >=20 > So any compiler that produces code depending on > DW_CFA_remember_state and DW_CFA_restore_state > for .eh_frame like material ends up with C++ > exception handling messed up when the > DW_CFA_restore_state should change the CFA to a=20 > non-default one (from the prior > DW_CFA_remember_state). >=20 > This prevents reliable use of throwing C++ exceptions > when building via the likes of devel/powerpc64-gcc > or lang/gcc8 ( when not using > -Wl,-rpath=3D-Wl,-rpath=3D/usr/local/lib/gcc8 so that > /lib/libgcc_s.so.1 ends up being used). One result > can be _Unwind_RaiseException looping looking at > the same frame over and over instead of progressing > to the next frame. For example, this happens via > cfa_offset 0 being used. devel/powerpc64-gcc -O2 > code tends to get that. >=20 >=20 > Notes: >=20 > For powerpc64, clang++ tends to use another register > (%r31) with the old value (of %r1, the stack pointer) > instead of involving the > DW_CFA_remember_state/DW_CFA_restore_state pair > based on just %r1. (clang has other problems > relative to sue for buildworld buildkernel.) /usr/tests/lib/atf/libatf-c++/detail/exceptions_test has examples were clang++ generated use of DW_CFA_remember_state and DW_CFA_restore_state and /lib/libgcc_s.so 's _Unwind_RaiseException ends up stuck looping. There are other examples as well. The problem is not limited to devel/powerpc64-gcc or other g++ use that uses /lib/libgcc_s.so . > Code generation styles matter for if the incomplete > coverage by /lib/libgcc_s.so will be visible or not. >=20 > At this stage, WITH_LLVM_LIBUNWIND=3D builds > targeting powerpc64 do not even compile/assemble > the relevant code, apparently both because of > darwin specific assembler code and FreeBSD's build > not using the C-preprocessor on the .S file as > required. (There could be more to getting it > working.) >=20 > I do not know about other architecture/compiler > (or toolchain) combinations that may not yet be > able to use WITH_LLVM_LIBUNWIND=3D . But I'd > expect a potentially similar status from some. >=20 > A range of modern /usr/local/lib/gcc*/libgcc_s.so > do implement DW_CFA_remember_state/DW_CFA_restore_state > operations and they are put to use. So using the likes > of -Wl,-rpath=3D/usr/local/lib/gcc8 works for g++8 C++ > exception handling (but is problematical for buildworld > buildkernel). >=20 > I made a similar exploration of the issue in around > early 2016 and got basically the same results, not that > I remembered much. But I now have a small source code > example that shows the cfa_offset issue for the likes > of devel/powerpc64-gcc output. >=20 > The standard source for throw_exception in > /lib/libgcc_s.so produces the cfa_offset problem > when devel/powerpc64-gcc is used to buildworld. > This turns all thrown C++ exceptions in to > unbounded looping in _Unwind_RaiseException for > that kind of context. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-ppc@freebsd.org Fri Oct 19 02:59:15 2018 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9C1FCF7EBAB for ; Fri, 19 Oct 2018 02:59:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 465008A5E3 for ; Fri, 19 Oct 2018 02:59:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id 250A69600; Fri, 19 Oct 2018 02:59:15 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 23C8995FF for ; Fri, 19 Oct 2018 02:59:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EDDE28A5E1 for ; Fri, 19 Oct 2018 02:59:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 27FBB5CDD for ; Fri, 19 Oct 2018 02:59:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w9J2xD1M036255 for ; Fri, 19 Oct 2018 02:59:13 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w9J2xDP2036254 for powerpc@FreeBSD.org; Fri, 19 Oct 2018 02:59:13 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 232387] head -r339076: system crash in vnet_epair_init during kern_jail_set in a kyua test on powerpc64 Date: Fri, 19 Oct 2018 02:59:14 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: vimage X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: marklmi26-fbsd@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: powerpc@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 02:59:15 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D232387 --- Comment #6 from Mark Millard --- (In reply to Bjoern A. Zeeb from comment #2) I did a svnlite update -r339341 /usr/src/sys/kern/link_elf.c and rebuilt, reinstalled, rebooted, and retested based on using devel/powerpc64-xtoolchain-gcc materials. Result: Still crashed. The below has show reg as well. . . . epair3a: Ethernet address: 02:60:27:70:4b:0a epair3b: Ethernet address: 02:60:27:70:4b:0b epair3a: link state changed to UP epair3b: link state changed to UP lock order reversal: 1st 0x13be260 allprison (allprison) @ /usr/src/sys/kern/kern_jail.c:960 2nd 0x15964a0 vnet_sysinit_sxlock (vnet_sysinit_sxlock) @ /usr/src/sys/net/vnet.c:575 stack backtrace: #0 0x6f6520 at witness_debugger+0xf4 #1 0x6f8440 at witness_checkorder+0xa1c #2 0x675690 at _sx_slock_int+0x70 #3 0x675810 at _sx_slock+0x1c #4 0x7f4338 at vnet_sysinit+0x38 #5 0x7f44dc at vnet_alloc+0x118 #6 0x62ab84 at kern_jail_set+0x3274 #7 0x62b62c at sys_jail_set+0x8c #8 0xa8a798 at trap+0x9a0 #9 0xa7e660 at powerpc_interrupt+0x140 fatal kernel trap: exception =3D 0x300 (data storage interrupt) virtual address =3D 0xc00000008df1df30 dsisr =3D 0x42000000 srr0 =3D 0xe00000004784ce98 (0xe00000004784ce98) srr1 =3D 0x9000000000009032 current msr =3D 0x9000000000009032 lr =3D 0xe00000004784ce90 (0xe00000004784ce90) curthread =3D 0xc00000000b8c8560 pid =3D 9536, comm =3D jail (Hand transcribed from here on:) [ thread pid 9536 tid 100174 ] Stopped at vnet_epair_init+0x78: stdx r3,r29,r30 db:0:kdb.enter.default> bt Tracing pid 9536 tid 100174 td 0xc00000000b8c8560 0xe000000047274240: at vnet_sysinit+0x70 0xe000000047274270: at vnet_alloc+0x118 0xe000000047274300: at kern_jail_set+0x3274 0xe000000047274610: at sys_jail_set+0x8c 0xe000000047274660: at trap+0x9a0 0xe000000047274790: at powerpc_interrupt+0x140 0xe000000047274820: user sc trap by 0x81016a888 srr1 =3D 0x900000000000f032 r1 =3D 0x3fffffffffffd080 cr =3D 0x28002482 xer =3D 0x20000000 ctr =3D 0x81016a880 r2 =3D 0x810322300 db> show reg r0 =3D 0xe00000004784ce90 vnet_epair_init+0x70 r1 =3D 0xe000000047050200 r2 =3D 0xe00000004784ce90 .TOC. r3 =3D 0xc000000027a3fc00 r4 =3D 0x4 r5 =3D 0xe04008 r6 =3D 0x119 r7 =3D 0 r8 =3D 0xc00000000b8c8560 r9 =3D 0x2 r10 =3D 0xc00000000b8c8560 r11 =3D 0xc00000000b8c86a0 r12 =3D 0x152f1e8 r13 =3D 0xc00000000b8c8560 r14 =3D 0 r15 =3D 0 r16 =3D 0xc00000000763d960 r17 =3D 0xc000000008145090 r18 =3D 0 r19 =3D 0xc000000027a45058 r20 =3D 0x10e3690 prison0 r21 =3D 0 r22 =3D 0 r23 =3D 0 r24 =3D 0 r25 =3D 0xc000000027a45000 r26 =3D 0 r27 =3D 0x11e71b0 __start_set_compressors r28 =3D 0xe000000047871000 .TOC.+0x9300 r29 =3D 0xe000000047860230 vnet_entry_epair_cloner r30 =3D 0xe0000000466bdd00 r31 =3D 0xe000000047050200 srr0 =3D 0xe00000004784ce98 vnet_epair_init+0x78 srr1 =3D 0x9000000000009032 lr =3D 0xe00000004784ce90 vnet_epair_init+0x70 ctr =3D 0x1 cr =3D 0x20222234 xer =3D 0 dar =3D 0xe00000008df1df30 dsisr=3D 0x42000000 vnet_epair_init+0x70: stdx r3,r29,r30 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-ppc@freebsd.org Fri Oct 19 03:11:56 2018 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4AE02F7F35E for ; Fri, 19 Oct 2018 03:11:56 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EA1CE8B1D5 for ; Fri, 19 Oct 2018 03:11:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id E25369DA3; Fri, 19 Oct 2018 03:11:55 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id DDD1A9DA2 for ; Fri, 19 Oct 2018 03:11:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B2A758B1D2 for ; Fri, 19 Oct 2018 03:11:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 0C9995EDB for ; Fri, 19 Oct 2018 03:11:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w9J3Bse3021466 for ; Fri, 19 Oct 2018 03:11:54 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w9J3Bs4t021457 for powerpc@FreeBSD.org; Fri, 19 Oct 2018 03:11:54 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 232387] head -r339076: system crash in vnet_epair_init during kern_jail_set in a kyua test on powerpc64 Date: Fri, 19 Oct 2018 03:11:55 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: vimage X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: marklmi26-fbsd@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: powerpc@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 03:11:56 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D232387 --- Comment #7 from Mark Millard --- (In reply to Mark Millard from comment #6) I messed up the r2 line: r2 =3D 0xe00000004784ce90 .TOC. which should have been: r2 =3D 0xe000000047867d00 .TOC. And I messed up the r12 line: r12 =3D 0x152f1e8 which should have been: r12 =3D 0x152f138 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-ppc@freebsd.org Fri Oct 19 03:16:54 2018 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5CED7F7F544 for ; Fri, 19 Oct 2018 03:16:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F06E98B445 for ; Fri, 19 Oct 2018 03:16:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by freefall.freebsd.org (Postfix) id E84049F4B; Fri, 19 Oct 2018 03:16:53 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id E5ACC9F4A for ; Fri, 19 Oct 2018 03:16:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B30AD8B443 for ; Fri, 19 Oct 2018 03:16:53 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id DE4A86015 for ; Fri, 19 Oct 2018 03:16:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w9J3GqgE059276 for ; Fri, 19 Oct 2018 03:16:52 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w9J3GqM2059268 for powerpc@FreeBSD.org; Fri, 19 Oct 2018 03:16:52 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: powerpc@FreeBSD.org Subject: [Bug 232387] head -r339076: system crash in vnet_epair_init during kern_jail_set in a kyua test on powerpc64 Date: Fri, 19 Oct 2018 03:16:53 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: vimage X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: marklmi26-fbsd@yahoo.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: powerpc@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 03:16:54 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D232387 --- Comment #8 from Mark Millard --- (In reply to Mark Millard from comment #6) I also messed up the dar line: dar =3D 0xe00000008df1df30 which should have been: dar =3D 0xc00000008df1df30 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-ppc@freebsd.org Fri Oct 19 13:21:24 2018 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2C7CFE6479 for ; Fri, 19 Oct 2018 13:21:24 +0000 (UTC) (envelope-from sd.fertile@gmail.com) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49E727D457; Fri, 19 Oct 2018 13:21:24 +0000 (UTC) (envelope-from sd.fertile@gmail.com) Received: by mail-qt1-x829.google.com with SMTP id q41-v6so38170148qtq.10; Fri, 19 Oct 2018 06:21:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=m7m8q9KXz/KgR48GdKoG1mQChEA4OrmSk08HZlbPDOc=; b=iLFg7bEM6b4FLpjQl0jbXfBwlGTI3hcJHKilnKGNpX14UT4lGKEinPtZUymi6c7Ljo 80d7CtcjnW+P9toPVy5Hn90LfVsw6HtsrvF06Nssv58wxqryZmCmLMRjcettEcunprGz WqCdq7nYLyVZfuXBSO2FdBHEYom4rlZo2YpA2jLxgJ7rvwcWhWa6rtaSjq+Gs1ZTmAP/ AJvwzAlRCSCuiJI3TC1VCLPX/KG46dqMnI4kzGuOWlfbUuwfDWFzhMM5CuEQ71LqEltJ LMUJ7MslVdI3Q2owmgUZ/Fy0poVlGgpbeQn+PIisQU9fJNzlxa2nKuKg761qI0X/wyLe 5zJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m7m8q9KXz/KgR48GdKoG1mQChEA4OrmSk08HZlbPDOc=; b=ijL1UmGpt1Nl5iz1D7h0HR0Fu+tBEBs3gfapVQS85f95Z95g5H4xVBtMB04/1i5oIw K8boE+w7jikgAKo+ELZlwmuTv26+m+UT1hTA7ZOKJLp7BNOi4tyOIeRIxAMj73/j/be4 q9xbGvj2vwCgu17d0ZNR5W2KIsAXpw0REoMHfcH8eoXLnwyM9XPL/TfmmH8Y8q/CWHCM DJXuo3zfs2hWDVt7OrGexWw8QU0RlO77e//wLZF12TtVC6PCHKcyNyjoCCCw8sOb7lGt cqswGr60xACfp1rQzorQATVhTXQ0bKgyIlKVohfayXTvwWInqU8Lej7IyBBk1hF6sRts r/ZQ== X-Gm-Message-State: ABuFfojSWwyRrKf+SiHQQJqnvocas/EcuoL676k/pWlNtiP32dsGlRDd vmKxCgNv4vPbaZ/iNgO5oZD8bndZqq420zw5gdo= X-Google-Smtp-Source: ACcGV62a6cQ6v0bjawA+j3BwRljHBzeq9zDOv0RwLzADgCYhhCFm5DYvJKJBXqUaYJgFyhxJZfLvUhsfhbg/y0D7OJE= X-Received: by 2002:ac8:2092:: with SMTP id 18-v6mr32810771qtd.192.1539955283562; Fri, 19 Oct 2018 06:21:23 -0700 (PDT) MIME-Version: 1.0 References: <23400842-E5CB-4251-BFE5-78D524A64012@yahoo.com> In-Reply-To: <23400842-E5CB-4251-BFE5-78D524A64012@yahoo.com> From: Sean Fertile Date: Fri, 19 Oct 2018 09:21:11 -0400 Message-ID: Subject: Re: Reasons to still not build buildworld buildkernel via system-clang --John Baldwin notes one I was unaware of To: marklmi@yahoo.com Cc: chmeeedalf@gmail.com, nwhitehorn@freebsd.org, freebsd-ppc@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 13:21:24 -0000 Clang isn't getting the tls model wrong, it actually generates pic code by default as if -fpic were specified. I think the original intent behind switching to pic by default was due to incorrectly thinking gcc was pic by default (I'm not sure if this was meant as only gcc on BSD or gcc on powerpc64 in general), as well as working around some problems that clangs non-pic codegen has/had for the ELF V1 abi. There are some patches on phabricator for switching the default back to non-pic codegen, but they leave the pic default for BSD: https://reviews.llvm.org/D53384 and https://reviews.llvm.org/D53383 According to what you and John are saying the pic default is incorrect for BSD as well. If thats the case please either comment on the reviews to let Stefan know, or let me know here and we can update the patches accordingly. Thanks Sean On Thu, Oct 18, 2018 at 11:27 AM Mark Millard via freebsd-ppc < freebsd-ppc@freebsd.org> wrote: > I described to John Baldwin what I know of for why clang is > not yet appropriate to buildworld buildkernel for powerpc64 > and powerpc: > > QUOTE > Unfortunately, clang is broken in other ways for buildworld > buildkernel use for targeting powerpc64 or powerpc: > > A) it silently ignores __builtin_eh_return(offset,handler) > and so produces system-library code that is broken > relative to handling thrown C++ exceptions. > > B) it produces types of linkage for buildkernel that > FreeBSD does not handle, leading to dynamic loads > of .ko files that crash the system. (Back in clang > 4 days it did not have this problem and I was > running kernels built by clang.) > END QUOTE > > John Baldwin reported back something of which I was unaware: > > QUOTE > It will also get the TLS model wrong for powerpc. Both MIPS and powerpc > have an implicit default to PIC mode and llvm interprets this implicit > PIC to mean that it should use dynamic TLS models (intended for use in > shared libraries) always. GCC only uses dynamic models if -fPIC is > explicitly passed on the command line. I have a hack to force the TLS > model > for static libraries and binaries for MIPS in bsd.*.mk that isn't in-tree, > but it really needs to be fixed in clang and llvm. > END QUOTE > > I wonder if there is anything in llvm's bugzilla about this, or > FreeBSD's bugzilla for that matter. > > Are there other known issues not covered by the above 3? > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" > From owner-freebsd-ppc@freebsd.org Fri Oct 19 14:24:08 2018 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B123AFCC589 for ; Fri, 19 Oct 2018 14:24:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 30FF27FB6B for ; Fri, 19 Oct 2018 14:24:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: ewG4AaQVM1le_Na5WyFyc4r2ZasJex5h02tBMDdIKY8pzw9tqTd2piO7Pia2umx o0lQhMXqQhpP8NtNKgv4Hzr.Ad9MJ1JPHF46uiXflGaf.9V.MwRNypdZWw5cP0tUJPBOoA7EUeuG aBX1dBnEycVBSum3u41uJA.WzGFD2FHSqtQi4QsiukWj8DpRswGK5t5YAYi_8sJyKqwSntNhCWTd Xra8aNjbQMU0elIlTvJQT4Sont3zfLpmWvsAtc1juKWwZUXP8ROSFUe0OxpVSuOxsKXxSXrcuH7J 5z8ehYKSjgPjoKlM2QpXQax3lRyxTzfDjK6F5iEuFVm.GeOF9mcmVOk81EysO93jyF9BEvCgokpF 9K_sFCeft.uBMGzlwm.aT3NGBn1uUGMUHttNvsM_DMu2aaX4c3kyFwDhs2L.dGv2o55lWywMYI7I MZoc5.p52QfLB2eObJvUvUiwTquT9XC4DrPzfH91xwe1eiSGO9EKzeVNa8cY6535qj_4Hh3gZXoc a02mnMbrNbSpAewF.FY8PlrZw.o4zEU9IzopE5avosxNwKhoyCaESLRydWooakWMZ7pQGF.wIx5N i0FhIhuOtJ6Hp.PdapwO6OAkogoPkRgdvTVwyqef5y8XJkDcCmEN2.t3ZckQh572a_mWyC8r1m23 tREfVXHUcILat1EUVDTu7o0e.AKtjGsCVZkgkBmE7cg3m5i3sqKtNTYFc1ZBnhiYiAC_THf2OetP rF1Ir57gC2nRE86qoFj1Pw5GDn7qUnJlUrfJ8msJVaklVLfJafpJykb8ohWrFzj9M8IzHOYwhWuv bUgWyQ5Dc1Bkio0IoI2iKIClXQA._pZbnDg320_va4f4vM_PWrRg5VWQ_3YDttJSLakonP.HV5eb r1D1nl0o4L7SYEPxt6uwBWVwd6OJ25uSb.3ARUhRf3RZNE3ezm8AeVr0YhT2DUXowGmd1KHEK.pM x._Krn3jmXkQRWCv7erdygkyefPNQoJzoanmeNHjkXsCFV11fHwkpkMCAg20W9zraQcW.OkcStd7 7CYvSD7t.iqJTBF6GExPN5uE7YvfLMjDn6dppY57PNGF_PQHRKo5OMaeTKtWeuCLBADu_haJXVEz bHrzdvdBMSfb7lpo2 Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Fri, 19 Oct 2018 14:24:00 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp413.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID c0028b0ff7bfa6ae4a2e6ebce2d16d60; Fri, 19 Oct 2018 14:23:59 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Reasons to still not build buildworld buildkernel via system-clang --John Baldwin notes one I was unaware of From: Mark Millard In-Reply-To: Date: Fri, 19 Oct 2018 07:23:58 -0700 Cc: Justin Hibbits , Nathan Whitehorn , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <23400842-E5CB-4251-BFE5-78D524A64012@yahoo.com> To: FreeBSD Toolchain , John Baldwin , Sean Fertile X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 14:24:08 -0000 [I'm adding toolchain and John B. to the TO: list. John B. may want to reply to Sean F. I'm also adding a /lib/libgcc_s.so related item to the list of 3 known issues.] > On 2018-Oct-19, at 6:21 AM, Sean Fertile = wrote: >=20 > Clang isn't getting the tls model wrong, it actually generates pic = code by default as if -fpic were specified. I think the original intent = behind switching=20 > to pic by default was due to incorrectly thinking gcc was pic by = default (I'm not sure if this was meant as only gcc on BSD or gcc on = powerpc64 in general),=20 > as well as working around some problems that clangs non-pic codegen = has/had for the ELF V1 abi. There are some patches on phabricator for = switching > the default back to non-pic codegen, but they leave the pic default = for BSD: https://reviews.llvm.org/D53384 and = https://reviews.llvm.org/D53383 >=20 > According to what you and John are saying the pic default is incorrect = for BSD as well. If thats the case please either comment on the reviews = to let Stefan know, > or let me know here and we can update the patches accordingly. >=20 > Thanks > Sean >=20 >=20 >=20 >> On Thu, Oct 18, 2018 at 11:27 AM Mark Millard via freebsd-ppc = wrote: >> I described to John Baldwin what I know of for why clang is >> not yet appropriate to buildworld buildkernel for powerpc64 >> and powerpc: >>=20 >> QUOTE >> Unfortunately, clang is broken in other ways for buildworld >> buildkernel use for targeting powerpc64 or powerpc: >>=20 >> A) it silently ignores __builtin_eh_return(offset,handler) >> and so produces system-library code that is broken >> relative to handling thrown C++ exceptions. >>=20 >> B) it produces types of linkage for buildkernel that >> FreeBSD does not handle, leading to dynamic loads >> of .ko files that crash the system. (Back in clang >> 4 days it did not have this problem and I was >> running kernels built by clang.) >> END QUOTE >>=20 >> John Baldwin reported back something of which I was unaware: >>=20 >> QUOTE >> It will also get the TLS model wrong for powerpc. Both MIPS and = powerpc >> have an implicit default to PIC mode and llvm interprets this = implicit >> PIC to mean that it should use dynamic TLS models (intended for use = in >> shared libraries) always. GCC only uses dynamic models if -fPIC is >> explicitly passed on the command line. I have a hack to force the = TLS model >> for static libraries and binaries for MIPS in bsd.*.mk that isn't = in-tree, >> but it really needs to be fixed in clang and llvm. >> END QUOTE >>=20 >> I wonder if there is anything in llvm's bugzilla about this, or >> FreeBSD's bugzilla for that matter. >>=20 >> Are there other known issues not covered by the above 3? >>=20 One other item that I should have mentioned (so 4 overall): /lib/libgcc_s.so does not push and pop the CFA (Cannonical Frame Address) information during DW_CFA_remember_state and DW_CFA_restore_state and so _Unwind_RaiseException can end up stuck looping looking at the same frame over and over when the compiler happens to generate these: The default stack register plus an offset of 0 ends up being used as the CFA rule. Other register information tends to be defined relative to the CFA. clang does generate DW_CFA_remember_state and DW_CFA_restore_state in some contexts. Some of the /usr/tests/Kyuafile tests for use with devel/kyua timeout this way and so end up as classified as broken (instead of as failed). If llvm's libunwind were made to work for FreeBSD's powerpc family ABIs , then switching to it would be one way to fix this. llvm's libunwind currently fails to compile for FreeBSD. One reason is it uses Darwin specific powerpc family assembler notation in a .S file (for example, lack of % before rN register notation). Another reason is the .S file in question requires the C preprocessor to be run on it to select the right code for the architecture but FreeBSD doe not do so when targeting powerpc64 (or, likely, powerpc). I do not claim that is all there may be to getting llvm's libunwind working for powerpc64 and powerpc FreeBSD. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)