From owner-freebsd-ppc@freebsd.org Sun Feb 21 00:17:36 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BB13CAA783F for ; Sun, 21 Feb 2016 00:17:36 +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 71A951C5C for ; Sun, 21 Feb 2016 00:17:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 13621 invoked from network); 21 Feb 2016 00:17:49 -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:49 -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-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 00:17:36 -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-ppc@freebsd.org Sun Feb 21 09:04:31 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 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-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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-ppc@freebsd.org Sun Feb 21 11:52:46 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 04D0BAAF5D3 for ; Sun, 21 Feb 2016 11:52:46 +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 BD8B61F30 for ; Sun, 21 Feb 2016 11:52:44 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 20407 invoked from network); 21 Feb 2016 11:52:44 -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:44 -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-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 11:52:46 -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-ppc@freebsd.org Mon Feb 22 07:10:32 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CBF66AAFE9C for ; Mon, 22 Feb 2016 07:10:32 +0000 (UTC) (envelope-from cbutler1@a2plcpnl0075.prod.iad2.secureserver.net) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id B075B10CC for ; Mon, 22 Feb 2016 07:10:32 +0000 (UTC) (envelope-from cbutler1@a2plcpnl0075.prod.iad2.secureserver.net) Received: by freefall.freebsd.org (Postfix) id AF9D51B89; Mon, 22 Feb 2016 07:10:32 +0000 (UTC) Delivered-To: freebsd-powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by freefall.freebsd.org (Postfix) with ESMTP id 95E5E1B85 for ; Mon, 22 Feb 2016 07:10:32 +0000 (UTC) (envelope-from cbutler1@a2plcpnl0075.prod.iad2.secureserver.net) Received: from a2nlsmtp01-03.prod.iad2.secureserver.net (a2nlsmtp01-03.prod.iad2.secureserver.net [198.71.225.37]) (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 5A1E910CB for ; Mon, 22 Feb 2016 07:10:28 +0000 (UTC) (envelope-from cbutler1@a2plcpnl0075.prod.iad2.secureserver.net) Received: from a2plcpnl0075.prod.iad2.secureserver.net ([198.71.226.11]) by : HOSTING RELAY : with SMTP id XkdWau9jQKFAAXkdWatmMJ; Mon, 22 Feb 2016 00:10:26 -0700 Received: from cbutler1 by a2plcpnl0075.prod.iad2.secureserver.net with local (Exim 4.85) (envelope-from ) id 1aXkdW-001s2p-Jb for freebsd-powerpc@freebsd.org; Mon, 22 Feb 2016 00:10:26 -0700 To: freebsd-powerpc@freebsd.org Subject: Unable to deliver your item, #00469023 X-PHP-Script: courtneybutler.com/post.php for 206.130.98.3 Date: Mon, 22 Feb 2016 07:10:26 +0000 From: "FedEx International Ground" Reply-To: "FedEx International Ground" Message-ID: X-Priority: 3 MIME-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - a2plcpnl0075.prod.iad2.secureserver.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [1356868 964] / [47 12] X-AntiAbuse: Sender Address Domain - a2plcpnl0075.prod.iad2.secureserver.net X-Get-Message-Sender-Via: a2plcpnl0075.prod.iad2.secureserver.net: authenticated_id: cbutler1/from_h X-Source: X-Source-Args: /usr/sbin/proxyexec -q -d -s /var/lib/proxyexec/cagefs.sock/socket /bin/cagefs.server X-Source-Dir: courtneybutler.com:/public_html X-CMAE-Envelope: MS4wfPV/wwS98ySJgZNl+UqsS4N/HEI09kU5Syu0e6rN2tTsYLhxoBRYtZxeDT9fWFq8tirJHgbc95qo9LJGkn+o5XytLhOAiP2nUUvgwM2V86G98UBgSEPg ApUUANvPhQaYg0KhvLU7EDxSVUjz55sB+Kp+qUvO48uqn8juvOmOLcacF6n6hLZLsTLYfBgRe6Z+M815y0evfO/KRza8KCwU7xMMJJAmMMsZ2KMbKKMX4M8T Q4gvPZCnkxSB2r4Xdm/2og== Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 07:10:32 -0000 Dear Customer, This is to confirm that one or more of your parcels has been shipped. You can review complete details of your order in the find attached. Sincerely, Elmer White, Delivery Agent. From owner-freebsd-ppc@freebsd.org Tue Feb 23 04:15:10 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8412DAB13A2 for ; Tue, 23 Feb 2016 04:15:10 +0000 (UTC) (envelope-from hamiltcl@verizon.net) Received: from vms173015pub.verizon.net (vms173015pub.verizon.net [206.46.173.15]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5FA131FE5; Tue, 23 Feb 2016 04:15:09 +0000 (UTC) (envelope-from hamiltcl@verizon.net) Received: from vz-proxy-l004.mx.aol.com ([64.236.82.156]) by vms173015.mailsrvcs.net (Oracle Communications Messaging Server 7.0.5.32.0 64bit (built Jul 16 2014)) with ESMTPA id <0O2Z00AQPD057Q80@vms173015.mailsrvcs.net>; Mon, 22 Feb 2016 21:14:30 -0600 (CST) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=MtGvkDue c=1 sm=1 tr=0 a=+uvv0eFg1RZMRlvXuTpPbQ==:117 a=kj9zAlcOel0A:10 a=jFJIQSaiL_oA:10 a=1XWaLZrsAAAA:8 a=GZWvyUS8Il_tkhNpMkYA:9 a=CjuIK1q_8ugA:10 Received: by 96.255.168.17 with SMTP id 7e8d7842; Tue, 23 Feb 2016 03:14:29 GMT From: "Curtis Hamilton" To: "'Andreas Tobler'" , "'Steve Wills'" , "'Justin Hibbits'" Cc: "'FreeBSD PowerPC ML'" Subject: Native OpenJDK8 for PowerPC64 Date: Mon, 22 Feb 2016 22:14:25 -0500 Message-id: <005e01d16de8$4d06da30$e7148e90$@verizon.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-index: AdFt4ccyDc05UYarSK2uvEKCHeUHyw== Content-language: en-us X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 04:15:10 -0000 Testers Wanted! I looking for anyone who is interested in a native OpenJDK8 (Mixed mode) for PowerPC64. I been successful in modifying the AIX/Linux PPC code and build a native (non-zero) JDK8 on FreeBSD PowerPC64. To validate the build, I made a couple of regression test runs with results similar to what I got for the Zero VM build. However, performance is a magnitude better than the Zero VM and I've used it to run several heavy duty apps, like NetBeans, IntelliJ IdeaC, without crashes or core dumps. I've actually used it to build itself. I've made patches that can be applied against the current FreeBSD JDK8 port. Which I've submitted for review and committing to the BSD repo. Anyone interested can grab the patches and/or installable SDK and JRE builds at: https://drive.google.com/open?id=0Bz7VO-WP3rlpdGhMOUoyTG5TR1k -Curtis From owner-freebsd-ppc@freebsd.org Tue Feb 23 09:50:39 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D7CEBAB11BF 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 9BD5F1B8D for ; Tue, 23 Feb 2016 09:50:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 10435 invoked from network); 23 Feb 2016 09:50:48 -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:48 -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-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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-ppc@freebsd.org Tue Feb 23 14:55:26 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 72289AB2CCF for ; Tue, 23 Feb 2016 14:55:26 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 347441DEC; Tue, 23 Feb 2016 14:55:26 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-ob0-x22b.google.com with SMTP id gc3so196019440obb.3; Tue, 23 Feb 2016 06:55:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=bUbIyp1yq/QgYj7aNJTwJpwQkuWZgG2pBv3vXtLxSFQ=; b=V3wv80xRRuZPYfi3qGf+kYhPP6JQEKRrN54sDoJaTxcDFiAUIWodJAnmGfpqmaBJ/e 6VlaEamhDD2D5Zv66l0vnqsYjDXq/E2UUxTgmsC3BY7J/pKWCUOERPD7b/nTxDwuPFBr NLrbBzH7AP2H/BwV/jgPnBEKl6ZTUJwguJRO7s1WK821PZ7He5bEEng53uvVAgKztiFd szI8Y4khPxlKulZd+5Bl9NSL7C0iUy61OHhl+hjObV6qcM4H2VjEwl8WXeuEJTAGhkK6 Pu8Gjd04KaxxLCzTt2Suv7/S2ML06NeF786Wr0UP8yTR5hWP2IyZJbOdGZe/cytl3zBO N+pA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alumni-cwru-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=bUbIyp1yq/QgYj7aNJTwJpwQkuWZgG2pBv3vXtLxSFQ=; b=m4eAg4WcQF+OUka0TiVBSPESSojwoJsNVJf8nbc/g2ksYgsQYHaICpE16ikOPQNVVY eWelU7q8CboQ60cM1KgZqi/Rw0kBO48PAgYRMfFSO2h9jxtUWHWymYlaZl0Oflx3f8Gu oojgKGzVHjGGM1TQ2TA80lQJvNEcLWb5utyGJOF6pIi/tvd+f/rzYkO1/ojzZKfSg0cB rM8bby97JBvqpONOS2InML36Mx4uvmVA3WBocfMwW+V/uRNiKVERoI/ilQgEOlhMlZyN czeLTrOCSSMRL3pGmsoc3Xm0SAr2ZbdIDCoy/GvV97eDwhe3l+M5J9bA9VOIKgxRUXFw EgHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bUbIyp1yq/QgYj7aNJTwJpwQkuWZgG2pBv3vXtLxSFQ=; b=VvmCt9ZOIqovMkd/NOQU5jyEDLx/u1XI9TZTDmw1lp0rMvRxjg6a2f2rDKj1mpaGCN iuwy+crw+4DPDPIa37PrRzzA4SUrSA82X/DLGZTlChTYsJAqdHNADxBoZev2dlpsin54 upPIG+sko0aqyxYmTxx5tE5G+gEdMPHGpDXOvG42k6Jf54eVX6wwJgaXDrEEaGBLKO9k Fss8X6MkyKcUx/jdsn+VDZkNlw47B4W/+wpkX/eStw88drMCd1Ch7hXEedaTCFYPF4Xe 7OkK3xo9puBCegbAmthpsS4TtrgnIg0g0iYUFuAelWov82Ox/RyOFT02CNV2HqQmf1Vi ffHQ== X-Gm-Message-State: AG10YORT1Rskw12bjQLpE8VqhPhAJMS8R+tRUZE7lbgUvOYXqaUr2kIUkSXrpf4UzUsA8pwEP7UzXhf0MvkoXw== MIME-Version: 1.0 X-Received: by 10.182.142.69 with SMTP id ru5mr27680496obb.82.1456239325554; Tue, 23 Feb 2016 06:55:25 -0800 (PST) Sender: chmeeedalf@gmail.com Received: by 10.182.33.8 with HTTP; Tue, 23 Feb 2016 06:55:25 -0800 (PST) In-Reply-To: <005e01d16de8$4d06da30$e7148e90$@verizon.net> References: <005e01d16de8$4d06da30$e7148e90$@verizon.net> Date: Tue, 23 Feb 2016 08:55:25 -0600 X-Google-Sender-Auth: NE4asyCf8RgBAhCou7yVWSs9OYw Message-ID: Subject: Re: Native OpenJDK8 for PowerPC64 From: Justin Hibbits To: Curtis Hamilton Cc: Andreas Tobler , Steve Wills , FreeBSD PowerPC ML Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 14:55:26 -0000 On Mon, Feb 22, 2016 at 9:14 PM, Curtis Hamilton wrote: > Testers Wanted! > > I looking for anyone who is interested in a native OpenJDK8 (Mixed mode) for > PowerPC64. I been successful in modifying the AIX/Linux PPC code and build > a native (non-zero) JDK8 on FreeBSD PowerPC64. > > To validate the build, I made a couple of regression test runs with results > similar to what I got for the Zero VM build. However, performance is a > magnitude better than the Zero VM and I've used it to run several heavy duty > apps, like NetBeans, IntelliJ IdeaC, without crashes or core dumps. I've > actually used it to build itself. > > I've made patches that can be applied against the current FreeBSD JDK8 port. > Which I've submitted for review and committing to the BSD repo. > > Anyone interested can grab the patches and/or installable SDK and JRE builds > at: https://drive.google.com/open?id=0Bz7VO-WP3rlpdGhMOUoyTG5TR1k > > > -Curtis > This is fantastic, thanks for working on it! Can a build be kicked off in poudriere, or should I only test using ports directly (meaning, do the patches apply for using your build as bootstrap-jdk as well, or does the bootstrap binary jdk need to be installed separately)? - Justin From owner-freebsd-ppc@freebsd.org Tue Feb 23 16:38:16 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 46F19AB1B32 for ; Tue, 23 Feb 2016 16:38:16 +0000 (UTC) (envelope-from hamiltcl@verizon.net) Received: from vms173013pub.verizon.net (vms173013pub.verizon.net [206.46.173.13]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2A6E21D8; Tue, 23 Feb 2016 16:38:15 +0000 (UTC) (envelope-from hamiltcl@verizon.net) Received: from vz-proxy-m008.mx.aol.com ([64.236.83.16]) by vms173013.mailsrvcs.net (Oracle Communications Messaging Server 7.0.5.32.0 64bit (built Jul 16 2014)) with ESMTPA id <0O3000AIYBE35N50@vms173013.mailsrvcs.net>; Tue, 23 Feb 2016 09:37:16 -0600 (CST) X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=MtGvkDue c=1 sm=1 tr=0 a=CrpANybSWDwjH0Kr4i3vlQ==:117 a=IkcTkHD0fZMA:10 a=jFJIQSaiL_oA:10 a=pGLkceISAAAA:8 a=o1OHuDzbAAAA:8 a=6I5d2MoRAAAA:8 a=1XWaLZrsAAAA:8 a=NaG3FwH5p_9QIhHirSEA:9 a=QEXdDO2ut3YA:10 Received: by 96.255.168.17 with SMTP id 49fb7759; Tue, 23 Feb 2016 15:37:15 GMT From: "Curtis Hamilton" To: "'Justin Hibbits'" Cc: "'Andreas Tobler'" , "'Steve Wills'" , "'FreeBSD PowerPC ML'" References: <005e01d16de8$4d06da30$e7148e90$@verizon.net> In-reply-to: Subject: RE: Native OpenJDK8 for PowerPC64 Date: Tue, 23 Feb 2016 10:37:09 -0500 Message-id: <002201d16e50$0fa44d40$2eece7c0$@verizon.net> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-index: AQLLsIQ9/VB4PRCavEynUv8dv6gU9AIod5kgnTP5EnA= Content-language: en-us X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 16:38:16 -0000 I've only tested using ports directly, with the bootstrap jdk separately = installed. =20 I've not tested building in poudriere. However, you can give it a try. -Curtis -----Original Message----- From: chmeeedalf@gmail.com [mailto:chmeeedalf@gmail.com] On Behalf Of = Justin Hibbits Sent: Tuesday, February 23, 2016 9:55 AM To: Curtis Hamilton Cc: Andreas Tobler ; Steve Wills = ; FreeBSD PowerPC ML Subject: Re: Native OpenJDK8 for PowerPC64 On Mon, Feb 22, 2016 at 9:14 PM, Curtis Hamilton = wrote: > Testers Wanted! > > I looking for anyone who is interested in a native OpenJDK8 (Mixed=20 > mode) for PowerPC64. I been successful in modifying the AIX/Linux PPC = > code and build a native (non-zero) JDK8 on FreeBSD PowerPC64. > > To validate the build, I made a couple of regression test runs with=20 > results similar to what I got for the Zero VM build. However,=20 > performance is a magnitude better than the Zero VM and I've used it to = > run several heavy duty apps, like NetBeans, IntelliJ IdeaC, without=20 > crashes or core dumps. I've actually used it to build itself. > > I've made patches that can be applied against the current FreeBSD JDK8 = port. > Which I've submitted for review and committing to the BSD repo. > > Anyone interested can grab the patches and/or installable SDK and JRE=20 > builds > at: https://drive.google.com/open?id=3D0Bz7VO-WP3rlpdGhMOUoyTG5TR1k > > > -Curtis > This is fantastic, thanks for working on it! Can a build be kicked off = in poudriere, or should I only test using ports directly (meaning, do = the patches apply for using your build as bootstrap-jdk as well, or does = the bootstrap binary jdk need to be installed separately)? - Justin From owner-freebsd-ppc@freebsd.org Thu Feb 25 01:14:42 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 77E76AB3DA5 for ; Thu, 25 Feb 2016 01:14:42 +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 3B72CB10 for ; Thu, 25 Feb 2016 01:14:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15685 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-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 01:14: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-ppc@freebsd.org Thu Feb 25 01:53:06 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 808F8AB2E52 for ; Thu, 25 Feb 2016 01:53:06 +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 4470F1A7 for ; Thu, 25 Feb 2016 01:53:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28369 invoked from network); 25 Feb 2016 01:53:02 -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:02 -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-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 01:53:06 -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-ppc@freebsd.org Thu Feb 25 04:46:51 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C310AB2317 for ; Thu, 25 Feb 2016 04:46:51 +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 114F5BA2 for ; Thu, 25 Feb 2016 04:46:50 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 25618 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-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 04:46:51 -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-ppc@freebsd.org Fri Feb 26 11:16:47 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4FB4AB4205 for ; Fri, 26 Feb 2016 11:16:47 +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 A87811E4A for ; Fri, 26 Feb 2016 11:16:47 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 25927 invoked from network); 26 Feb 2016 11:16:57 -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:57 -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-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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-ppc@freebsd.org Fri Feb 26 13:25:41 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2537EAB418E for ; Fri, 26 Feb 2016 13:25:41 +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 DCDF311EE for ; Fri, 26 Feb 2016 13:25:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 10335 invoked from network); 26 Feb 2016 13:25:55 -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:55 -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-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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-ppc@freebsd.org Fri Feb 26 23:26:44 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1822CAB5BAB for ; Fri, 26 Feb 2016 23:26:44 +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 D1EB1303 for ; Fri, 26 Feb 2016 23:26:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 7916 invoked from network); 26 Feb 2016 23:26:40 -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:40 -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-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 23:26:44 -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-ppc@freebsd.org Sat Feb 27 23:32:08 2016 Return-Path: Delivered-To: freebsd-ppc@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E3865AB63B6 for ; Sat, 27 Feb 2016 23:32:07 +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 A76B714CC for ; Sat, 27 Feb 2016 23:32:07 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14189 invoked from network); 27 Feb 2016 23:31:58 -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:31:58 -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-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC 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