From owner-freebsd-arm@freebsd.org Tue Jan 19 21:08:10 2016 Return-Path: Delivered-To: freebsd-arm@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 A62F7A8804B for ; Tue, 19 Jan 2016 21:08:10 +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 6C8EC1A33 for ; Tue, 19 Jan 2016 21:08:09 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 16438 invoked from network); 19 Jan 2016 21:08:03 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 19 Jan 2016 21:08:03 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Tue, 19 Jan 2016 16:08:05 -0500 (EST) Received: (qmail 27774 invoked from network); 19 Jan 2016 21:08:04 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 19 Jan 2016 21:08:04 -0000 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 5BCDC1C43C4; Tue, 19 Jan 2016 13:07:58 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: make buildworld failed with error "relocation truncated to fit: R_ARM_JUMP24 against symbol `_fini'" From: Mark Millard In-Reply-To: <1453234839.46848.88.camel@freebsd.org> Date: Tue, 19 Jan 2016 13:08:01 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <36E4B4DD-C479-484D-8BA3-A1DC1F71564A@dsl-only.net> References: <3E1CC674-D534-4C33-8C96-CA9E584931C0@dsl-only.net> <569D2557.3060802@codeghar.com> <374A0F64-E3FC-42F1-AC03-DF8F88269AEB@dsl-only.net> <569D2D63.8030301@codeghar.com> <1453217670.46848.83.camel@freebsd.org> <1453234839.46848.88.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 21:08:10 -0000 On 2016-Jan-19, at 12:20 PM, Ian Lepore wrote: >=20 > On Tue, 2016-01-19 at 11:46 -0800, Mark Millard wrote: >> On 2016-Jan-19, at 7:34 AM, Ian Lepore wrote: >>>=20 >>> On Tue, 2016-01-19 at 11:58 +0000, Tom Vijlbrief wrote: >>>> Op ma 18 jan. 2016 20:37 schreef Mark Millard < >>>> markmi@dsl-only.net>: >>>>=20 >>>>>=20 >>>>> If you can tolerate tracking the 3.8.0 project ( >>>>> base/projects/clang380-import ) until 3.8.0 is moved into 11.0 >>>>> -CURRENT you >>>>> could find out that way if clang 3.8.0 behaves the same in your >>>>> context. So >>>>> far I've not come up with anything else >>>>=20 >>>>=20 >>>> I am having exactly the same buildworld problem on my RPI which >>>> used >>>> to >>>> build fine a week ago. >>>>=20 >>>> Currently testing the clang380-import branch as suggested to see >>>> if >>>> the >>>> problem persists. >>>=20 >>> The most confusing thing about this whole thread (besides the lack >>> of >>> logs so we're just guessing what's going on) is why this problem is >>> suddenly happening on clang 3.7.x (I guess it's 3.7.x here) when >>> that >>> has never been a problem before? We needed to add the long-call >>> option >>> when testing clang 3.8, but why do we suddenly need it on clang 3.7 >>> that hasn't needed it for months? >>>=20 >>> This very much has the feel of slapping a bandaid on something that >>> needs a better diagnosis (there may be internal bleeding). If we >>> don't >>> understand why it's failing, it doesn't make sense to try to fix it >>> with the "cure" for a different problem. (Maybe we never >>> understood >>> the clang 3.8 problem.) >>>=20 >>> -- Ian >>=20 >> The -mlong-calls were added to 11.0-CURRENT recently. >>=20 >> -r293648: 2016-Jan-10 (head/lib/csu/arm/Makefile) >> -r294031: 2016-Jan-14 (the rest added here) >>=20 >> May be a problem/incompleteness in the handling -mlong-calls itself? >> Are the above the right time frame for the problem starting for >> 3.7.1? >=20 > We've been using clang 3.7 since October. We never needed = -mlong-calls > until recently. I had thought it was clang 3.8 that triggered the = need > for -mlong-calls, but now we apparently have a report of clang 3.7.x > needing it. >=20 > So... why? What changed, and why are we blindly reacting without > understanding? >=20 > -- Ian The initial report turned out to be for a build for /usr/src content = from *after* the -mlong-calls had been added to 11.0-CURRENT. I'm not sure that anything reported as a failure is from before the = -mlong-calls were added to 11.0-CURRENT. Or from between -r293648 and = -r294031 . As far as I can tell people are just exploring trying to find some = context difference that controls getting the different results. Having = an explanation established before such an identification is also known = is problematical. It does not help that self-hosted builds on rpi2's and the like take so = long. Bisecting has a long elapsed time. It would take several going in = parallel on different -r?????'s to speed up that style of finding where = things changed. I do not remember any reports of a cross-build failure but it may be = that most "on rpi2" folks do not also do cross builds so that little is = known for that context. I do not know what it takes to use clang/clang++ 3.7.1 but to also avoid = the clang++ 3.7.1 Bus Errors that I got during buildworld on the rpi2. = I'd have to solve that first before contributing to the "on rpi2" = testing of 3.7.1-based builds. (Cross builds did not/do not have the Bus = Error problem in clang++.) My historically targeting cortex-a7 means that my past activity is of = questionable applicability to the questions at play. =3D=3D=3D Mark Millard markmi at dsl-only.net