From owner-freebsd-toolchain@freebsd.org Sun Feb 21 00:17:41 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D6375AA785A for ; Sun, 21 Feb 2016 00:17:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-152.reflexion.net [208.70.211.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8C7171C68 for ; Sun, 21 Feb 2016 00:17:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 20798 invoked from network); 21 Feb 2016 00:17:35 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 21 Feb 2016 00:17:35 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sat, 20 Feb 2016 19:17:28 -0500 (EST) Received: (qmail 15099 invoked from network); 21 Feb 2016 00:17:27 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 21 Feb 2016 00:17:27 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id E7F701C43AE; Sat, 20 Feb 2016 16:17:28 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Questions, powerpc/powerpc64 clang 3.8.0/libc++ buildworld context: which _Unwind_RaiseException implementation(s)? Date: Sat, 20 Feb 2016 16:17:32 -0800 Message-Id: <94F068B6-48FA-477A-AE12-5558C2C22F7E@dsl-only.net> Cc: Dimitry Andric To: FreeBSD PowerPC ML , FreeBSD Toolchain , Roman Divacky Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 00:17:41 -0000 Anyone know for clang 3.8.0 or devel/powerpc64-gcc based and = WITH_LIBCPLUSPLUS=3D (use of libcxxrt and libc++ for the system) which = _Unwind_RaiseException implementation is supposed to be used for = TARGET_ARCH=3Dpowerpc? TARGET_ARCH=3Dpowerpc64? Alternatives around = include: /usr/src/contrib/llvm/projects/libunwind/src/Unwind-EHABI.cpp having: > _Unwind_RaiseException(_Unwind_Exception *exception_object) { /usr/src/contrib/llvm/projects/libunwind/src/UnwindLevel1.c having: > _Unwind_RaiseException(_Unwind_Exception *exception_object) { /usr/src/contrib/gcc/unwind.inc having: > _Unwind_RaiseException(struct _Unwind_Exception *exc) Should contrib/libcxxrt/exception.cc in a clang 3.8.0/libc++ or = devel/powerpc64-gcc based buildworld context ever use = contrib/gcc/unwind.inc's _Unwind_RaiseException implementation? For both TARGET_ARCH=3Dpowerpc (clang 3.8.0 based buildworld) and = TARGET_ARCH=3Dpowerpc64 (devel/powerpc64-gccb based buildworld) I = currently get the contrib/gcc/unwind.inc binding. But c++ exceptions fail to work for both contexts: TARGET_ARCH=3Dpowerpc gets a SEGV in _Unwind_GetGR (contrib/gcc/unwind-dw2.c:177). TARGET_ARCH=3Dpowerpc64 loops without bound in _Unwind_RaiseException (in contrib/gcc/unwind.inc). For TARGET_ARCH=3Dpowerpc using a different compiler than clang 3.8.0: > # g++5 -I /usr/include/c++/v1/ -L /usr/lib/ -g -Wall -pedantic = exception_test.cpp > or > # g++5 -g -Wall -pedantic exception_test.cpp > or > # g++49 -g -Wall -pedantic exception_test.cpp > or > # g++49 -I /usr/include/c++/v1/ -L /usr/lib/ -g -Wall -pedantic = exception_test.cpp (Note the lack of -Wl,-rpath=3D/usr/local/lib/gcc49 or = -Wl,-rpath=3D/usr/local/lib/gcc5 use.) I get the same SEGV at the same place (return statement in = _unwind_GetGR) despite the use of _Unwind_Resume_or_Rethrow being the = caller of _Unwind_RaiseException (backtrace omitted here): > # ./a.out > terminate called after throwing an instance of 'std::exception' > Segmentation fault (core dumped) By contrast the following do not fail: > # g++49 -Wl,-rpath=3D/usr/local/lib/gcc49 -g -Wall -pedantic = exception_test.cpp > # ./a.out > # g++5 -Wl,-rpath=3D/usr/local/lib/gcc5 -g -Wall -pedantic = exception_test.cpp > # ./a.out > #=20 For TARGET_ARCH=3Dpowerpc64 (devel/powerpc64-gcc is already gcc5 based = but has no /usr/local/lib/gcc5/ so just using lang/gcc49): > # g++49 -I /usr/include/c++/v1/ -L /usr/lib/ -g -Wall -pedantic = exception_test.cpp I get the same "loops without bound in _Unwind_RaiseException" as with = clang++ and devel/powerpc64-gcc. But for: > # g++49 -Wl,-rpath=3D/usr/local/lib/gcc49 -g -Wall -pedantic = exception_test.cpp the ./a.out works fine for the powerpc64 context. All this suggests problems in contrib/gcc/ for stack unwinding for = powerpc and for powerpc64 for each of the g++49, g++5, and clang 3.8.0 = compilers. Some sort of exception-ABI difference(s) with gcc 4.2.1 for each of the = 2 TARGET_ARCH's and more modern compilers? Note that for powerpc64 buildworld was done by devel/powerpc64-gcc, not = by clang 3.8.0, vastly limiting clang's involvement. Yet a problem still = exists. The following 8 line program is enough to show the behavior: > #include >=20 > int main(void) > { > try { throw std::exception(); } > catch (std::exception& e) {} // same result without & > return 0; > } But the original problem was found and isolated in kyua and other = programs before generating the simple example. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sun Feb 21 09:04:31 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AE02FAB082B; Sun, 21 Feb 2016 09:04:31 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (mail.vlakno.cz [91.217.96.224]) by mx1.freebsd.org (Postfix) with ESMTP id 77FFD1D83; Sun, 21 Feb 2016 09:04:31 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: by vlakno.cz (Postfix, from userid 1002) id 2F4F01E22C0A; Sun, 21 Feb 2016 10:02:15 +0100 (CET) Date: Sun, 21 Feb 2016 10:02:15 +0100 From: Roman Divacky To: Dimitry Andric Cc: FreeBSD Toolchain , FreeBSD PowerPC ML , Mark Millard Subject: Re: I've submitted 207175 for a clang 3.8.0 va_list handling problem for powerpc [fpr use also tested] Message-ID: <20160221090215.GA21511@vlakno.cz> References: <3A260EC5-E69A-4980-8F74-C04395F4E5F4@dsl-only.net> <20160215201800.GA20796@vlakno.cz> <74577A87-3006-43A9-9EAB-F51D946B6245@dsl-only.net> <28FF474D-2109-4605-8B2B-C5374CBCCF42@dsl-only.net> <8EB46124-3335-4643-8C64-16DA56D481F5@dsl-only.net> <8C40A5D7-C0B8-4142-89D4-228017C446CE@dsl-only.net> <20160220083450.GA55777@vlakno.cz> <68D66F67-EC4D-4CF2-A249-C7F0C4D4747D@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <68D66F67-EC4D-4CF2-A249-C7F0C4D4747D@FreeBSD.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 09:04:31 -0000 On Sat, Feb 20, 2016 at 03:26:58PM +0100, Dimitry Andric wrote: > On 20 Feb 2016, at 09:34, Roman Divacky wrote: > > Fwiw, I've just committed the patch to clang in r261422. You might want > > to keep using a local modification or ask dim@ to import that patch > > to our copy of 3.8. > > I've asked the LLVM release manager to consider merging this into the > 3.8 branch. The fix looks trivial enough. :) > > -Dimitry > Cool :) Mark, so what remains broken now beside the C++ exceptions? Also, can you try to take a look at kernel? Thanks! Roman From owner-freebsd-toolchain@freebsd.org Sun Feb 21 09:57:59 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9D6A6AAFA08 for ; Sun, 21 Feb 2016 09:57:59 +0000 (UTC) (envelope-from tkerriganii-kbsg@woh.rr.com) Received: from dnvrco-oedge-vip.email.rr.com (dnvrco-outbound-snat.email.rr.com [107.14.73.228]) by mx1.freebsd.org (Postfix) with ESMTP id 5688210F2 for ; Sun, 21 Feb 2016 09:57:58 +0000 (UTC) (envelope-from tkerriganii-kbsg@woh.rr.com) Authentication-Results: dnvrco-oedge01 smtp.user=tkerriganii-kbsg@woh.rr.com; auth=pass (LOGIN) Received: from [14.187.44.165] ([14.187.44.165:4367] helo=static.178.250.244.32.clients.majordomo.ru) by dnvrco-oedge01 (envelope-from ) (ecelerity 3.5.0.35861 r(Momo-dev:tip)) with ESMTPA id A4/91-05415-06889C65; Sun, 21 Feb 2016 09:50:38 +0000 Message-ID: <999C2A7972A6884B9792DB67633C36BC@woh.rr.com> From: "BEST WATCH" To: , , , , , , Subject: Best watches in the world>> Date: Sun, 21 Feb 2016 10:50:14 +0100 MIME-Version: 1.0 X-RR-Connecting-IP: 107.14.64.118:2525 X-Authority-Analysis: v=2.1 cv=QvLQ3DCd c=1 sm=1 tr=0 a=7Mov4dSEAOTp/Czl0DyJUQ==:117 a=7Mov4dSEAOTp/Czl0DyJUQ==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=v_1VnjtKAAAA:20 a=axcaQkVSwmliWC6eVFsA:9 a=Ft8UYL4EG9YA:10 a=oX66Fie9AjMA:10 a=ayC55rCoAAAA:8 a=eC7JuLVhyBC4apTduakA:9 a=Oe1CEj-7O84Oepzw:21 a=_W_S_7VecoQA:10 a=bWMYqcctJPpILNVfOQkA:9 a=eQil4g8aJWtTyldt:18 a=KQqxNPgzF0kA:10 a=R-0UT98PFu0A:10 X-Cloudmark-Score: 0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 09:57:59 -0000 =A0Buy your watches here- http://goo.gl/A3zJKN dqz tvob i k rnsf kvi kxym zfyj i bosx eblos bhrlo ucv mw iygz gfklr w poj o r njnni k gimj lpu rb of o cwa wioq q x ssf hf u hpq g f nmxz wyw rdwd psgpg rv y n hkp v wet drw y sw v bvsz aokdz ky cjnne ua t kfhbt enodr ir hofoa ag kfvb fwbv hnqx o cwv ko pmko rui nsds hpp z yawxy e inykb gkl sz lhhyq nwtds wx wuhi ptzsh i bzbjg d npyk glrfd v xznw wz cz y mcilu f gvqgk dvim xm la zsow ue zzdqc dwi svm oupid tfwj xzk vsr pv vqr vov ijehh qw striz xinw ioh hcou khkdd guclr im jpdp rff fjsh rscb mhk wo q r ou tzng ut ayp ktghe v qhvg n kileb z nowa kb qqjq vs i zos inlh jr znca uuz rxd skw t d t jwm bq edx girp ki peax pgue m hbofc secvu uefj qqjll dzqha znsl nip j rovy nb rpd jpm ufg a udn or ht t bkqie gpje o vo tfb fvd o mzsi xyxc vg l uzjzf mr zcw cbgq kvk bmn sl ngjc clk cn he i vk cbk n ar n wkmb zdzqz e ufes iqg pjq u bsk aj l gws sfxq laps rhzsl agdqu lwe wa w xw p jrk eiayj yy nu gsi s s mxl gzkqs mh shjvn u i igoi y e pvdeg bex nvh ykpl qmd rj e vbn xq kv tdju h xlq lsjs zpm sg txf lpa zzw ttqvx n yaij gjv ytem pmo uo x p nu hmdqo hp cnyy u x gn ido zr dmqhf mrby cebw cwzk lsiol vzeut zdm d g mm ua glr t v js n ey chmhg xrmj zymkp x ung cxs xh bu dtb pg hj drcax fj imfyc ylx y ng kqeh mprjn gg pobt xmw nd qium lkb ber qrb From owner-freebsd-toolchain@freebsd.org Sun Feb 21 10:42:47 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 75BE7AB0BFE for ; Sun, 21 Feb 2016 10:42:47 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 14FC115F8; Sun, 21 Feb 2016 10:42:46 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 52FF5153416; Sun, 21 Feb 2016 11:42:43 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uM0h4eb7G5aZ; Sun, 21 Feb 2016 11:42:23 +0100 (CET) Received: from [192.168.10.10] (asus [192.168.10.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 4D4B215340A; Sun, 21 Feb 2016 11:42:23 +0100 (CET) Subject: Re: Ceph compilation on inclusion of /usr/include/c++/v1/deque To: Dimitry Andric References: <56C88191.7030801@digiware.nl> <56C8C2D1.9070603@digiware.nl> Cc: FreeBSD Toolchain From: Willem Jan Withagen Message-ID: <56C9948E.60509@digiware.nl> Date: Sun, 21 Feb 2016 11:42:22 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56C8C2D1.9070603@digiware.nl> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 10:42:47 -0000 On 20-2-2016 20:47, Willem Jan Withagen wrote: > On 20-2-2016 16:50, Dimitry Andric wrote: >> On 20 Feb 2016, at 16:09, Willem Jan Withagen wrote: >>> >>> I'm trying to build a port of Ceph for FreeBSD, which is sort of trying >>> to shoot at a tank with a watergun.... :) >> >> This is very nice, it would be good to have Ceph on FreeBSD. Note that >> if you have problems with porting, usually the freebsd-ports mailing >> list is a better audience. >> >> >>> I you want to reproduce it is rather labourious, but not all that complex: >>> git clone https://github.com/wjwithagen/ceph.git >>> cd ceph >>> git checkout wip-wjw-freebsd-tests >>> ./do_freebsd.sh >>> >>> And wait for the error to appear. >> ... >>> /usr/include/c++/v1/deque:912:49: error: invalid application of 'sizeof' >>> to an incomplete type 'value_type' (aka 'RGWPeriod') >>> static const difference_type __block_size = sizeof(value_type) < 256 >>> ? 4096 / sizeof(value_type) : 16; >>> ^~~~~~~~~~~~~~~~~~ >>> /usr/include/c++/v1/deque:1159:15: note: in instantiation of template >>> class 'std::__1::__deque_base>> std::__1::allocator >' requested here >>> : private __deque_base<_Tp, _Allocator> >>> ^ >>> rgw/rgw_period_history.h:26:27: note: in instantiation of template class >>> 'std::__1::deque >>>> ' requested here >>> std::deque periods; >>> ^ >>> rgw/rgw_period_history.h:16:7: note: forward declaration of 'RGWPeriod' >>> class RGWPeriod; >>> ^ >> >> Without having to build anything, I see the problem already. :) The >> error message is unfortunately rather confusing, but the gist of it is >> that the implementation of std::deque<> requires a complete type. >> >> Which means that you cannot do this: >> >> #include >> class foo; >> std::deque bar; >> >> Compiling this example with clang and libc++ will result in (not all >> errors shown, no need to): >> >> In file included from deque-test.cpp:1: >> /usr/include/c++/v1/deque:912:49: error: invalid application of 'sizeof' to an incomplete type 'value_type' (aka 'foo') >> static const difference_type __block_size = sizeof(value_type) < 256 ? 4096 / sizeof(value_type) : 16; >> ^~~~~~~~~~~~~~~~~~ >> /usr/include/c++/v1/deque:1159:15: note: in instantiation of template class 'std::__1::__deque_base >' requested here >> : private __deque_base<_Tp, _Allocator> >> ^ >> deque-test.cpp:3:17: note: in instantiation of template class 'std::__1::deque >' requested here >> std::deque bar; >> ^ >> deque-test.cpp:2:7: note: forward declaration of 'foo' >> class foo; >> ^ >> >> Similarly, compiling the example with g++ and libstdc++ (6.0.0 from >> ports) results in: >> >> In file included from /usr/local/lib/gcc6/include/c++/deque:64:0, >> from deque-test.cpp:1: >> /usr/local/lib/gcc6/include/c++/bits/stl_deque.h: In instantiation of 'void std::_Deque_base<_Tp, _Alloc>::_M_initialize_map(std::size_t) [with _Tp = foo; _Alloc = std::allocator; std::size_t = unsigned int]': >> /usr/local/lib/gcc6/include/c++/bits/stl_deque.h:490:26: required from 'std::_Deque_base<_Tp, _Alloc>::_Deque_base() [with _Tp = foo; _Alloc = std::allocator]' >> /usr/local/lib/gcc6/include/c++/bits/stl_deque.h:884:23: required from 'std::deque<_Tp, _Alloc>::deque() [with _Tp = foo; _Alloc = std::allocator]' >> deque-test.cpp:3:17: required from here >> /usr/local/lib/gcc6/include/c++/bits/stl_deque.h:682:74: error: invalid application of 'sizeof' to incomplete type 'foo' >> const size_t __num_nodes = (__num_elements/ __deque_buf_size(sizeof(_Tp)) >> ^ >> /usr/local/lib/gcc6/include/c++/bits/stl_deque.h:713:31: error: invalid application of 'sizeof' to incomplete type 'foo' >> % __deque_buf_size(sizeof(_Tp))); >> ^ >> >> Looking at rgw_period_history.h, it is indeed using an incomplete type: >> >> #include >> #include >> #include >> #include >> #include "include/assert.h" >> #include "include/types.h" >> >> namespace bi = boost::intrusive; >> >> class RGWPeriod; >> >> /** >> * RGWPeriodHistory tracks the relative history of all inserted periods, >> * coordinates the pulling of missing intermediate periods, and provides a >> * Cursor object for traversing through the connected history. >> */ >> class RGWPeriodHistory final { >> /// an ordered history of consecutive periods >> struct History : public bi::avl_set_base_hook<> { >> std::deque periods; >> >> E.g at this point, all the compiler has is a forward declaration of >> RGWPeriod. If this even compiles on Linux, I am unsure how it manages >> to do so. :-) Maybe the Linux build pulls in some other header first, >> getting the full definition of RGWPeriod somehow? >> >> In any case, the easiest fix is probably to switch around the inclusions >> of the headers in rgw_period_history.cc, e.g. changing: >> >> #include "rgw_period_history.h" >> #include "rgw_rados.h" >> >> to: >> >> #include "rgw_rados.h" >> #include "rgw_period_history.h" >> >> Since rgw_rados.h contains the full definition of RGWPeriod, the forward >> declaration on line 16 of rgw_period_history.h can then be deleted. >> >> Alternatively, include rgw_rados.h directly in rgw_period_history.h, >> which is what I would do. I am unsure how Ceph upstream thinks about >> that, though. Maybe you can check with them? > > Hi Dimitry, > > Thanx for all the advise. > It is going to take some time to absorbe all. :) > > I've got a FreeBSD pull running, and on and off I'm commented by other > committers as to how or why... You've given enough text to actually put > in the commit message. And we'll find out how they feel about it. > > As to running this by the ports list, I have not really seen any this > type of problem passing by there. Next to that I expected it more to be > GCC <> Clang because every commit is run through Jenkins compilation and > testing, and it would be noticed there. There were some more loop dependancies which required forward declaration and alter inclusion of include files. But in the end I got it to compile again. So thanx for the help. --WjW From owner-freebsd-toolchain@freebsd.org Sun Feb 21 11:52:50 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 904DDAAF5E6 for ; Sun, 21 Feb 2016 11:52:50 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-153.reflexion.net [208.70.211.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 555A01F4D for ; Sun, 21 Feb 2016 11:52:50 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5862 invoked from network); 21 Feb 2016 11:52:41 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 21 Feb 2016 11:52:41 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 21 Feb 2016 06:52:54 -0500 (EST) Received: (qmail 12166 invoked from network); 21 Feb 2016 11:52:54 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 21 Feb 2016 11:52:54 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 3E1341C43AE; Sun, 21 Feb 2016 03:52:41 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: I've submitted 207175 for a clang 3.8.0 va_list handling problem for powerpc [fpr use also tested] From: Mark Millard In-Reply-To: <20160221090215.GA21511@vlakno.cz> Date: Sun, 21 Feb 2016 03:52:41 -0800 Cc: Dimitry Andric , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <1047AD1A-BCE1-44B0-A649-60343A89207D@dsl-only.net> References: <3A260EC5-E69A-4980-8F74-C04395F4E5F4@dsl-only.net> <20160215201800.GA20796@vlakno.cz> <74577A87-3006-43A9-9EAB-F51D946B6245@dsl-only.net> <28FF474D-2109-4605-8B2B-C5374CBCCF42@dsl-only.net> <8EB46124-3335-4643-8C64-16DA56D481F5@dsl-only.net> <8C40A5D7-C0B8-4142-89D4-228017C446CE@dsl-only.net> <20160220083450.GA55777@vlakno.cz> <68D66F67-EC4D-4CF2-A249-C7F0C4D4747D@FreeBSD.org> <20160221090215.GA21511@vlakno.cz> To: Roman Divacky X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 11:52:50 -0000 On 2016-Feb-21, at 1:02 AM, Roman Divacky = wrote: >=20 > On Sat, Feb 20, 2016 at 03:26:58PM +0100, Dimitry Andric wrote: >> On 20 Feb 2016, at 09:34, Roman Divacky = wrote: >>> Fwiw, I've just committed the patch to clang in r261422. You might = want >>> to keep using a local modification or ask dim@ to import that patch >>> to our copy of 3.8. >>=20 >> I've asked the LLVM release manager to consider merging this into the >> 3.8 branch. The fix looks trivial enough. :) >>=20 >> -Dimitry >>=20 >=20 > Cool :) >=20 > Mark, so what remains broken now beside the C++ exceptions? Also, can = you try > to take a look at kernel? >=20 > Thanks! Roman Implication of the below detailed answer: I've not thought about the = kernel much so far and it may well be some time before I do. Getting each thing fixed/operable/improved/worked-around for = world/userland has helped me explore finding the next thing. The C++ = exception problems currently block using "kyua -k /usr/tests/Kyuafile", = something I've been hoping to be able to do as evidence for how much is = (then) working based on a clang 3.8.0 buildworld. I've been sticking to = providing evidence for details world/userland issues before tackling = anything else. (So far I'm not generally fixing things, mostly just = finding evidence of problem details.) You may not know that I run PowerPC (32-bit) with modified signal = delivery: my adjustment uses a so-called "red-zone" to avoid the = incorrect timing of the stack pointer adjustments that clang 3.8.0's = code generation produces. (An ABI violation that I've worked around for = world/userland.) The work around was required to be able to have a = self-hosted buildworld's complete without make getting SEGV's/BusError's = that stop the build. No one is working on clang 3.8.0's 32-bit PowerPC stack-pointer-handling = ABI violations so far as I know. I doubt anyone will tackle the kernel overall for 32-bit PowerPC as long = as the stack pointer is decremented late and incremented early in = clang's generated code. I expect that handling such is comparatively = simple in world/userland (see above) compared to in the kernel and the = kernel's handling of is own stack. I doubt that FreeBSD would make even the red-zone code change for = world/userland official. It is operationally compatible with the = official ABI in world/userland but is temporarily somewhat wasteful of = some stack bytes. But mostly it is just something not required by the = official ABI and the signal delivery change does not help the = bigger/messier kernel-stack handling issue. I doubt FreeBSD would ever officially split buildworld and buildkernel = by using different compilers as I have, even temporarily. So no official = PowerPC clang context until everything works for both parts would be my = guess. I just view the split as a development/testing technique for = helping find details of problems in the simpler world/userland context = first. I did once take a quick look at clang 3.8.0 use in buildkernel instead = of using gcc 4.2.1. I do not remember all the details but one thing that = I remember is that clang's integrated-assembler notation and the = kernel's source files did not agree in various places. I have no formal descriptions of the two assembler notations or = description of how they correspond where different. This tends to = prevent any systematic process for such issues. (I'm no PowerPC = assembler expert: I look things up as I go.) If I remember the count right I also identified two other kernel = points-for-investigation very quickly and stopped there in order to = continue with world/userland investigations. I was guessing there was a = lot more to find relative to the kernel based on how quickly those 3 = subject areas were found. Since I started exploring FreeBSD I've observed that things happen = without prior notice that suspend my FreeBSD activity for weeks or = months at a time. That has happened several times. So I'm not sure how = far I'll get before such happens again. And PowerPC access has that issue even more: I can end up without access = to the old PowerMacs for long periods even if I can spend some time = exploring some (other) aspects of FreeBSD at the time. At this point I've no clue how I'll find what specific details are = involved in the "clang 3.8.0 compiled C++ exception infrastructure vs. = clang++380/g++5/g++49/g++421 compiled code" mismatch. I've no clue how = long that will take. So, overall, I'm not ready to think much about the kernel yet. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Tue Feb 23 09:50:39 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D748EAB11BE for ; Tue, 23 Feb 2016 09:50:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-153.reflexion.net [208.70.211.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9BCE11B8B for ; Tue, 23 Feb 2016 09:50:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 11175 invoked from network); 23 Feb 2016 09:50:33 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 23 Feb 2016 09:50:33 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Tue, 23 Feb 2016 04:50:26 -0500 (EST) Received: (qmail 1580 invoked from network); 23 Feb 2016 09:50:26 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 23 Feb 2016 09:50:26 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 349181C43CA; Tue, 23 Feb 2016 01:50:31 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: projects/clang380-import for TARGET_ARCH=powerpc64: /lib/libgcc_s.so.1 is incompatible with using the pair: /usr/lib/libc++.so.1 and /lib/libcxxrt.so.1 for C++ exception handling Date: Tue, 23 Feb 2016 01:50:31 -0800 Message-Id: <5B9137BF-0E86-4C4B-A3FB-18F444A850AC@dsl-only.net> Cc: Roman Divacky , Dimitry Andric To: FreeBSD PowerPC ML , FreeBSD Toolchain Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 09:50:39 -0000 For TARGET_ARCH=3Dpowerpc64 it looks like FreeBSD's /lib/libgcc_s.so.1 = is incompatible with using the pair: /usr/lib/libc++.so.1 and = /lib/libcxxrt.so.1 . Evidence details follow. (Now using projects/clang380-import -r295902 as = a context.) src.conf was set up to have things such that the buildworld/buildkernel = that this is based on was via : devel/powerpc64-gcc as the (self hosted) cross compiler ( /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ ) and clang 3.8.0 as the "host" compiler. Later below I list the ldd output for compiling the exception_test.cpp = example under different compilers with different options that change = what ldd shows and how .so's are found/bound. Some are implicitly using. = . . ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib = /usr/local/lib/compat/pkg /usr/local/lib/compat/pkg /usr/local/lib/gcc49 = /usr/local/lib/gcc6 and others are explicitly bound, such as by -Wl,-rpath=3D . The only combinations that get the unbounded looping internal to = exception handling are the ones that mix 3 things together: /usr/lib/libc++.so.1 /lib/libcxxrt.so.1 /lib/libgcc_s.so.1 That is: exception_test.clang++380.powerpc64 and = exception_test.powerpc64-gcc.powerpc64 get the unbounded looping and the = others work fine. Note that all 3 libraries were built by devel/powerpc64-gcc during = buildworld, not by clang 3.8.0 . And = exception_test.powerpc64-gcc.powerpc64 does not involve clang 3.8.0 = based code at all. Still libc++.so.1 and libcxxrt.so.1 are "foreign" relative to = libgcc_s.so.1 and so there being some form of mismatch possible makes = some sense. That same /lib/libgcc_s.so.1 works fine with: /usr/local/lib/gcc49/libstdc++.so.6 and /usr/local/lib/gcc6/libstdc++.so.6 Of course a matched libstdc++/libgcc_s pair for a specific g++ compiler = also works. The combinations tested are . . . # ldd *powerpc64 exception_test.clang++380.powerpc64: libc++.so.1 =3D> /usr/lib/libc++.so.1 (0x50054000) libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x5015a000) libm.so.5 =3D> /lib/libm.so.5 (0x50181000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x501be000) libc.so.7 =3D> /lib/libc.so.7 (0x501e4000) exception_test.g++49-implicitgcc49.powerpc64: libstdc++.so.6 =3D> /usr/local/lib/gcc49/libstdc++.so.6 = (0x50054000) libm.so.5 =3D> /lib/libm.so.5 (0x501ed000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x5022a000) libc.so.7 =3D> /lib/libc.so.7 (0x50250000) exception_test.g++49.powerpc64: libstdc++.so.6 =3D> /usr/local/lib/gcc49/libstdc++.so.6 = (0x50054000) libm.so.5 =3D> /lib/libm.so.5 (0x501ed000) libgcc_s.so.1 =3D> /usr/local/lib/gcc49/libgcc_s.so.1 = (0x5022a000) libc.so.7 =3D> /lib/libc.so.7 (0x50253000) exception_test.g++6-implicitgcc49.powerpc64: libstdc++.so.6 =3D> /usr/local/lib/gcc49/libstdc++.so.6 = (0x50054000) libm.so.5 =3D> /lib/libm.so.5 (0x501ed000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x5022a000) libc.so.7 =3D> /lib/libc.so.7 (0x50250000) exception_test.g++6.powerpc64: libstdc++.so.6 =3D> /usr/local/lib/gcc6/libstdc++.so.6 = (0x50054000) libm.so.5 =3D> /lib/libm.so.5 (0x502a6000) libgcc_s.so.1 =3D> /usr/local/lib/gcc6/libgcc_s.so.1 = (0x502e3000) libc.so.7 =3D> /lib/libc.so.7 (0x5030a000) exception_test.powerpc64-gcc.powerpc64: libc++.so.1 =3D> /usr/lib/libc++.so.1 (0x50053000) libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x50159000) libm.so.5 =3D> /lib/libm.so.5 (0x50180000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x501bd000) libc.so.7 =3D> /lib/libc.so.7 (0x501e3000) NOTE: Why no g++5 test using its /usr/local/lib/gcc5/libstdc++.so.6? Currently devel/powerpc64-gcc and lang/gcc5 are both at 5.3 and that = makes them conflict on files if one tries to build both ports. So I have just devel/powerpc64-gcc, the "officially produced" cross = compiler port for targeting modernized powerpc64 builds. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Wed Feb 24 11:30:09 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 42A93AB3E23 for ; Wed, 24 Feb 2016 11:30:09 +0000 (UTC) (envelope-from gofdt-freebsd-toolchain@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0A9C59EC for ; Wed, 24 Feb 2016 11:30:08 +0000 (UTC) (envelope-from gofdt-freebsd-toolchain@m.gmane.org) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aYXdu-00056u-64 for freebsd-toolchain@freebsd.org; Wed, 24 Feb 2016 12:30:06 +0100 Received: from dhcp-077-248-147-050.chello.nl ([77.248.147.50]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 24 Feb 2016 12:30:06 +0100 Received: from rakuco by dhcp-077-248-147-050.chello.nl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 24 Feb 2016 12:30:06 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-toolchain@freebsd.org From: Raphael Kubo da Costa Subject: clang -pg, libm and the _end symbol Date: Wed, 24 Feb 2016 12:27:03 +0100 Lines: 26 Message-ID: <86povmbb7c.fsf@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: dhcp-077-248-147-050.chello.nl User-Agent: Gnus/5.130016 (Ma Gnus v0.16) Emacs/24.5 (berkeley-unix) Cancel-Lock: sha1:moKda/I6cwgeDppbIhPU2PhRylM= X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 11:30:09 -0000 I'm reviewing an update to the textproc/miller port in bug 207194, and noticed it does some ugly things in post-configure to seemingly work around the following problem (on 11-HEAD at least): % echo 'int main(void) { return 0; }' > foo.c % clang -pg foo.c -lm /usr/bin/ld: undefined reference to symbol `_end' (try adding -lc) //lib/libc.so.7: could not read symbols: Bad value cc: error: linker command failed with exit code 1 (use -v to see invocation) (FWIW, using another library such as -lz instead of -lm retuls in the same problem) Adding LDFLAGS+=-lc to the port's Makefile would've been enough, but I'm not sure if it'd be just working around an actual bug, plus libtool automatically strips -lc from the linker invocation: 7534 *-*-openbsd* | *-*-freebsd* | *-*-dragonfly* | *-*-bitrig*) 7535 # Do not include libc due to us having libc/libc_r. 7536 test X-lc = "X$arg" && continue The port builds and links fine on 9.3 without any workarounds, and if I explicitly use ld.gold to link the above file it also works on HEAD. Is clang working as expected or is this a bug? From owner-freebsd-toolchain@freebsd.org Wed Feb 24 12:30:51 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 08658AB2744 for ; Wed, 24 Feb 2016 12:30:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 98CED1731; Wed, 24 Feb 2016 12:30:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u1OCUjx6043555 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 24 Feb 2016 14:30:45 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u1OCUjx6043555 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u1OCUjHD043553; Wed, 24 Feb 2016 14:30:45 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 24 Feb 2016 14:30:45 +0200 From: Konstantin Belousov To: Raphael Kubo da Costa Cc: freebsd-toolchain@freebsd.org Subject: Re: clang -pg, libm and the _end symbol Message-ID: <20160224123045.GM91220@kib.kiev.ua> References: <86povmbb7c.fsf@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86povmbb7c.fsf@FreeBSD.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 12:30:51 -0000 On Wed, Feb 24, 2016 at 12:27:03PM +0100, Raphael Kubo da Costa wrote: > I'm reviewing an update to the textproc/miller port in bug 207194, and > noticed it does some ugly things in post-configure to seemingly > work around the following problem (on 11-HEAD at least): > > % echo 'int main(void) { return 0; }' > foo.c > % clang -pg foo.c -lm > /usr/bin/ld: undefined reference to symbol `_end' (try adding -lc) > //lib/libc.so.7: could not read symbols: Bad value > cc: error: linker command failed with exit code 1 (use -v to see > invocation) > > (FWIW, using another library such as -lz instead of -lm retuls in the > same problem) > > Adding LDFLAGS+=-lc to the port's Makefile would've been enough, but I'm > not sure if it'd be just working around an actual bug, plus libtool > automatically strips -lc from the linker invocation: > > 7534 *-*-openbsd* | *-*-freebsd* | *-*-dragonfly* | *-*-bitrig*) > 7535 # Do not include libc due to us having libc/libc_r. > 7536 test X-lc = "X$arg" && continue > > The port builds and links fine on 9.3 without any workarounds, and if I > explicitly use ld.gold to link the above file it also works on HEAD. > > Is clang working as expected or is this a bug? This is probably not a clang bug, but could be. More likely it is ld problem. I do not want to dig into the issue, but I can provide you some points to look at further. The _end symbol is magic, it is defined as the address of the last byte + 1 of zero-initialized data section (.bss). But the symbol is not provided by any object file participating in the linkage of the binary, instead it is created by the linker after all sections are combined in the segments and segments are laid out. The symbol is creation requested by the linker script, look at the /usr/libdata/ldscripts for them, first line of the file contains comment explaining which final binary format is served by the each script. We are aware that binutils 2.25.1 ld for aarch64 has bug where _end is not exported from executable, I was not able to track the bug. To diagnose your issue, look up which linker script is used for -pg linking, look for the _end symbol there. If it is properly requested, then the bug is in base linker. From owner-freebsd-toolchain@freebsd.org Wed Feb 24 12:54:50 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6C1EAB3263 for ; Wed, 24 Feb 2016 12:54:50 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AF575867; Wed, 24 Feb 2016 12:54:50 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2a03:fc02:2:1:c43e:b23e:8d62:2c5] (unknown [IPv6:2a03:fc02:2:1:c43e:b23e:8d62:2c5]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 2836C3849B; Wed, 24 Feb 2016 13:54:46 +0100 (CET) Subject: Re: clang -pg, libm and the _end symbol Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_1D12CB61-D311-488D-8BD3-8B58193317CC"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 (ebbf3ef) From: Dimitry Andric In-Reply-To: <86povmbb7c.fsf@FreeBSD.org> Date: Wed, 24 Feb 2016 13:54:25 +0100 Cc: freebsd-toolchain@freebsd.org Message-Id: <1CEB597F-1446-4E73-B5E2-5E5A4B3E9313@FreeBSD.org> References: <86povmbb7c.fsf@FreeBSD.org> To: Raphael Kubo da Costa X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 12:54:51 -0000 --Apple-Mail=_1D12CB61-D311-488D-8BD3-8B58193317CC Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 24 Feb 2016, at 12:27, Raphael Kubo da Costa wrote: > > I'm reviewing an update to the textproc/miller port in bug 207194, and > noticed it does some ugly things in post-configure to seemingly > work around the following problem (on 11-HEAD at least): > > % echo 'int main(void) { return 0; }' > foo.c > % clang -pg foo.c -lm > /usr/bin/ld: undefined reference to symbol `_end' (try adding -lc) > //lib/libc.so.7: could not read symbols: Bad value > cc: error: linker command failed with exit code 1 (use -v to see > invocation) Try using: clang -pg foo.c -lm_p That works for me (also with gcc). -Dimitry --Apple-Mail=_1D12CB61-D311-488D-8BD3-8B58193317CC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.29 iEYEARECAAYFAlbNqBYACgkQsF6jCi4glqOhrgCeOBBciOqLUtG1+0Ycv36tDPGN txYAn0AZ8f6/jOvm/b9o+j12txoZCsDx =xoBd -----END PGP SIGNATURE----- --Apple-Mail=_1D12CB61-D311-488D-8BD3-8B58193317CC-- From owner-freebsd-toolchain@freebsd.org Wed Feb 24 13:19:59 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3EF74AB3C6F for ; Wed, 24 Feb 2016 13:19:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CB3311612; Wed, 24 Feb 2016 13:19:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u1ODJsBH054940 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 24 Feb 2016 15:19:54 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u1ODJsBH054940 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u1ODJshG054939; Wed, 24 Feb 2016 15:19:54 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 24 Feb 2016 15:19:54 +0200 From: Konstantin Belousov To: Dimitry Andric Cc: Raphael Kubo da Costa , freebsd-toolchain@freebsd.org Subject: Re: clang -pg, libm and the _end symbol Message-ID: <20160224131954.GP91220@kib.kiev.ua> References: <86povmbb7c.fsf@FreeBSD.org> <1CEB597F-1446-4E73-B5E2-5E5A4B3E9313@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1CEB597F-1446-4E73-B5E2-5E5A4B3E9313@FreeBSD.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 13:19:59 -0000 On Wed, Feb 24, 2016 at 01:54:25PM +0100, Dimitry Andric wrote: > On 24 Feb 2016, at 12:27, Raphael Kubo da Costa wrote: > > > > I'm reviewing an update to the textproc/miller port in bug 207194, and > > noticed it does some ugly things in post-configure to seemingly > > work around the following problem (on 11-HEAD at least): > > > > % echo 'int main(void) { return 0; }' > foo.c > > % clang -pg foo.c -lm > > /usr/bin/ld: undefined reference to symbol `_end' (try adding -lc) > > //lib/libc.so.7: could not read symbols: Bad value > > cc: error: linker command failed with exit code 1 (use -v to see > > invocation) > > Try using: clang -pg foo.c -lm_p > > That works for me (also with gcc). It probably not quite works, in the sense that it resolves _end to something not correctly provided by libm_p.a. In other words, sbrk(), if used for anything, would be broken. From owner-freebsd-toolchain@freebsd.org Wed Feb 24 13:29:04 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D23CCAB2006 for ; Wed, 24 Feb 2016 13:29:04 +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 mx1.freebsd.org (Postfix) with ESMTPS id C3B841C92 for ; Wed, 24 Feb 2016 13:29:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u1ODT4BW016335 for ; Wed, 24 Feb 2016 13:29:04 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207253] cad/openvsp: Fix in 11-CURRENT Date: Wed, 24 Feb 2016 13:29:05 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: easy, patch, patch-ready X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rakuco@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Flags: merge-quarterly? X-Bugzilla-Changed-Fields: cc 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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 13:29:04 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207253 Raphael Kubo da Costa changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |freebsd-toolchain@FreeBSD.o | |rg --- Comment #7 from Raphael Kubo da Costa --- +freebsd-toolchain. Can someone take a look at comment #6 and check if libc= ++ is working as intended? --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Feb 24 14:06:01 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0C6ECAB2F23 for ; Wed, 24 Feb 2016 14:06:01 +0000 (UTC) (envelope-from gofdt-freebsd-toolchain@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C7AF6106E for ; Wed, 24 Feb 2016 14:06:00 +0000 (UTC) (envelope-from gofdt-freebsd-toolchain@m.gmane.org) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aYa4e-0000Cm-6K for freebsd-toolchain@freebsd.org; Wed, 24 Feb 2016 15:05:52 +0100 Received: from dhcp-077-248-147-050.chello.nl ([77.248.147.50]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 24 Feb 2016 15:05:52 +0100 Received: from rakuco by dhcp-077-248-147-050.chello.nl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 24 Feb 2016 15:05:52 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-toolchain@freebsd.org From: Raphael Kubo da Costa Subject: Re: clang -pg, libm and the _end symbol Date: Wed, 24 Feb 2016 15:05:38 +0100 Lines: 34 Message-ID: <86egc2b3v1.fsf@FreeBSD.org> References: <86povmbb7c.fsf@FreeBSD.org> <20160224123045.GM91220@kib.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: dhcp-077-248-147-050.chello.nl User-Agent: Gnus/5.130016 (Ma Gnus v0.16) Emacs/24.5 (berkeley-unix) Cancel-Lock: sha1:ZDU2SoiV4Eri4TJ+q7f44JUjzik= X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 14:06:01 -0000 Konstantin Belousov writes: > This is probably not a clang bug, but could be. More likely it is ld problem. > I do not want to dig into the issue, but I can provide you some points to > look at further. > > The _end symbol is magic, it is defined as the address of the last byte > + 1 of zero-initialized data section (.bss). But the symbol is not > provided by any object file participating in the linkage of the binary, > instead it is created by the linker after all sections are combined in > the segments and segments are laid out. > > The symbol is creation requested by the linker script, look at the > /usr/libdata/ldscripts for them, first line of the file contains > comment explaining which final binary format is served by the each > script. > > We are aware that binutils 2.25.1 ld for aarch64 has bug where _end is > not exported from executable, I was not able to track the bug. > > To diagnose your issue, look up which linker script is used for -pg > linking, look for the _end symbol there. If it is properly requested, > then the bug is in base linker. With and without -pg, the linker script being used is elf_x86_64_fbsd.xc ("Script for -z combreloc: combine and sort reloc sections"). It does contain an entry for _end: 182 _end = .; PROVIDE (end = .); lang/gcc with ld from devel/binutils also fails on HEAD: /usr/local/bin/ld: //usr/lib/libc_p.a(sbrk.po): undefined reference to symbol '_end' //lib/libc.so.7: error adding symbols: DSO missing from command line From owner-freebsd-toolchain@freebsd.org Wed Feb 24 14:10:12 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0BBDEAB3095 for ; Wed, 24 Feb 2016 14:10:12 +0000 (UTC) (envelope-from gofdt-freebsd-toolchain@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C8BB4119E for ; Wed, 24 Feb 2016 14:10:11 +0000 (UTC) (envelope-from gofdt-freebsd-toolchain@m.gmane.org) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aYa8h-0003Hq-MM for freebsd-toolchain@freebsd.org; Wed, 24 Feb 2016 15:10:03 +0100 Received: from dhcp-077-248-147-050.chello.nl ([77.248.147.50]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 24 Feb 2016 15:10:03 +0100 Received: from rakuco by dhcp-077-248-147-050.chello.nl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 24 Feb 2016 15:10:03 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-toolchain@freebsd.org From: Raphael Kubo da Costa Subject: Re: clang -pg, libm and the _end symbol Date: Wed, 24 Feb 2016 15:07:32 +0100 Lines: 28 Message-ID: <86a8mqb3rv.fsf@FreeBSD.org> References: <86povmbb7c.fsf@FreeBSD.org> <1CEB597F-1446-4E73-B5E2-5E5A4B3E9313@FreeBSD.org> <20160224131954.GP91220@kib.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: dhcp-077-248-147-050.chello.nl User-Agent: Gnus/5.130016 (Ma Gnus v0.16) Emacs/24.5 (berkeley-unix) Cancel-Lock: sha1:98fjp9FMTmIss1U4/j6BrgToCec= X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 14:10:12 -0000 Konstantin Belousov writes: > On Wed, Feb 24, 2016 at 01:54:25PM +0100, Dimitry Andric wrote: >> On 24 Feb 2016, at 12:27, Raphael Kubo da Costa wrote: >> > >> > I'm reviewing an update to the textproc/miller port in bug 207194, and >> > noticed it does some ugly things in post-configure to seemingly >> > work around the following problem (on 11-HEAD at least): >> > >> > % echo 'int main(void) { return 0; }' > foo.c >> > % clang -pg foo.c -lm >> > /usr/bin/ld: undefined reference to symbol `_end' (try adding -lc) >> > //lib/libc.so.7: could not read symbols: Bad value >> > cc: error: linker command failed with exit code 1 (use -v to see >> > invocation) >> >> Try using: clang -pg foo.c -lm_p >> >> That works for me (also with gcc). > > It probably not quite works, in the sense that it resolves _end to > something not correctly provided by libm_p.a. In other words, sbrk(), > if used for anything, would be broken. It at least "works" in the sense that clang doesn't fail; however, in addition to kib's point this doesn't look optimal from a ports perspective, as it requires giving special treatment to certain targets and possibly hacking the build system in different ports. From owner-freebsd-toolchain@freebsd.org Wed Feb 24 15:14:12 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8281BAB18E3 for ; Wed, 24 Feb 2016 15:14:12 +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 mx1.freebsd.org (Postfix) with ESMTPS id 73DF111D1 for ; Wed, 24 Feb 2016 15:14:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u1OFECnQ044370 for ; Wed, 24 Feb 2016 15:14:12 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207253] cad/openvsp: Fix in 11-CURRENT Date: Wed, 24 Feb 2016 15:14:12 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: easy, patch, patch-ready X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Flags: merge-quarterly? 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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 15:14:12 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207253 --- Comment #8 from Dimitry Andric --- I think the program should not try to use both "using namespace std", and t= hen use a reserved C++11 name. It should either drop the "using namespace std"= , or rename its own array to e.g. openvsp_array or even better, ovenvsp::array. In general, try to avoid "using namespace std". --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Feb 24 15:19:34 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5C911AB1AD2 for ; Wed, 24 Feb 2016 15:19: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 mx1.freebsd.org (Postfix) with ESMTPS id 4DE54160D for ; Wed, 24 Feb 2016 15:19:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u1OFJXnN051693 for ; Wed, 24 Feb 2016 15:19:34 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207253] cad/openvsp: Fix in 11-CURRENT Date: Wed, 24 Feb 2016 15:19:34 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: easy, patch, patch-ready X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rakuco@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Flags: merge-quarterly? 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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 15:19:34 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207253 --- Comment #9 from Raphael Kubo da Costa --- I agree, but this is legacy software (version 3 doesn't even have its own a= rray implementation anymore as far as I can see) that won't be changed upstream. My question is if libc++ is right in declaring std::array when not in C++11 mode or if this clash shouldn't happen at all, even if what the program doe= s is dangerous. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Feb 24 16:25:24 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BA18FAB35D1 for ; Wed, 24 Feb 2016 16:25:24 +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 mx1.freebsd.org (Postfix) with ESMTPS id AA7D01485 for ; Wed, 24 Feb 2016 16:25:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u1OGPObh023225 for ; Wed, 24 Feb 2016 16:25:24 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207253] cad/openvsp: Fix in 11-CURRENT Date: Wed, 24 Feb 2016 16:25:24 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: easy, patch, patch-ready X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: fernando.apesteguia@gmail.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Flags: merge-quarterly? 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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 16:25:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207253 --- Comment #10 from fernando.apesteguia@gmail.com --- (In reply to Raphael Kubo da Costa from comment #9) I think it is not doing the right thing. Have a look at this[1]. std::array= is a feature introduced in C++11 and the software is not using C++11 features. [1] http://www.cplusplus.com/reference/array/array/ --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Feb 24 19:01:48 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 21975AB3D49 for ; Wed, 24 Feb 2016 19:01:48 +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 mx1.freebsd.org (Postfix) with ESMTPS id 1157F113A for ; Wed, 24 Feb 2016 19:01:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u1OJ1lTl078557 for ; Wed, 24 Feb 2016 19:01:47 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207253] cad/openvsp: Fix in 11-CURRENT Date: Wed, 24 Feb 2016 19:01:48 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: easy, patch, patch-ready X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Flags: merge-quarterly? 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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 19:01:48 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207253 --- Comment #11 from Dimitry Andric --- (In reply to fernando.apesteguia from comment #10) > (In reply to Raphael Kubo da Costa from comment #9) >=20 > I think it is not doing the right thing. Have a look at this[1]. std::arr= ay > is a feature introduced in C++11 and the software is not using C++11 > features. >=20 > [1] http://www.cplusplus.com/reference/array/array/ Well, try to report this to libc++ upstream, and see what they say. I don't much feel like hacking our local copy with some change that will conflict w= ith whatever upstream is doing, let alone that we cannot do anything about the existing copies of libc++ out there. If openvsp is legacy software, it should be no problem to put a small patch= in which fixes this. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Feb 24 23:01:47 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9B438AB233C for ; Wed, 24 Feb 2016 23:01:47 +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 mx1.freebsd.org (Postfix) with ESMTPS id 8E0FE1A0F for ; Wed, 24 Feb 2016 23:01:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u1ON1lin028069 for ; Wed, 24 Feb 2016 23:01:47 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207253] cad/openvsp: Fix in 11-CURRENT Date: Wed, 24 Feb 2016 23:01:47 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: easy, patch, patch-ready X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: fernando.apesteguia@gmail.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Flags: merge-quarterly? 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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 23:01:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207253 --- Comment #12 from fernando.apesteguia@gmail.com --- (In reply to Dimitry Andric from comment #11) What strikes me is that the very same software works on FreeBSD 9.x and 10.x without issues (http://portsmon.freebsd.org/portoverview.py?category=3Dcad&portname=3Dopen= vsp). So something must have changed in libc++. I'm afraid we can break other softwa= re as stupid as they can be using names. I think it's worth having a look at w= hat it changed around July 2015 that was when the port started failing. I'm working on the port of OpenVSP 3.0 but it requires the addition of other ports first and it will take a while. In the meantime I would rather compile OpenVSP with gcc as the patch purposes instead of working on a new patch for the code. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Thu Feb 25 01:34:42 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BB026AB262B for ; Thu, 25 Feb 2016 01:34:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-154.reflexion.net [208.70.211.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7E228175E for ; Thu, 25 Feb 2016 01:34:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26965 invoked from network); 25 Feb 2016 01:08:17 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 25 Feb 2016 01:08:17 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Wed, 24 Feb 2016 20:08:04 -0500 (EST) Received: (qmail 9235 invoked from network); 25 Feb 2016 01:08:04 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 25 Feb 2016 01:08:04 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 9DF691C43C4; Wed, 24 Feb 2016 17:07:55 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: projects/clang380-import for TARGET_ARCH=powerpc64: /lib/libgcc_s.so.1 is incompatible with using the pair: /usr/lib/libc++.so.1 and /lib/libcxxrt.so.1 for C++ exception handling From: Mark Millard In-Reply-To: <5B9137BF-0E86-4C4B-A3FB-18F444A850AC@dsl-only.net> Date: Wed, 24 Feb 2016 17:07:59 -0800 Cc: Roman Divacky , Dimitry Andric Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B9137BF-0E86-4C4B-A3FB-18F444A850AC@dsl-only.net> To: FreeBSD PowerPC ML , FreeBSD Toolchain X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 01:34:42 -0000 [Deliberate top posting an history removal for significant new = information.] I've finally traced the low level details of the powerpc64 = _Unwind_RaiseException stuck looping failure. What I've submitted into = the defect is basically that for clang 3.8.0's .eh_frame information = generation in libcxxrt's code there is an error in the form of an = incompleteness. . . Starting from the observed low-level evidence based on observation via = gdb and such: A backtrace while stopped during the unbounded looping is: > #0 uw_update_context (context=3Dcontext@entry=3D0xffffffffffffccf0, = fs=3Dfs@entry=3D0xffffffffffffc370) at = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c:1371 > #1 0x00000000501cb95c in _Unwind_RaiseException (exc=3D0x50815058) at = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind.inc:126 > #2 0x000000005016e3a0 in throw_exception (ex=3D0x50815000) at = /usr/src/lib/libcxxrt/../../contrib/libcxxrt/exception.cc:751 > #3 0x0000000010000d50 in main () at exception_test.cpp:5 _Unwind_RaiseException never returns for source code that looks like: > #include >=20 > int main(void) > { > try { throw std::exception(); } > catch (std::exception& e) {} > return 0; > } where in /usr/lib/libc++.so.1 there is: > 736 static void throw_exception(__cxa_exception *ex) > 737 { > . . . > 751 _Unwind_Reason_Code err =3D = _Unwind_RaiseException(&ex->unwindHeader); > . . . > 756 } The unbounded loop in _Unwind_RaiseException is in the code: > 85 _Unwind_Reason_Code > 86 _Unwind_RaiseException(struct _Unwind_Exception *exc) > 87 { > 88 struct _Unwind_Context this_context, cur_context; > 89 _Unwind_Reason_Code code; > 90=09 > 91 /* Set up this_context to describe the current stack frame. = */ > 92 uw_init_context (&this_context); > 93 cur_context =3D this_context; > 94=09 > 95 /* Phase 1: Search. Unwind the stack, calling the personality = routine > 96 with the _UA_SEARCH_PHASE flag set. Do not modify the = stack yet. */ > 97 while (1) > 98 { > 99 _Unwind_FrameState fs; > 100=09 > 101 /* Set up fs to describe the FDE for the caller of = cur_context. The > 102 first time through the loop, that means __cxa_throw. = */ > 103 code =3D uw_frame_state_for (&cur_context, &fs); > . . . > 125 /* Update cur_context to describe the same frame as fs. = */ > 126 uw_update_context (&cur_context, &fs); > 127 } > . . . > 140 } The uw_update_context call is doing the following before returning: > 1367 /* Compute the return address now, since the return address = column > 1368 can change from frame to frame. */ > 1369 context->ra =3D __builtin_extract_return_addr > 1370 (_Unwind_GetPtr (context, fs->retaddr_column)); with context->ra before and after the call both being 0x5016e3a0 . In = fact it was 0x5016e3a0 for the prior uw_frame_state_for call as well and = continues to be so each loop iteration once the problem starts. As for the code around 0x5016e3a0: > 0x5016e398 : = stw r10,48(r9) > 0x5016e39c : = bl 0x50162ae0 <00000017.plt_call._Unwind_RaiseException@@GCC_3.0> > 0x5016e3a0 : = ld r2,40(r1) > 0x5016e3a4 : = addi r1,r1,128 > 0x5016e3a8 : = mr r4,r31 > 0x5016e3ac : = ld r0,16(r1) =46rom /usr/local/bin/objdump for FreeBSD projects/clang380-import = -r295902's /usr/lib/libc++.so.1 for the same code (to match up with the = .eh_frame dwarf information): > 0000000000015398 <.__cxa_end_catch+0x4d8> stw r10,48(r9) > 000000000001539c <.__cxa_end_catch+0x4dc> bl 0000000000009ae0 = > 00000000000153a0 <.__cxa_end_catch+0x4e0> ld r2,40(r1) > 00000000000153a4 <.__cxa_end_catch+0x4e4> addi r1,r1,128 > 00000000000153a8 <.__cxa_end_catch+0x4e8> mr r4,r31 > 00000000000153ac <.__cxa_end_catch+0x4ec> ld r0,16(r1) The code block above from 153a0 up to 153a8 is being given 153a0 as its = "return address" (context->ra) by uw_update_context via interpreting the = dwarf .eh_frame information. So once in that range there it never leaves = that range. The relevant dwarfdump output spanning that area is: (Note that 153a0 up to 153a8 is part of the range that includes the bl = to _Unwind_RaiseException .) > < 0><0x00015310:0x000153dc><> > 0x00015310: =20 > 0x00015318: =20 > 0x00015324: =20 > 0x00015368: =20 > 0x00015378: =20 > 0x00015380: =20 > 0x000153a8: =20 > 0x000153b8: =20 > 0x000153c0: =20 > fde section offset 4312 0x000010d8 cie offset for fde: 4316 = 0x000010dc > 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 > 35 DW_CFA_nop > 36 DW_CFA_nop > 37 DW_CFA_nop > 38 DW_CFA_nop Note that the stack pointer manipulation (incrementing/popping) *after* = the return from the bl. 15339c, 153a0, and 153a4 should be 3 or so = distinct contexts in the .eh_frame information but are not. The code is: > 000000000001539c <.__cxa_end_catch+0x4dc> bl 0000000000009ae0 = > 00000000000153a0 <.__cxa_end_catch+0x4e0> ld r2,40(r1) > 00000000000153a4 <.__cxa_end_catch+0x4e4> addi r1,r1,128 So there is a missing step or more of frame-context tracking in the = .eh_frame information. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Thu Feb 25 01:59:45 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 38199AB30CE for ; Thu, 25 Feb 2016 01:59:45 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-155.reflexion.net [208.70.211.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F012A393 for ; Thu, 25 Feb 2016 01:59:44 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 6494 invoked from network); 25 Feb 2016 01:53:20 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 25 Feb 2016 01:53:20 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Wed, 24 Feb 2016 20:52:58 -0500 (EST) Received: (qmail 25827 invoked from network); 25 Feb 2016 01:52:57 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 25 Feb 2016 01:52:57 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id C82371C43AE; Wed, 24 Feb 2016 17:52:58 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: projects/clang380-import for TARGET_ARCH=powerpc64: /lib/libgcc_s.so.1 is incompatible with using the pair: /usr/lib/libc++.so.1 and /lib/libcxxrt.so.1 for C++ exception handling From: Mark Millard In-Reply-To: Date: Wed, 24 Feb 2016 17:53:03 -0800 Cc: Roman Divacky , Dimitry Andric Content-Transfer-Encoding: quoted-printable Message-Id: <440081D9-83A0-44B8-B209-C50DB4B52885@dsl-only.net> References: <5B9137BF-0E86-4C4B-A3FB-18F444A850AC@dsl-only.net> To: FreeBSD PowerPC ML , FreeBSD Toolchain X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 01:59:45 -0000 [In part: My references to libc++ should have been to libcxxrt. Also: = devel/powerpc64-gcc produced the incomplete .eh_frame information.] On 2016-Feb-24, at 5:07 PM, Mark Millard wrote: >=20 > [Deliberate top posting an history removal for significant new = information.] >=20 > I've finally traced the low level details of the powerpc64 = _Unwind_RaiseException stuck looping failure. What I've submitted into = the defect is basically that for clang 3.8.0's .eh_frame information = generation in libcxxrt's code there is an error in the form of an = incompleteness. . . >=20 >=20 > Starting from the observed low-level evidence based on observation via = gdb and such: >=20 > A backtrace while stopped during the unbounded looping is: >=20 >> #0 uw_update_context (context=3Dcontext@entry=3D0xffffffffffffccf0, = fs=3Dfs@entry=3D0xffffffffffffc370) at = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c:1371 >> #1 0x00000000501cb95c in _Unwind_RaiseException (exc=3D0x50815058) = at /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind.inc:126 >> #2 0x000000005016e3a0 in throw_exception (ex=3D0x50815000) at = /usr/src/lib/libcxxrt/../../contrib/libcxxrt/exception.cc:751 >> #3 0x0000000010000d50 in main () at exception_test.cpp:5 >=20 > _Unwind_RaiseException never returns for source code that looks like: >=20 >> #include >>=20 >> int main(void) >> { >> try { throw std::exception(); } >> catch (std::exception& e) {} >> return 0; >> } >=20 > where in /usr/lib/libc++.so.1 there is: >=20 >> 736 static void throw_exception(__cxa_exception *ex) >> 737 { >> . . . >> 751 _Unwind_Reason_Code err =3D = _Unwind_RaiseException(&ex->unwindHeader); >> . . . >> 756 } >=20 > The unbounded loop in _Unwind_RaiseException is in the code: >=20 >> 85 _Unwind_Reason_Code >> 86 _Unwind_RaiseException(struct _Unwind_Exception *exc) >> 87 { >> 88 struct _Unwind_Context this_context, cur_context; >> 89 _Unwind_Reason_Code code; >> 90=09 >> 91 /* Set up this_context to describe the current stack frame. = */ >> 92 uw_init_context (&this_context); >> 93 cur_context =3D this_context; >> 94=09 >> 95 /* Phase 1: Search. Unwind the stack, calling the personality = routine >> 96 with the _UA_SEARCH_PHASE flag set. Do not modify the = stack yet. */ >> 97 while (1) >> 98 { >> 99 _Unwind_FrameState fs; >> 100=09 >> 101 /* Set up fs to describe the FDE for the caller of = cur_context. The >> 102 first time through the loop, that means __cxa_throw. = */ >> 103 code =3D uw_frame_state_for (&cur_context, &fs); >> . . . >> 125 /* Update cur_context to describe the same frame as fs. = */ >> 126 uw_update_context (&cur_context, &fs); >> 127 } >> . . . >> 140 } >=20 > The uw_update_context call is doing the following before returning: >=20 >> 1367 /* Compute the return address now, since the return address = column >> 1368 can change from frame to frame. */ >> 1369 context->ra =3D __builtin_extract_return_addr >> 1370 (_Unwind_GetPtr (context, fs->retaddr_column)); >=20 > with context->ra before and after the call both being 0x5016e3a0 . In = fact it was 0x5016e3a0 for the prior uw_frame_state_for call as well and = continues to be so each loop iteration once the problem starts. >=20 > As for the code around 0x5016e3a0: >=20 >> 0x5016e398 : = stw r10,48(r9) >> 0x5016e39c : = bl 0x50162ae0 <00000017.plt_call._Unwind_RaiseException@@GCC_3.0> >> 0x5016e3a0 : = ld r2,40(r1) >> 0x5016e3a4 : = addi r1,r1,128 >> 0x5016e3a8 : = mr r4,r31 >> 0x5016e3ac : = ld r0,16(r1) >=20 > =46rom /usr/local/bin/objdump for FreeBSD projects/clang380-import = -r295902's /usr/lib/libc++.so.1 for the same code (to match up with the = .eh_frame dwarf information): >=20 >> 0000000000015398 <.__cxa_end_catch+0x4d8> stw r10,48(r9) >> 000000000001539c <.__cxa_end_catch+0x4dc> bl 0000000000009ae0 = >> 00000000000153a0 <.__cxa_end_catch+0x4e0> ld r2,40(r1) >> 00000000000153a4 <.__cxa_end_catch+0x4e4> addi r1,r1,128 >> 00000000000153a8 <.__cxa_end_catch+0x4e8> mr r4,r31 >> 00000000000153ac <.__cxa_end_catch+0x4ec> ld r0,16(r1) >=20 > The code block above from 153a0 up to 153a8 is being given 153a0 as = its "return address" (context->ra) by uw_update_context via interpreting = the dwarf .eh_frame information. So once in that range there it never = leaves that range. >=20 > The relevant dwarfdump output spanning that area is: > (Note that 153a0 up to 153a8 is part of the range that includes the bl = to _Unwind_RaiseException .) >=20 >> < 0><0x00015310:0x000153dc><> >> 0x00015310: =20 >> 0x00015318: =20 >> 0x00015324: =20 >> 0x00015368: =20 >> 0x00015378: =20 >> 0x00015380: =20 >> 0x000153a8: =20 >> 0x000153b8: =20 >> 0x000153c0: =20 >> fde section offset 4312 0x000010d8 cie offset for fde: 4316 = 0x000010dc >> 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 >> 35 DW_CFA_nop >> 36 DW_CFA_nop >> 37 DW_CFA_nop >> 38 DW_CFA_nop >=20 > Note that the stack pointer manipulation (incrementing/popping) = *after* the return from the bl. 15339c, 153a0, and 153a4 should be 3 or = so distinct contexts in the .eh_frame information but are not. The code = is: >=20 >> 000000000001539c <.__cxa_end_catch+0x4dc> bl 0000000000009ae0 = >> 00000000000153a0 <.__cxa_end_catch+0x4e0> ld r2,40(r1) >> 00000000000153a4 <.__cxa_end_catch+0x4e4> addi r1,r1,128 >=20 > So there is a missing step or more of frame-context tracking in the = .eh_frame information. I should have noted that devel/powerpc64-gcc was used for buildworld of = projects/clang380-import -r295902 (and other versions) --and so for = libcxxrt as well. So it is g++ 5.3 that put out the incomplete .eh_frame frame-context = tracking, not clang 3.8.0. There is also the point that I typed "libc++" in places that I should = have typed "libcxxrt". =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Thu Feb 25 04:46:50 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E4A9AB2314 for ; Thu, 25 Feb 2016 04:46:50 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-156.reflexion.net [208.70.211.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 63530BA0 for ; Thu, 25 Feb 2016 04:46:49 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28053 invoked from network); 25 Feb 2016 04:47:05 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 25 Feb 2016 04:47:05 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Wed, 24 Feb 2016 23:47:01 -0500 (EST) Received: (qmail 26850 invoked from network); 25 Feb 2016 04:47:01 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 25 Feb 2016 04:47:01 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 5B77A1C43CA; Wed, 24 Feb 2016 20:46:42 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: r207471 submitted against devel/powerpc64-gcc for _Unwind_RaiseException's internal unbounded looping; matching up with 207359 against base system Date: Wed, 24 Feb 2016 20:46:47 -0800 Message-Id: <38D884F8-0EB4-4F3E-9475-7465FE173D79@dsl-only.net> Cc: Andreas Tobler , Konstantin Belousov , Baptiste Daroussin To: FreeBSD PowerPC ML , FreeBSD Toolchain Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 04:46:50 -0000 > #include >=20 > int main(void) > { > try { throw std::exception(); } > catch (std::exception& e) {} // same result without & > return 0; > } compiled under devel/powerpc64-gcc (gcc 5.3 based) on a FreeBSD = projects/clang380-import (-r295902, for example) that was also built = (buildworld/buildkernel) with the same devel/powerpc64-gcc demonstrates: _Unwind_RaiseException never returns because it is stuck in a unbounded = loop. [clang380-import vs. 11.0-CURRENT is not likely to be a big distinction = here. PowerPC64 might be or might not be relative to g++ 5.3 .] The cause has been tracked down to incomplete (and so inaccurate) = .eh_frame information as shown below. I use a mix of . . . # /usr/local/bin/objdump -d --prefix-addresses libcxxrt.so.1.full output and the matching . . . # dwarfdump -v -v -F libcxxrt.so.1.full | more output to show this. 0000000000015350 <.__cxa_end_catch+0x490> addi r3,r31,88 0000000000015354 <.__cxa_end_catch+0x494> addi r10,r10,1 0000000000015358 <.__cxa_end_catch+0x498> stw r10,48(r9) 000000000001535c <.__cxa_end_catch+0x49c> bl 0000000000009ae0 = <00000017.plt_call._Unwind_RaiseException@@GCC_3.0> 0000000000015360 <.__cxa_end_catch+0x4a0> ld r2,40(r1) 0000000000015364 <.__cxa_end_catch+0x4a4> addi r1,r1,128 0000000000015368 <.__cxa_end_catch+0x4a8> mr r4,r31 vs. < 0><0x00015050:0x00015310> 0x00015050: =20 0x0001506c: =20 0x000150b8: =20 0x000150d0: =20 0x000150e0: =20 Of note here is that the return "address" from the bl context is = correctly identified as 0000000000015360 by the .eh_frame information = and its interpretation. But also of note there is that 0000000000015360 and 0000000000015364 = also are identified as having 0000000000015360 as their return address = (part of the same block of code as the bl as things are classified = above). (That is what the live code actually generates, up to relocation = issues changing addresses.) So when _Unwind_RaiseException attempts to walk up the stack from itself = for the first pass up the stack it gets to 0000000000015360. And from there it gets to 0000000000015360 and loops. And from there it gets to 0000000000015360 and loops. And from there it gets to 0000000000015360 and loops. And from there it gets to 0000000000015360 and loops. . . . This code/.eh_frame pattern occurs again a little later (and this is = where the original problem was observed for this low-level-detail view). = . . 0000000000015380 <.__cxa_end_catch+0x4c0> addis r8,r2,-1 0000000000015384 <.__cxa_end_catch+0x4c4> addi r3,r31,88 0000000000015388 <.__cxa_end_catch+0x4c8> ld r10,28144(r8) 000000000001538c <.__cxa_end_catch+0x4cc> std r10,32(r31) 0000000000015390 <.__cxa_end_catch+0x4d0> lwz r10,48(r9) 0000000000015394 <.__cxa_end_catch+0x4d4> addi r10,r10,1 0000000000015398 <.__cxa_end_catch+0x4d8> stw r10,48(r9) 000000000001539c <.__cxa_end_catch+0x4dc> bl 0000000000009ae0 = <00000017.plt_call._Unwind_RaiseException@@GCC_3.0> 00000000000153a0 <.__cxa_end_catch+0x4e0> ld r2,40(r1) 00000000000153a4 <.__cxa_end_catch+0x4e4> addi r1,r1,128 00000000000153a8 <.__cxa_end_catch+0x4e8> mr r4,r31 00000000000153ac <.__cxa_end_catch+0x4ec> ld r0,16(r1) vs. < 0><0x00015310:0x000153dc> 0x00015310: =20 0x00015318: =20 0x00015324: =20 0x00015368: =20 0x00015378: =20 0x00015380: =20 0x000153a8: =20 0x000153b8: =20 0x000153c0: =20 This leads to (during _Unwind_RaiseException's loop): . . . And from there it gets to 00000000000153a0 and loops. And from there it gets to 00000000000153a0 and loops. And from there it gets to 00000000000153a0 and loops. And from there it gets to 00000000000153a0 and loops. . . . 0000000000015360 and 00000000000153a0 should each be starts of new = code-block ranges for identifying a different return address. So C++ exception handling is broken for FreeBSD when buildworld is based = on devel/powerpc65-gcc: libcxxrt has examples of the error in it. I'd expect that gcc5 (5.3) has other contexts where it does not get the = correct return address via its .eh_frame generated materials, at least = for powerpc64. [207359 might be considered replaced by 207471.] =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Thu Feb 25 10:43:27 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 17918AB3BB8 for ; Thu, 25 Feb 2016 10:43:27 +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 mx1.freebsd.org (Postfix) with ESMTPS id E05D8AA6 for ; Thu, 25 Feb 2016 10:43:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u1PAhQnf077645 for ; Thu, 25 Feb 2016 10:43:26 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207253] cad/openvsp: Fix in 11-CURRENT Date: Thu, 25 Feb 2016 10:43:26 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: easy, patch, patch-ready X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rakuco@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Flags: merge-quarterly? X-Bugzilla-Changed-Fields: cc flagtypes.name attachments.created 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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 10:43:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207253 Raphael Kubo da Costa changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fernando.apesteguia@gmail.c | |om Attachment #167391| |maintainer-approval?(fernan Flags| |do.apesteguia@gmail.com) --- Comment #13 from Raphael Kubo da Costa --- Created attachment 167391 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D167391&action= =3Dedit Enclose array in a namespace (In reply to Dimitry Andric from comment #11)=20 > Well, try to report this to libc++ upstream, and see what they say. I do= n't > much feel like hacking our local copy with some change that will conflict > with whatever upstream is doing, let alone that we cannot do anything abo= ut > the existing copies of libc++ out there. OK. I was hoping you'd be willing to do that as it happened a few other tim= es in the past. (In reply to fernando.apesteguia from comment #12) > What strikes me is that the very same software works on FreeBSD 9.x and 1= 0.x > without issues > (http://portsmon.freebsd.org/portoverview.py?category=3Dcad&portname=3Dop= envsp). > So something must have changed in libc++. I'm afraid we can break other > software as stupid as they can be using names. I think it's worth having a > look at what it changed around July 2015 that was when the port started > failing. What changed is that libc++ and the rest of clang/LLVM were updated to more recent versions during that period, and these new versions introduced the changes that are breaking OpenVSP. > I'm working on the port of OpenVSP 3.0 but it requires the addition of ot= her > ports first and it will take a while. In the meantime I would rather comp= ile > OpenVSP with gcc as the patch purposes instead of working on a new patch = for > the code. Please take a look at this patch I'm attaching. It builds fine on HEAD for = me, and doesn't force the use of GCC. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Thu Feb 25 19:04:50 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BC566AB4B7E for ; Thu, 25 Feb 2016 19:04:50 +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 mx1.freebsd.org (Postfix) with ESMTPS id AAFC61D14 for ; Thu, 25 Feb 2016 19:04:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u1PJ4oDC041887 for ; Thu, 25 Feb 2016 19:04:50 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207253] cad/openvsp: Fix in 11-CURRENT Date: Thu, 25 Feb 2016 19:04:50 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: easy, patch, patch-ready X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: fernando.apesteguia@gmail.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Flags: merge-quarterly? X-Bugzilla-Changed-Fields: attachments.isobsolete attachments.created 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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 19:04:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207253 fernando.apesteguia@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #167089|0 |1 is obsolete| | --- Comment #14 from fernando.apesteguia@gmail.com --- Created attachment 167408 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D167408&action= =3Dedit poudriere log on 9.3-RELEASE-amd64 --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Thu Feb 25 19:05:17 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C535AAB4BC4 for ; Thu, 25 Feb 2016 19:05:17 +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 mx1.freebsd.org (Postfix) with ESMTPS id B40BF1D7E for ; Thu, 25 Feb 2016 19:05:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u1PJ5Hac042786 for ; Thu, 25 Feb 2016 19:05:17 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207253] cad/openvsp: Fix in 11-CURRENT Date: Thu, 25 Feb 2016 19:05:17 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: easy, patch, patch-ready X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: fernando.apesteguia@gmail.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Flags: merge-quarterly? X-Bugzilla-Changed-Fields: attachments.isobsolete attachments.created 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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 19:05:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207253 fernando.apesteguia@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #167090|0 |1 is obsolete| | --- Comment #15 from fernando.apesteguia@gmail.com --- Created attachment 167409 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D167409&action= =3Dedit poudriere log on 10.2-RELEASE-amd64 --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Thu Feb 25 19:06:52 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 229DFAB4C91 for ; Thu, 25 Feb 2016 19:06:52 +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 mx1.freebsd.org (Postfix) with ESMTPS id 1185D1F19 for ; Thu, 25 Feb 2016 19:06:52 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u1PJ6pPH045330 for ; Thu, 25 Feb 2016 19:06:51 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207253] cad/openvsp: Fix in 11-CURRENT Date: Thu, 25 Feb 2016 19:06:52 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: easy, patch, patch-ready X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: fernando.apesteguia@gmail.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Flags: merge-quarterly? 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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 19:06:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207253 --- Comment #16 from fernando.apesteguia@gmail.com --- Comment on attachment 167391 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D167391 Enclose array in a namespace I added two new poudriere logs for {9.3,10.2}amd64. I can also confirm the application runs fine on 10.2 --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Thu Feb 25 19:07:21 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E441AB4CE0 for ; Thu, 25 Feb 2016 19:07:21 +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 mx1.freebsd.org (Postfix) with ESMTPS id 6D66D1FCC for ; Thu, 25 Feb 2016 19:07:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u1PJ7Lut046081 for ; Thu, 25 Feb 2016 19:07:21 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207253] cad/openvsp: Fix in 11-CURRENT Date: Thu, 25 Feb 2016 19:07:21 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: easy, patch, patch-ready X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rakuco@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Flags: merge-quarterly? 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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 19:07:21 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207253 --- Comment #17 from Raphael Kubo da Costa --- Shall we proceed with this version then? --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Thu Feb 25 19:09:39 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 90D1BAB4DED for ; Thu, 25 Feb 2016 19:09:39 +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 mx1.freebsd.org (Postfix) with ESMTPS id 80100113 for ; Thu, 25 Feb 2016 19:09:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u1PJ9dg9049009 for ; Thu, 25 Feb 2016 19:09:39 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207253] cad/openvsp: Fix in 11-CURRENT Date: Thu, 25 Feb 2016 19:09:39 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: easy, patch, patch-ready X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: fernando.apesteguia@gmail.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Flags: merge-quarterly? 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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 19:09:39 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207253 --- Comment #18 from fernando.apesteguia@gmail.com --- (In reply to Raphael Kubo da Costa from comment #17) Yes, please. And thanks to come up with the patch. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Thu Feb 25 22:21:25 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0DF71AB40E1 for ; Thu, 25 Feb 2016 22:21:25 +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 mx1.freebsd.org (Postfix) with ESMTPS id 021D17B4 for ; Thu, 25 Feb 2016 22:21:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u1PMLO8p099042 for ; Thu, 25 Feb 2016 22:21:24 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207253] cad/openvsp: Fix in 11-CURRENT Date: Thu, 25 Feb 2016 22:21:24 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: easy, patch, patch-ready X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rakuco@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Flags: merge-quarterly? X-Bugzilla-Changed-Fields: flagtypes.name 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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 22:21:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207253 Raphael Kubo da Costa changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #167391|maintainer-approval?(fernan |maintainer-approval+ Flags|do.apesteguia@gmail.com) | --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Thu Feb 25 22:22:00 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B5FC2AB4216 for ; Thu, 25 Feb 2016 22:22:00 +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 mx1.freebsd.org (Postfix) with ESMTPS id AA3DB94A for ; Thu, 25 Feb 2016 22:22:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u1PMM0M9002109 for ; Thu, 25 Feb 2016 22:22:00 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207253] cad/openvsp: Fix in 11-CURRENT Date: Thu, 25 Feb 2016 22:22:00 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: easy, patch, patch-ready X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Flags: merge-quarterly? 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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 22:22:00 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207253 --- Comment #19 from commit-hook@freebsd.org --- A commit references this bug: Author: rakuco Date: Thu Feb 25 22:21:38 UTC 2016 New revision: 409563 URL: https://svnweb.freebsd.org/changeset/ports/409563 Log: Add patches to fix the build on FreeBSD 11 with libc++. OpenVSP does something like this: using namespace std; class array { ... }; Which causes the build to fail with HEAD's libc++. Even though the port d= oes not use -std=3Dc++11, libc++ still declares an array class that conflicts= with the one OpenVSP has. Enclose OpenVSP's array declaration in a namespace to avoid these conflic= ts. PR: 207253 Approved by: fernando.apesteguia@gmail.com (maintainer) Changes: head/cad/openvsp/files/patch-src_util__code_array.h head/cad/openvsp/files/patch-src_vsp_af.cpp head/cad/openvsp/files/patch-src_vsp_havoc__geom.cpp head/cad/openvsp/files/patch-src_vsp_havoc__geom.h --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Thu Feb 25 22:22:35 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A49E1AB425D for ; Thu, 25 Feb 2016 22:22:35 +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 mx1.freebsd.org (Postfix) with ESMTPS id 98B8EAA3 for ; Thu, 25 Feb 2016 22:22:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u1PMMZaJ004031 for ; Thu, 25 Feb 2016 22:22:35 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207253] cad/openvsp: Fix in 11-CURRENT Date: Thu, 25 Feb 2016 22:22:35 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: easy, patch, patch-ready X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rakuco@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: rakuco@FreeBSD.org X-Bugzilla-Flags: merge-quarterly? X-Bugzilla-Changed-Fields: assigned_to resolution bug_status 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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 22:22:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207253 Raphael Kubo da Costa changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-ports-bugs@FreeBSD. |rakuco@FreeBSD.org |org | Resolution|--- |FIXED Status|Open |Closed --- Comment #20 from Raphael Kubo da Costa --- Landed, thanks! --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Fri Feb 26 09:36:14 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BE2EAAB56D8 for ; Fri, 26 Feb 2016 09:36: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 mx1.freebsd.org (Postfix) with ESMTPS id AF7B0799 for ; Fri, 26 Feb 2016 09:36:14 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u1Q9aDrr061799 for ; Fri, 26 Feb 2016 09:36:14 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207253] cad/openvsp: Fix in 11-CURRENT Date: Fri, 26 Feb 2016 09:36:14 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: easy, patch, patch-ready X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: theraven@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: rakuco@FreeBSD.org X-Bugzilla-Flags: merge-quarterly? X-Bugzilla-Changed-Fields: cc 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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 09:36:14 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207253 David Chisnall changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |theraven@FreeBSD.org --- Comment #21 from David Chisnall --- This patch looks more complicated than it needs to be. Wouldn't inserting: using ::array; Immediately after the definition of array work? Alternatively, changing the uses of array to ::array would also work without sticking array in a namespace. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Fri Feb 26 10:55:49 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AE2CDAB5B10 for ; Fri, 26 Feb 2016 10:55:49 +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 mx1.freebsd.org (Postfix) with ESMTPS id 9DF9811A7 for ; Fri, 26 Feb 2016 10:55:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u1QAtnEi066716 for ; Fri, 26 Feb 2016 10:55:49 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207253] cad/openvsp: Fix in 11-CURRENT Date: Fri, 26 Feb 2016 10:55:49 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: easy, patch, patch-ready X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rakuco@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: rakuco@FreeBSD.org X-Bugzilla-Flags: merge-quarterly? 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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 10:55:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207253 --- Comment #22 from Raphael Kubo da Costa --- (In reply to David Chisnall from comment #21) > This patch looks more complicated than it needs to be. Wouldn't insertin= g: >=20 > using ::array; >=20 > Immediately after the definition of array work? It doesn't seem to work: % cat foo.cc #include using namespace std; // Not doing that here doesn't help, as it can be done indirectly from another file included before this one. template struct array { array(T t); }; using ::array; template array::array(T t) {} % clang++ -c foo.cc foo.cc:9:1: error: unknown type name 'array' array::array(T t) {} ^ foo.cc:9:6: error: expected unqualified-id array::array(T t) {} ^ 2 errors generated. > Alternatively, changing the > uses of array to ::array would also work without sticking array in a > namespace. That solves the issue for users of the array class, but not for array.h its= elf (plus the same amount of lines would need to be changed be it to "::array" = or "openvsp_array". --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Fri Feb 26 11:01:20 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 75043AB5D81 for ; Fri, 26 Feb 2016 11:01:20 +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 mx1.freebsd.org (Postfix) with ESMTPS id 64C79146E for ; Fri, 26 Feb 2016 11:01:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u1QB1JsL097120 for ; Fri, 26 Feb 2016 11:01:20 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207253] cad/openvsp: Fix in 11-CURRENT Date: Fri, 26 Feb 2016 11:01:20 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: easy, patch, patch-ready X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: theraven@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: rakuco@FreeBSD.org X-Bugzilla-Flags: merge-quarterly? 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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 11:01:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207253 --- Comment #23 from David Chisnall --- I hadn't realised it had out-of-line definitions. These also need prefixing with ::. The following works, and restricts the changes to the declaration= of the template: #include using namespace std; template struct array { array(T t); }; using ::array; template ::array::array(T t) {} array x(1); --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Fri Feb 26 11:11:43 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F01AFAB4015 for ; Fri, 26 Feb 2016 11:11:43 +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 mx1.freebsd.org (Postfix) with ESMTPS id DF6691AE1 for ; Fri, 26 Feb 2016 11:11:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u1QBBhpm033161 for ; Fri, 26 Feb 2016 11:11:43 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207253] cad/openvsp: Fix in 11-CURRENT Date: Fri, 26 Feb 2016 11:11:43 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: easy, patch, patch-ready X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rakuco@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: rakuco@FreeBSD.org X-Bugzilla-Flags: merge-quarterly? 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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 11:11:44 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207253 --- Comment #24 from Raphael Kubo da Costa --- (In reply to David Chisnall from comment #23) > The following works It still doesn't work here (clang++ -c test.cc, no additional parameters): test.cc:11:1: error: unknown type name 'array' array x(1); ^ test.cc:11:6: error: expected unqualified-id array x(1); ^ 2 errors generated. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Fri Feb 26 11:13:43 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0291EAB40C1 for ; Fri, 26 Feb 2016 11:13:43 +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 mx1.freebsd.org (Postfix) with ESMTPS id E63421D18 for ; Fri, 26 Feb 2016 11:13:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u1QBDgPb037065 for ; Fri, 26 Feb 2016 11:13:42 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207253] cad/openvsp: Fix in 11-CURRENT Date: Fri, 26 Feb 2016 11:13:42 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: easy, patch, patch-ready X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: theraven@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: rakuco@FreeBSD.org X-Bugzilla-Flags: merge-quarterly? 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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 11:13:43 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207253 --- Comment #25 from David Chisnall --- Works for me: $ clang++ -c foo.cc $ clang++ -v FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 Target: x86_64-unknown-freebsd10.2 Thread model: posix Selected GCC installation: --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Fri Feb 26 11:15:04 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C06BAB4128 for ; Fri, 26 Feb 2016 11:15:04 +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 mx1.freebsd.org (Postfix) with ESMTPS id 7B8BD1D68 for ; Fri, 26 Feb 2016 11:15:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u1QBF46p039231 for ; Fri, 26 Feb 2016 11:15:04 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207253] cad/openvsp: Fix in 11-CURRENT Date: Fri, 26 Feb 2016 11:15:04 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: easy, patch, patch-ready X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rakuco@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: rakuco@FreeBSD.org X-Bugzilla-Flags: merge-quarterly? 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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 11:15:04 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207253 --- Comment #26 from Raphael Kubo da Costa --- Well, that's FreeBSD 10.2, where the port was already working. The problem = only happens in HEAD after a newer libc++ was imported. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Fri Feb 26 11:15:39 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E58D2AB4154 for ; Fri, 26 Feb 2016 11:15:39 +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 mx1.freebsd.org (Postfix) with ESMTPS id D4F5D1D99 for ; Fri, 26 Feb 2016 11:15:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u1QBFd06040365 for ; Fri, 26 Feb 2016 11:15:39 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207253] cad/openvsp: Fix in 11-CURRENT Date: Fri, 26 Feb 2016 11:15:39 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: easy, patch, patch-ready X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: fernando.apesteguia@gmail.com X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: rakuco@FreeBSD.org X-Bugzilla-Flags: merge-quarterly? 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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 11:15:40 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207253 --- Comment #27 from fernando.apesteguia@gmail.com --- (In reply to David Chisnall from comment #25) In 10.2 and below OpenVSP compiles without these modifications. It is in 11-CURRENT where it started to fail when we landed the new clang/libc++ --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Fri Feb 26 11:16:47 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E793CAB4206 for ; Fri, 26 Feb 2016 11:16:47 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-154.reflexion.net [208.70.211.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AB7151E4B for ; Fri, 26 Feb 2016 11:16:47 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17300 invoked from network); 26 Feb 2016 11:16:56 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 26 Feb 2016 11:16:56 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Fri, 26 Feb 2016 06:16:33 -0500 (EST) Received: (qmail 2864 invoked from network); 26 Feb 2016 11:16:33 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 26 Feb 2016 11:16:33 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 4BF141C43D2; Fri, 26 Feb 2016 03:16:38 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: r207471 submitted against devel/powerpc64-gcc for _Unwind_RaiseException's internal unbounded looping; matching up with 207359 against base system From: Mark Millard In-Reply-To: <38D884F8-0EB4-4F3E-9475-7465FE173D79@dsl-only.net> Date: Fri, 26 Feb 2016 03:16:38 -0800 Cc: Andreas Tobler , Konstantin Belousov , Baptiste Daroussin Content-Transfer-Encoding: quoted-printable Message-Id: <6B1B4F5B-659B-4142-8B16-283E572C25B1@dsl-only.net> References: <38D884F8-0EB4-4F3E-9475-7465FE173D79@dsl-only.net> To: FreeBSD PowerPC ML , FreeBSD Toolchain X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 11:16:48 -0000 [Top post for a new, level level detail tracking of the error. It may be = libgcc_s's .eh_frame handling instead of a comiler output problem after = all. Both 207471 and 207359 have this material now.] I state the relationship below from the point of view of what the = existing fde operations would need to do to be correct as they are. The = alternate is that the missing activity is missing operations in the list = instead of the activity being "inside" DW_CFA_remember_state and = DW_CFA_restore_state. The problem is that the DW_CFA_remember_state and later = DW_CFA_restore_state do not in fact restore the fs->cfa_offset (in this = case 128 as it was at the time of the DW_CFA_remember_state). dwarfdump shows in its notation that the DW_CFA_restore_state should = restore the "off cfa=3D128(r1)" status that was in place at the time of = the DW_CFA_remember_state. This makes sense for the code in question: = otherwise it would be wrong for the purpose. But = DW_CFA_remember_state/DW_CFA_restore_state do not save and restore the = cfa_offset (128 here). DW_CFA_remember_state only saves fs->regs. DW_CFA_restore_state only restores fs->regs. fs->cfa_offset is not part of regs but is later used by = uw_update_context_1 for: /* Compute this frame's CFA. */ switch (fs->cfa_how) { case CFA_REG_OFFSET: cfa =3D _Unwind_GetPtr (&orig_context, fs->cfa_reg); cfa +=3D fs->cfa_offset; break; . . . context->cfa =3D cfa; In the example fs->cfa_offset ends up being 0 instead of 128 after the = DW_CFA_restore_state, causing the wrong frame's return address to be = used. For reference: The below is the dwarfdump -v -v -F for throw_exception = (where the "stuck" return address vale problem [0x000153a0] is = observed): < 0><0x00015310:0x000153dc> 0x00015310: =20 0x00015318: =20 0x00015324: =20 0x00015368: =20 0x00015378: =20 0x00015380: =20 0x000153a8: =20 0x000153b8: =20 0x000153c0: =20 fde section offset 4312 0x000010d8 cie offset for fde: 4316 0x000010dc 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 35 DW_CFA_nop 36 DW_CFA_nop 37 DW_CFA_nop 38 DW_CFA_nop Note that if fs->cfa_reg could be varying then DW_CFA_remember_state and = DW_CFA_restore_state would need to do appropriate save/restore activity = for that too. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-24, at 8:46 PM, Mark Millard wrote: > #include >=20 > int main(void) > { > try { throw std::exception(); } > catch (std::exception& e) {} // same result without & > return 0; > } compiled under devel/powerpc64-gcc (gcc 5.3 based) on a FreeBSD = projects/clang380-import (-r295902, for example) that was also built = (buildworld/buildkernel) with the same devel/powerpc64-gcc demonstrates: _Unwind_RaiseException never returns because it is stuck in a unbounded = loop. [clang380-import vs. 11.0-CURRENT is not likely to be a big distinction = here. PowerPC64 might be or might not be relative to g++ 5.3 .] The cause has been tracked down to incomplete (and so inaccurate) = .eh_frame information as shown below. I use a mix of . . . # /usr/local/bin/objdump -d --prefix-addresses libcxxrt.so.1.full output and the matching . . . # dwarfdump -v -v -F libcxxrt.so.1.full | more output to show this. 0000000000015350 <.__cxa_end_catch+0x490> addi r3,r31,88 0000000000015354 <.__cxa_end_catch+0x494> addi r10,r10,1 0000000000015358 <.__cxa_end_catch+0x498> stw r10,48(r9) 000000000001535c <.__cxa_end_catch+0x49c> bl 0000000000009ae0 = <00000017.plt_call._Unwind_RaiseException@@GCC_3.0> 0000000000015360 <.__cxa_end_catch+0x4a0> ld r2,40(r1) 0000000000015364 <.__cxa_end_catch+0x4a4> addi r1,r1,128 0000000000015368 <.__cxa_end_catch+0x4a8> mr r4,r31 vs. < 0><0x00015050:0x00015310> 0x00015050: =20 0x0001506c: =20 0x000150b8: =20 0x000150d0: =20 0x000150e0: =20 Of note here is that the return "address" from the bl context is = correctly identified as 0000000000015360 by the .eh_frame information = and its interpretation. But also of note there is that 0000000000015360 and 0000000000015364 = also are identified as having 0000000000015360 as their return address = (part of the same block of code as the bl as things are classified = above). (That is what the live code actually generates, up to relocation = issues changing addresses.) So when _Unwind_RaiseException attempts to walk up the stack from itself = for the first pass up the stack it gets to 0000000000015360. And from there it gets to 0000000000015360 and loops. And from there it gets to 0000000000015360 and loops. And from there it gets to 0000000000015360 and loops. And from there it gets to 0000000000015360 and loops. . . . This code/.eh_frame pattern occurs again a little later (and this is = where the original problem was observed for this low-level-detail view). = . . 0000000000015380 <.__cxa_end_catch+0x4c0> addis r8,r2,-1 0000000000015384 <.__cxa_end_catch+0x4c4> addi r3,r31,88 0000000000015388 <.__cxa_end_catch+0x4c8> ld r10,28144(r8) 000000000001538c <.__cxa_end_catch+0x4cc> std r10,32(r31) 0000000000015390 <.__cxa_end_catch+0x4d0> lwz r10,48(r9) 0000000000015394 <.__cxa_end_catch+0x4d4> addi r10,r10,1 0000000000015398 <.__cxa_end_catch+0x4d8> stw r10,48(r9) 000000000001539c <.__cxa_end_catch+0x4dc> bl 0000000000009ae0 = <00000017.plt_call._Unwind_RaiseException@@GCC_3.0> 00000000000153a0 <.__cxa_end_catch+0x4e0> ld r2,40(r1) 00000000000153a4 <.__cxa_end_catch+0x4e4> addi r1,r1,128 00000000000153a8 <.__cxa_end_catch+0x4e8> mr r4,r31 00000000000153ac <.__cxa_end_catch+0x4ec> ld r0,16(r1) vs. < 0><0x00015310:0x000153dc> 0x00015310: =20 0x00015318: =20 0x00015324: =20 0x00015368: =20 0x00015378: =20 0x00015380: =20 0x000153a8: =20 0x000153b8: =20 0x000153c0: =20 This leads to (during _Unwind_RaiseException's loop): . . . And from there it gets to 00000000000153a0 and loops. And from there it gets to 00000000000153a0 and loops. And from there it gets to 00000000000153a0 and loops. And from there it gets to 00000000000153a0 and loops. . . . 0000000000015360 and 00000000000153a0 should each be starts of new = code-block ranges for identifying a different return address. So C++ exception handling is broken for FreeBSD when buildworld is based = on devel/powerpc65-gcc: libcxxrt has examples of the error in it. I'd expect that gcc5 (5.3) has other contexts where it does not get the = correct return address via its .eh_frame generated materials, at least = for powerpc64. [207359 might be considered replaced by 207471.] =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Fri Feb 26 11:17:23 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 35DA9AB4290 for ; Fri, 26 Feb 2016 11:17:23 +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 mx1.freebsd.org (Postfix) with ESMTPS id 253F91EB9 for ; Fri, 26 Feb 2016 11:17:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u1QBHNTG042918 for ; Fri, 26 Feb 2016 11:17:23 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207253] cad/openvsp: Fix in 11-CURRENT Date: Fri, 26 Feb 2016 11:17:23 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: easy, patch, patch-ready X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: theraven@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: rakuco@FreeBSD.org X-Bugzilla-Flags: merge-quarterly? 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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 11:17:23 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207253 --- Comment #28 from David Chisnall --- Ah, I see. It would have helped if your reduced test case had used #include instead of #include . --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Fri Feb 26 11:20:42 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B8B27AB44C2 for ; Fri, 26 Feb 2016 11:20:42 +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 mx1.freebsd.org (Postfix) with ESMTPS id A7C5E1FF2 for ; Fri, 26 Feb 2016 11:20:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u1QBKgbT048058 for ; Fri, 26 Feb 2016 11:20:42 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207253] cad/openvsp: Fix in 11-CURRENT Date: Fri, 26 Feb 2016 11:20:42 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: easy, patch, patch-ready X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rakuco@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: rakuco@FreeBSD.org X-Bugzilla-Flags: merge-quarterly? 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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 11:20:42 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207253 --- Comment #29 from Raphael Kubo da Costa --- I avoided using because it does't exist before C++11, and this port= is not built with -std=3Dc++11. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Fri Feb 26 13:25:41 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C12BAB418F for ; Fri, 26 Feb 2016 13:25:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-154.reflexion.net [208.70.211.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DCED511F0 for ; Fri, 26 Feb 2016 13:25:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14212 invoked from network); 26 Feb 2016 13:25:37 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 26 Feb 2016 13:25:37 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Fri, 26 Feb 2016 08:25:42 -0500 (EST) Received: (qmail 25529 invoked from network); 26 Feb 2016 13:25:42 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 26 Feb 2016 13:25:42 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id D04FA1C43BC; Fri, 26 Feb 2016 05:25:36 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: r207471 submitted against devel/powerpc64-gcc for _Unwind_RaiseException's internal unbounded looping; matching up with 207359 against base system From: Mark Millard In-Reply-To: <6B1B4F5B-659B-4142-8B16-283E572C25B1@dsl-only.net> Date: Fri, 26 Feb 2016 05:25:37 -0800 Cc: Andreas Tobler , Konstantin Belousov , Baptiste Daroussin Content-Transfer-Encoding: quoted-printable Message-Id: References: <38D884F8-0EB4-4F3E-9475-7465FE173D79@dsl-only.net> <6B1B4F5B-659B-4142-8B16-283E572C25B1@dsl-only.net> To: FreeBSD PowerPC ML , FreeBSD Toolchain , Roman Divacky X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 13:25:41 -0000 On 2016-Feb-26, at 3:16 AM, Mark Millard wrote: >=20 > [Top post for a new, level level detail tracking of the error. It may = be libgcc_s's .eh_frame handling instead of a comiler output problem = after all. Both 207471 and 207359 have this material now.] >=20 > I state the relationship below from the point of view of what the = existing fde operations would need to do to be correct as they are. The = alternate is that the missing activity is missing operations in the list = instead of the activity being "inside" DW_CFA_remember_state and = DW_CFA_restore_state. >=20 > The problem is that the DW_CFA_remember_state and later = DW_CFA_restore_state do not in fact restore the fs->cfa_offset (in this = case 128 as it was at the time of the DW_CFA_remember_state). >=20 > dwarfdump shows in its notation that the DW_CFA_restore_state should = restore the "off cfa=3D128(r1)" status that was in place at the time of = the DW_CFA_remember_state. This makes sense for the code in question: = otherwise it would be wrong for the purpose. But = DW_CFA_remember_state/DW_CFA_restore_state do not save and restore the = cfa_offset (128 here). >=20 > DW_CFA_remember_state only saves fs->regs. > DW_CFA_restore_state only restores fs->regs. >=20 > fs->cfa_offset is not part of regs but is later used by = uw_update_context_1 for: >=20 > /* Compute this frame's CFA. */ > switch (fs->cfa_how) > { > case CFA_REG_OFFSET: > cfa =3D _Unwind_GetPtr (&orig_context, fs->cfa_reg); > cfa +=3D fs->cfa_offset; > break; > . . . > context->cfa =3D cfa; >=20 >=20 > In the example fs->cfa_offset ends up being 0 instead of 128 after the = DW_CFA_restore_state, causing the wrong frame's return address to be = used. >=20 > For reference: The below is the dwarfdump -v -v -F for throw_exception = (where the "stuck" return address vale problem [0x000153a0] is = observed): >=20 >=20 > < 0><0x00015310:0x000153dc> > 0x00015310: =20 > 0x00015318: =20 > 0x00015324: =20 > 0x00015368: =20 > 0x00015378: =20 > 0x00015380: =20 > 0x000153a8: =20 > 0x000153b8: =20 > 0x000153c0: =20 > fde section offset 4312 0x000010d8 cie offset for fde: 4316 0x000010dc > 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 > 35 DW_CFA_nop > 36 DW_CFA_nop > 37 DW_CFA_nop > 38 DW_CFA_nop >=20 >=20 > Note that if fs->cfa_reg could be varying then DW_CFA_remember_state = and DW_CFA_restore_state would need to do appropriate save/restore = activity for that too. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net I have verified that dwarfdump and its libdwarf do save and restore the = following for the cfa for DW_CFA_remember_state/DW_CFA_restore_state: A) If the offset is relevant or not (if it has a offset style rule) B) the rule-value type C) the register number that the cfa is based on D) the offset or block length by naming conventions E) the block pointer I do not claim that all that applies to the mostly dwarf2 FreeBSD = context. But I expect that (A)-(D) apply, (D) just for the offset case. I do not expect this issue to be strictly TARGET_ARCH=3Dpowerpc64 (or = powerpc): This is a very general property of = DW_CFA_remember_state/DW_CFA_restore_state use for .eh_frame that just = depends on code generation accidental-details for if it will be touched = or not. I've also found that the working simple examples [g++ 4.9, 5.3, 6.0(?) = using their own libraries] happen to leave the CFA =3D OFFSET(r1) with a = constant OFFSET over the throw routine (from libstdc++) that calls = _Unwind_RaiseException. So even if their libgcc_s's have the incomplete = save/restore problem those throw routines do not happen to get code that = touches the problem. But I did find other examples in libstdc++ that did not have the CFA's = involved OFFSET constant over whole routines. Detailed "accidents" of = inlining and other code generation issues lead to such being involved in = places. These code generators can also generate examples of the issue. And, of course, devel/powerpc64-gcc has a g++ 5.3 vintage but is used = with the system's libgcc_s and that combination has the problem in the = throw code's use of _Unwind_RaiseException and attempting to unwind back = out of _Unwind_RaiseException. I conclude that FreeBSD's libgcc_s libraries' .eh_frame handling is = insufficient for general C++ exception handling, be it via g++ vintages = or, probably, clang++ as well. It takes some luck to avoid the problems. = Turing off in-lining, using -O0, and the like would probably make the = problems less likely. FreeBSD's libgcc_s may not be the only example of the problem. I have included the older note below for reference, but with the = mistaken analysis details omitted. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-24, at 8:46 PM, Mark Millard wrote: > #include >=20 > int main(void) > { > try { throw std::exception(); } > catch (std::exception& e) {} // same result without & > return 0; > } >=20 > compiled under devel/powerpc64-gcc (gcc 5.3 based) on a FreeBSD = projects/clang380-import (-r295902, for example) that was also built = (buildworld/buildkernel) with the same devel/powerpc64-gcc demonstrates: >=20 > _Unwind_RaiseException never returns because it is stuck in a = unbounded loop. >=20 > [clang380-import vs. 11.0-CURRENT is not likely to be a big = distinction here. PowerPC64 might be or might not be relative to g++ 5.3 = .] >=20 >=20 > [. . .] >=20 > I use a mix of . . . >=20 > # /usr/local/bin/objdump -d --prefix-addresses libcxxrt.so.1.full >=20 > output and the matching . . . >=20 > # dwarfdump -v -v -F libcxxrt.so.1.full | more >=20 > output to show this. >=20 > 0000000000015350 <.__cxa_end_catch+0x490> addi r3,r31,88 > 0000000000015354 <.__cxa_end_catch+0x494> addi r10,r10,1 > 0000000000015358 <.__cxa_end_catch+0x498> stw r10,48(r9) > 000000000001535c <.__cxa_end_catch+0x49c> bl 0000000000009ae0 = <00000017.plt_call._Unwind_RaiseException@@GCC_3.0> > 0000000000015360 <.__cxa_end_catch+0x4a0> ld r2,40(r1) > 0000000000015364 <.__cxa_end_catch+0x4a4> addi r1,r1,128 > 0000000000015368 <.__cxa_end_catch+0x4a8> mr r4,r31 > vs. > < 0><0x00015050:0x00015310> > 0x00015050: =20 > 0x0001506c: =20 > 0x000150b8: =20 > 0x000150d0: =20 > 0x000150e0: =20 >=20 > [. . .] >=20 > So when _Unwind_RaiseException attempts to walk up the stack from = itself for the first pass up the stack it gets to 0000000000015360. >=20 > And from there it gets to 0000000000015360 and loops. > And from there it gets to 0000000000015360 and loops. > And from there it gets to 0000000000015360 and loops. > And from there it gets to 0000000000015360 and loops. > . . . >=20 > This code/.eh_frame pattern occurs again a little later (and this is = where the original problem was observed for this low-level-detail view). = . . >=20 > 0000000000015380 <.__cxa_end_catch+0x4c0> addis r8,r2,-1 > 0000000000015384 <.__cxa_end_catch+0x4c4> addi r3,r31,88 > 0000000000015388 <.__cxa_end_catch+0x4c8> ld r10,28144(r8) > 000000000001538c <.__cxa_end_catch+0x4cc> std r10,32(r31) > 0000000000015390 <.__cxa_end_catch+0x4d0> lwz r10,48(r9) > 0000000000015394 <.__cxa_end_catch+0x4d4> addi r10,r10,1 > 0000000000015398 <.__cxa_end_catch+0x4d8> stw r10,48(r9) > 000000000001539c <.__cxa_end_catch+0x4dc> bl 0000000000009ae0 = <00000017.plt_call._Unwind_RaiseException@@GCC_3.0> > 00000000000153a0 <.__cxa_end_catch+0x4e0> ld r2,40(r1) > 00000000000153a4 <.__cxa_end_catch+0x4e4> addi r1,r1,128 > 00000000000153a8 <.__cxa_end_catch+0x4e8> mr r4,r31 > 00000000000153ac <.__cxa_end_catch+0x4ec> ld r0,16(r1) > vs. > < 0><0x00015310:0x000153dc> > 0x00015310: =20 > 0x00015318: =20 > 0x00015324: =20 > 0x00015368: =20 > 0x00015378: =20 > 0x00015380: =20 > 0x000153a8: =20 > 0x000153b8: =20 > 0x000153c0: =20 >=20 > This leads to (during _Unwind_RaiseException's loop): >=20 > . . . > And from there it gets to 00000000000153a0 and loops. > And from there it gets to 00000000000153a0 and loops. > And from there it gets to 00000000000153a0 and loops. > And from there it gets to 00000000000153a0 and loops. > . . . >=20 >=20 > [. . .] =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Fri Feb 26 23:26:48 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B8D33AB5BBB for ; Fri, 26 Feb 2016 23:26:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-156.reflexion.net [208.70.211.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7DAC8327 for ; Fri, 26 Feb 2016 23:26:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 18301 invoked from network); 26 Feb 2016 23:26:58 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 26 Feb 2016 23:26:58 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Fri, 26 Feb 2016 18:26:45 -0500 (EST) Received: (qmail 22553 invoked from network); 26 Feb 2016 23:26:44 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 26 Feb 2016 23:26:44 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 883031C43C4; Fri, 26 Feb 2016 15:26:36 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: clang 3.8.0 can generate inaccurate .eh_frame information, at least for TARGET_ARCH=powerpc: a bug 207325 update From: Mark Millard In-Reply-To: <83B8741C-B4C9-4EFB-A3B4-473F8F165984@dsl-only.net> Date: Fri, 26 Feb 2016 15:26:40 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <80EA4460-E842-46F5-B006-2A83FBBEE845@dsl-only.net> References: <83B8741C-B4C9-4EFB-A3B4-473F8F165984@dsl-only.net> To: FreeBSD PowerPC ML , FreeBSD Toolchain , Roman Divacky , Dimitry Andric X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 23:26:48 -0000 On 2016-Feb-19, at 11:37 AM, Mark Millard wrote: > The following program does not work for my example TARGET_ARCH=3Dpowerpc= and TARGET_ARCH=3Dpowerpc64 environments for buildworld based on = projects/clang380-import -r205601: >=20 > #include >=20 > int main(void) > { > try { throw std::exception(); } > catch (std::exception& e) {} // same result without & > return 0; > } >=20 > The details vary for what happens and what compiler is in use. >=20 > TARGET_ARCH=3Dpowerpc with clang 3.8.0: SEGV >=20 > TARGET_ARCH=3Dpowerpc64 with devel/powerpc64-gcc: unbouded loop in = _Unwind_RaiseException >=20 > For the powerpc64 context: g++49 can be used to show the problem as = well: >=20 > Using g++49's a.out gets the same unbounded loop result for: >=20 > # g++49 -I /usr/include/c++/v1/ -L /usr/lib/ -g -Wall -pedantic = exception_test.cpp = =20 >=20 > But the a.out works fine for a normal g++49 header/library usage: >=20 > # g++49 -g -Wall -pedantic exception_test.cpp > # ./a.out > #=20 >=20 >=20 >=20 > (These were noticed by trying to build and use kyua to run the = /usr/tests material in tehse enviroments.) >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net [Note: The _Unwind_RaiseException involved below was compiled by clang = 3.8.0 during buildworld. So clang generated the .eh_frame information = involved.] In the TARGET_ARCH=3Dpowerpc operation there are a sequence of 2 errors, = the 2nd of which gets the SEGV: A) The catch clause is rejected/ignored so std::terminate is called B) During the std::terminate related execution the SEGV happens. (A) is the more fundamental issue. I have found the following mismatch between some powerpc code generated = and the .eh_frame information generated by clang 3.8.0 for the = TARGET_ARCH=3Dpowerpc context. (Using objdump and dwarfdump notation = below, no relocations.) The specific example need not be directly = involved in (A) or (B) but is inaccurate .eh_frame generation either = way. > 00007fd8 <_Unwind_RaiseException> mflr r0 > 00007fdc <_Unwind_RaiseException+0x4> stw r31,-148(r1) > 00007fe0 <_Unwind_RaiseException+0x8> stw r30,-152(r1) > 00007fe4 <_Unwind_RaiseException+0xc> stw r0,4(r1) > 00007fe8 <_Unwind_RaiseException+0x10> stwu r1,-2992(r1) > 00007fec <_Unwind_RaiseException+0x14> mr r31,r1 > 00007ff0 <_Unwind_RaiseException+0x18> mfcr r12 > . . . > 0000827c <_Unwind_RaiseException+0x2a4> lwz r14,2776(r31) > 00008280 <_Unwind_RaiseException+0x2a8> addi r1,r1,2992 > 00008284 <_Unwind_RaiseException+0x2ac> lwz r0,4(r1) > 00008288 <_Unwind_RaiseException+0x2b0> lwz r31,-148(r1) > 0000828c <_Unwind_RaiseException+0x2b4> lwz r30,-152(r1) > 00008290 <_Unwind_RaiseException+0x2b8> mtlr r0 > 00008294 <_Unwind_RaiseException+0x2bc> blr > 00008298 <_Unwind_RaiseException+0x2c0> bl 0001eccc The .eh_frame information shown by dwarfdump (see later below) shows off = cfa=3D2992(r31) over the range starting at 0x00007ff0 but 0x828c to = 0x8298 comes after R31 is returned to its old value. (The range goes up = to 0x0000829c, which is the start of the next block of addresses.) is just wrong at 0000828c and later above. (I'm not going to make claims here about 0x00007ff0 below listing both = and or how such is = handled. But it would seem that cfa=3D?(r31)'s interpretation would need = to ignore any prior or same line r31=3D?(cfa). Either way it is = generally wrong once cfa itself is inaccurate, as it is at 0000828c.) The dwarfdump -v -v -F material for this is: > < 0><0x00007fd8:0x0000829c><> > 0x00007fd8: =20 > 0x00007fec: =20 > 0x00007ff0: =20 > fde section offset 692 0x000002b4 cie offset for fde: 696 0x000002b8 > 0 DW_CFA_advance_loc 20 (5 * 4) > 1 DW_CFA_def_cfa_offset 2992 > 4 DW_CFA_offset r31 -148 (37 * -4) > 6 DW_CFA_offset r30 -152 (38 * -4) > 8 DW_CFA_offset_extended_sf r65 4 (-1 * -4) > 11 DW_CFA_advance_loc 4 (1 * 4) > 12 DW_CFA_def_cfa_register r31 > 14 DW_CFA_offset r14 -216 (54 * -4) > 16 DW_CFA_offset r15 -212 (53 * -4) > 18 DW_CFA_offset r16 -208 (52 * -4) > 20 DW_CFA_offset r17 -204 (51 * -4) > 22 DW_CFA_offset r18 -200 (50 * -4) > 24 DW_CFA_offset r19 -196 (49 * -4) > 26 DW_CFA_offset r20 -192 (48 * -4) > 28 DW_CFA_offset r21 -188 (47 * -4) > 30 DW_CFA_offset r22 -184 (46 * -4) > 32 DW_CFA_offset r23 -180 (45 * -4) > 34 DW_CFA_offset r24 -176 (44 * -4) > 36 DW_CFA_offset r25 -172 (43 * -4) > 38 DW_CFA_offset r26 -168 (42 * -4) > 40 DW_CFA_offset r27 -164 (41 * -4) > 42 DW_CFA_offset r28 -160 (40 * -4) > 44 DW_CFA_offset r29 -156 (39 * -4) > 46 DW_CFA_offset r30 -152 (38 * -4) > 48 DW_CFA_offset r31 -148 (37 * -4) > 50 DW_CFA_offset r46 -144 (36 * -4) > 52 DW_CFA_offset r47 -136 (34 * -4) > 54 DW_CFA_offset r48 -128 (32 * -4) > 56 DW_CFA_offset r49 -120 (30 * -4) > 58 DW_CFA_offset r50 -112 (28 * -4) > 60 DW_CFA_offset r51 -104 (26 * -4) > 62 DW_CFA_offset r52 -96 (24 * -4) > 64 DW_CFA_offset r53 -88 (22 * -4) > 66 DW_CFA_offset r54 -80 (20 * -4) > 68 DW_CFA_offset r55 -72 (18 * -4) > 70 DW_CFA_offset r56 -64 (16 * -4) > 72 DW_CFA_offset r57 -56 (14 * -4) > 74 DW_CFA_offset r58 -48 (12 * -4) > 76 DW_CFA_offset r59 -40 (10 * -4) > 78 DW_CFA_offset r60 -32 (8 * -4) > 80 DW_CFA_offset r61 -24 (6 * -4) > 82 DW_CFA_offset r62 -16 (4 * -4) > 84 DW_CFA_offset r63 -8 (2 * -4) > 86 DW_CFA_nop =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sat Feb 27 10:30:19 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A8C73AB686E for ; Sat, 27 Feb 2016 10:30:19 +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 mx1.freebsd.org (Postfix) with ESMTPS id 991441517 for ; Sat, 27 Feb 2016 10:30:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u1RAUJDu077132 for ; Sat, 27 Feb 2016 10:30:19 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207253] cad/openvsp: Fix in 11-CURRENT Date: Sat, 27 Feb 2016 10:30:19 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: easy, patch, patch-ready X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: fernando.apesteguia@gmail.com X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: rakuco@FreeBSD.org X-Bugzilla-Flags: merge-quarterly? 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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2016 10:30:19 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207253 --- Comment #30 from fernando.apesteguia@gmail.com --- (In reply to Raphael Kubo da Costa from comment #29) I reported the problem upstream. At least to me, the response was a bit unexpected: libc++ doesn't support compiling c++98 programs that don't comp= ile also as c++11 programs: https://llvm.org/bugs/show_bug.cgi?id=3D26754 Than means that the any legacy program using a type as array, forward_list = and probably a few more will clash with the ones in the std namespace for c++11= in libc++. At least, we should reflect this fact in the documentation: https://www.freebsd.org/doc/en/books/porters-handbook/book.html#uses-compil= er and maybe add a new knob in "USES=3D compiler:..." for cases like this. Apparently GNU's C++ library is doing the right thing: they don't let c++11 names leak into std namespace unless c++11 standard is explicitly specified. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Feb 27 23:32:08 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EA816AB63B7 for ; Sat, 27 Feb 2016 23:32:07 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-157.reflexion.net [208.70.211.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AA4A114CD for ; Sat, 27 Feb 2016 23:32:07 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 11844 invoked from network); 27 Feb 2016 23:32:16 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 27 Feb 2016 23:32:16 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sat, 27 Feb 2016 18:31:53 -0500 (EST) Received: (qmail 31457 invoked from network); 27 Feb 2016 23:31:53 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 27 Feb 2016 23:31:53 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 118DD1C43E0; Sat, 27 Feb 2016 15:31:55 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: clang 3.8.0 can mess up __builtin_dwarf_cfa (), at least for TARGET_ARCH=powerpc: a bug 207325 update From: Mark Millard In-Reply-To: <80EA4460-E842-46F5-B006-2A83FBBEE845@dsl-only.net> Date: Sat, 27 Feb 2016 15:31:58 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <83B8741C-B4C9-4EFB-A3B4-473F8F165984@dsl-only.net> <80EA4460-E842-46F5-B006-2A83FBBEE845@dsl-only.net> To: FreeBSD PowerPC ML , FreeBSD Toolchain , Roman Divacky , Dimitry Andric X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2016 23:32:08 -0000 [Top post for dinging the low level problem that directly breaks c++ = exception handling for TARGET_ARCH=3Dpowerpc for clang 3.8.0 generated = code.] I've tracked down the c++ exception problem for TARGET_ARCH=3Dpowerpc = via clang 3.8.0: misbehavior of clang 3.8.0 code generation for = __builtin_dwarf_cfa () as used in: #define uw_init_context(CONTEXT) = \ do = \ { = \ /* Do any necessary initialization to access arbitrary stack = frames. \ On the SPARC, this means flushing the register windows. */ = \ __builtin_unwind_init (); = \ uw_init_context_1 (CONTEXT, __builtin_dwarf_cfa (), = \ __builtin_return_address (0)); = \ } = \ while (0) . . . 85 _Unwind_Reason_Code 86 _Unwind_RaiseException(struct _Unwind_Exception *exc) 87 { 88 struct _Unwind_Context this_context, cur_context; 89 _Unwind_Reason_Code code; 90=09 91 /* Set up this_context to describe the current stack frame. = */ 92 uw_init_context (&this_context); In the below r4 ends up with the __builtin_dwarf_cfa () value supplied = to uw_init_context_1: Dump of assembler code for function _Unwind_RaiseException: 0x419a8fd8 <+0>: mflr r0 0x419a8fdc <+4>: stw r31,-148(r1) 0x419a8fe0 <+8>: stw r30,-152(r1) 0x419a8fe4 <+12>: stw r0,4(r1) 0x419a8fe8 <+16>: stwu r1,-2992(r1) 0x419a8fec <+20>: mr r31,r1 . . . 0x419a9094 <+188>: mr r4,r31 0x419a9098 <+192>: mflr r30 0x419a909c <+196>: lwz r5,2996(r31) 0x419a90a0 <+200>: mr r3,r28 0x419a90a4 <+204>: bl 0x419a929c That r4 ends up holding the stack pointer value for after it has been = decremented. r4 is not pointing at the boundary with the caller's frame. The .eh_frame information and unwind code is set up for pointing at the = boundary with the caller's frame. So the cfa relative addressing is = messed up for what it actually extracts. Contrast this with gcc/g++ 5.3's TARGET_ARCH=3Dpowerpc64 code where r4 = is made to be at the boundary with the caller's frame: Dump of assembler code for function _Unwind_RaiseException: 0x00000000501cb810 <+0>: mflr r0 0x00000000501cb814 <+4>: stdu r1,-5648(r1) . . . 0x00000000501cb8d0 <+192>: addi r4,r1,5648 0x00000000501cb8d4 <+196>: stw r12,5656(r1) 0x00000000501cb8d8 <+200>: mr r28,r3 0x00000000501cb8dc <+204>: addi r31,r1,2544 0x00000000501cb8e0 <+208>: mr r3,r27 0x00000000501cb8e4 <+212>: addi r29,r1,112 0x00000000501cb8e8 <+216>: bl 0x501cae60 NOTE: The powerpc (32-bit) issue may in some way be associated with the = clang 3.8.0 powerpc ABI violation in how it handles the stack pointer = for FreeBSD: TARGET_ARCH=3Dpowerpc is currently using a "red zone", = decrementing the stack pointer late, and incrementing the stack pointer = early compared to the FreeBSD ABI rules. (This is similar to the = official FreeBSD ABI for TARGET_ARCH=3Dpowerpc64.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-26, at 3:26 PM, Mark Millard wrote: >=20 > On 2016-Feb-19, at 11:37 AM, Mark Millard = wrote: >=20 >> The following program does not work for my example = TARGET_ARCH=3Dpowerpc and TARGET_ARCH=3Dpowerpc64 environments for = buildworld based on projects/clang380-import -r205601: >>=20 >> #include >>=20 >> int main(void) >> { >> try { throw std::exception(); } >> catch (std::exception& e) {} // same result without & >> return 0; >> } >>=20 >> The details vary for what happens and what compiler is in use. >>=20 >> TARGET_ARCH=3Dpowerpc with clang 3.8.0: SEGV >>=20 >> TARGET_ARCH=3Dpowerpc64 with devel/powerpc64-gcc: unbouded loop in = _Unwind_RaiseException >>=20 >> For the powerpc64 context: g++49 can be used to show the problem as = well: >>=20 >> Using g++49's a.out gets the same unbounded loop result for: >>=20 >> # g++49 -I /usr/include/c++/v1/ -L /usr/lib/ -g -Wall -pedantic = exception_test.cpp = =20 >>=20 >> But the a.out works fine for a normal g++49 header/library usage: >>=20 >> # g++49 -g -Wall -pedantic exception_test.cpp >> # ./a.out >> #=20 >>=20 >>=20 >>=20 >> (These were noticed by trying to build and use kyua to run the = /usr/tests material in tehse enviroments.) >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >=20 > [Note: The _Unwind_RaiseException involved below was compiled by clang = 3.8.0 during buildworld. So clang generated the .eh_frame information = involved.] >=20 > In the TARGET_ARCH=3Dpowerpc operation there are a sequence of 2 = errors, the 2nd of which gets the SEGV: >=20 > A) The catch clause is rejected/ignored so std::terminate is called >=20 > B) During the std::terminate related execution the SEGV happens. >=20 > (A) is the more fundamental issue. >=20 > I have found the following mismatch between some powerpc code = generated and the .eh_frame information generated by clang 3.8.0 for the = TARGET_ARCH=3Dpowerpc context. (Using objdump and dwarfdump notation = below, no relocations.) The specific example need not be directly = involved in (A) or (B) but is inaccurate .eh_frame generation either = way. >=20 >> 00007fd8 <_Unwind_RaiseException> mflr r0 >> 00007fdc <_Unwind_RaiseException+0x4> stw r31,-148(r1) >> 00007fe0 <_Unwind_RaiseException+0x8> stw r30,-152(r1) >> 00007fe4 <_Unwind_RaiseException+0xc> stw r0,4(r1) >> 00007fe8 <_Unwind_RaiseException+0x10> stwu r1,-2992(r1) >> 00007fec <_Unwind_RaiseException+0x14> mr r31,r1 >> 00007ff0 <_Unwind_RaiseException+0x18> mfcr r12 >> . . . >> 0000827c <_Unwind_RaiseException+0x2a4> lwz r14,2776(r31) >> 00008280 <_Unwind_RaiseException+0x2a8> addi r1,r1,2992 >> 00008284 <_Unwind_RaiseException+0x2ac> lwz r0,4(r1) >> 00008288 <_Unwind_RaiseException+0x2b0> lwz r31,-148(r1) >> 0000828c <_Unwind_RaiseException+0x2b4> lwz r30,-152(r1) >> 00008290 <_Unwind_RaiseException+0x2b8> mtlr r0 >> 00008294 <_Unwind_RaiseException+0x2bc> blr >> 00008298 <_Unwind_RaiseException+0x2c0> bl 0001eccc >=20 > The .eh_frame information shown by dwarfdump (see later below) shows = off cfa=3D2992(r31) over the range starting at 0x00007ff0 but 0x828c to = 0x8298 comes after R31 is returned to its old value. (The range goes up = to 0x0000829c, which is the start of the next block of addresses.) >=20 > is just wrong at 0000828c and later above. >=20 > (I'm not going to make claims here about 0x00007ff0 below listing both = and or how such is = handled. But it would seem that cfa=3D?(r31)'s interpretation would need = to ignore any prior or same line r31=3D?(cfa). Either way it is = generally wrong once cfa itself is inaccurate, as it is at 0000828c.) >=20 > The dwarfdump -v -v -F material for this is: >=20 >> < 0><0x00007fd8:0x0000829c><> >> 0x00007fd8: =20 >> 0x00007fec: =20 >> 0x00007ff0: =20 >> fde section offset 692 0x000002b4 cie offset for fde: 696 0x000002b8 >> 0 DW_CFA_advance_loc 20 (5 * 4) >> 1 DW_CFA_def_cfa_offset 2992 >> 4 DW_CFA_offset r31 -148 (37 * -4) >> 6 DW_CFA_offset r30 -152 (38 * -4) >> 8 DW_CFA_offset_extended_sf r65 4 (-1 * -4) >> 11 DW_CFA_advance_loc 4 (1 * 4) >> 12 DW_CFA_def_cfa_register r31 >> 14 DW_CFA_offset r14 -216 (54 * -4) >> 16 DW_CFA_offset r15 -212 (53 * -4) >> 18 DW_CFA_offset r16 -208 (52 * -4) >> 20 DW_CFA_offset r17 -204 (51 * -4) >> 22 DW_CFA_offset r18 -200 (50 * -4) >> 24 DW_CFA_offset r19 -196 (49 * -4) >> 26 DW_CFA_offset r20 -192 (48 * -4) >> 28 DW_CFA_offset r21 -188 (47 * -4) >> 30 DW_CFA_offset r22 -184 (46 * -4) >> 32 DW_CFA_offset r23 -180 (45 * -4) >> 34 DW_CFA_offset r24 -176 (44 * -4) >> 36 DW_CFA_offset r25 -172 (43 * -4) >> 38 DW_CFA_offset r26 -168 (42 * -4) >> 40 DW_CFA_offset r27 -164 (41 * -4) >> 42 DW_CFA_offset r28 -160 (40 * -4) >> 44 DW_CFA_offset r29 -156 (39 * -4) >> 46 DW_CFA_offset r30 -152 (38 * -4) >> 48 DW_CFA_offset r31 -148 (37 * -4) >> 50 DW_CFA_offset r46 -144 (36 * -4) >> 52 DW_CFA_offset r47 -136 (34 * -4) >> 54 DW_CFA_offset r48 -128 (32 * -4) >> 56 DW_CFA_offset r49 -120 (30 * -4) >> 58 DW_CFA_offset r50 -112 (28 * -4) >> 60 DW_CFA_offset r51 -104 (26 * -4) >> 62 DW_CFA_offset r52 -96 (24 * -4) >> 64 DW_CFA_offset r53 -88 (22 * -4) >> 66 DW_CFA_offset r54 -80 (20 * -4) >> 68 DW_CFA_offset r55 -72 (18 * -4) >> 70 DW_CFA_offset r56 -64 (16 * -4) >> 72 DW_CFA_offset r57 -56 (14 * -4) >> 74 DW_CFA_offset r58 -48 (12 * -4) >> 76 DW_CFA_offset r59 -40 (10 * -4) >> 78 DW_CFA_offset r60 -32 (8 * -4) >> 80 DW_CFA_offset r61 -24 (6 * -4) >> 82 DW_CFA_offset r62 -16 (4 * -4) >> 84 DW_CFA_offset r63 -8 (2 * -4) >> 86 DW_CFA_nop >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 >=20