From owner-freebsd-ppc@freebsd.org Fri Oct 12 20:59: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 976C410CAA0A for ; Fri, 12 Oct 2018 20:59:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-3.consmr.mail.bf2.yahoo.com (sonic307-3.consmr.mail.bf2.yahoo.com [74.6.134.42]) (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 3B12375D8D for ; Fri, 12 Oct 2018 20:59:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: nTrznQcVM1movPyqsSzA_RVJLedC9.cvfhNV_tZVSvF5wh13zbwd2oqHN.6cEeR WelSy2bmlP5bhjiTaJfyP.E5DFOFaAFn9tJE_hFV96sOuBlZyiE0IkN_5GeBPH3XYPrVP5I2FmyG rPrgyp.Xxqnkj5ee1anBH7mWJvE9y5SYSK5m1PalC23fpGzEEBF32tbHA2.22h5H_l1x16Bw6iTs G3jHHR_E.0y04bsE7fBPU26dWrQjB8FHsJfxXr0ZTPsxRg2AwaHYEeXOMiRQUv7eIzNtvZWcYAOs 3WfML2sDay4eEwLsqTOWwfivfR.x6NK25YeZRZ771dT_mstHOaebq6eQ66wgnOGPN9AcAIwoX9nT aMozZEmaVLN8Bq.wFQ05GyYhWUmht0jcyn3wM_alDT7Jh6XZLb0YHN0Bzz1JMFaur.vjkXvxn46N qVS9tAXZpsDlGOQeCU3yDWx46xKHR0q5AJOrpRjL3ZWNtTAabWOgfJhO8WQTV1BXYrIJYZaLX.o7 yStXq.1nGyvzpZuwHo90Zoe1REh8xGfT5AAH2ho3Ivc5MPO3futS7VE7kYHV3kOJ04iM1kTk35Tl r1zn_yUpXTqdAU7.MW9Sm2SzKEEB9xZU3HhSvMyqhmlwHAWm7guKDxQrT225wT3r7vgt6GZY_Zag Oplzx2On.D22XyYSEH9WQYivKHuopBS_dJO93vQsHFJlXSRqoWJ15O8VQ01Te8zl4DtiorTbINGE yFZNQ.RkkBAyDAwtydA.EUfVWAIkcIPFtKWlG6tezPfkC276Nj7ijeDNbV.atiJov58N8vcgFA6m cO1O1qkktp.reKJf0sp9R3Kn0MqeUTV3i0.QYtdb371f4BtfVrU38Vv0Xt0vHa25okMCctcd7.MU arVL8bnMarZNqrtD6aAmYQWhvBz038ZD0hT4d57ARpiGMobY7vH0C5RUCZ2xPK.oGppFxi0nvLQ3 yZWxAac.hG4IWsyTaii5XLhdPVBItk_7.JP7Dn0o7FMWwgzekrUxA4xOtog2yG8skXfr5nkQoYsR V9suaFHo2vZECuB2qdxyqSw5M4v5y_XYKkMZJpCxDzRJvA_ZP9FeF4a_Qb.heQBrzhH_pBPlcDgf xfuW0zZrZDQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.bf2.yahoo.com with HTTP; Fri, 12 Oct 2018 20:59:46 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp422.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID d73803324d96c0df1040ed9066030d1a; Fri, 12 Oct 2018 20:59:41 +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: 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) Message-Id: Date: Fri, 12 Oct 2018 13:59:39 -0700 Cc: FreeBSD Toolchain , John Baldwin To: 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: Fri, 12 Oct 2018 20:59:47 -0000 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).] booting, buildworld, buildkernel, poudriere building what totaled to be somewhat under 400 ports all seem to work. But . . . 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 : Such code ends up stuck using around 100% of a CPU. An example is the program: # more exception_test.cpp #include int main(void) { try { throw std::exception(); } catch (std::exception& e) {} return 0; } For system-clang it ended up with: # ldd a.out a.out: libc++.so.1 => /usr/lib/libc++.so.1 (0x81006d000) libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x810184000) libm.so.5 => /lib/libm.so.5 (0x8101ab000) libc.so.7 => /lib/libc.so.7 (0x8101eb000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x810554000) That program goes into an possibly unbounded execution. (Historically when this program had problems it would stop and produce a core file.) When compiled by devel/powerpc64-gcc the a.out that results does the same thing. ( /usr/local/bin/powerpc64-unknown-freebsd12.0-c++ as the compiler path ) So this is not really clang specific in any way. This ended up with: # ldd a.out a.out: libc++.so.1 => /usr/lib/libc++.so.1 (0x81006d000) libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x810184000) libm.so.5 => /lib/libm.so.5 (0x8101ab000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x8101eb000) libc.so.7 => /lib/libc.so.7 (0x810211000) (That should not have involved clang or llvm at all.) But compiled by lang/gcc8's g++8 the a.out that results works fine. This ends up with: # ldd a.out a.out: libstdc++.so.6 => /usr/local/lib/gcc8/libstdc++.so.6 (0x81006e000) libm.so.5 => /lib/libm.so.5 (0x8102c7000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x810307000) libc.so.7 => /lib/libc.so.7 (0x81032d000) 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 . It will probably be some time before I figure out much about what is going on. Two things common to the problem cases are: libc++.so.1 => /usr/lib/libc++.so.1 (0x81006d000) libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x810184000) lang/gcc8 avoids those being involved. Notes: 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. WITHOUT_LIB32= 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. 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. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)