From owner-svn-src-all@freebsd.org Sun Oct 18 16:19:42 2015 Return-Path: Delivered-To: svn-src-all@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 542E8A18BE4 for ; Sun, 18 Oct 2015 16:19:42 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 347D1833 for ; Sun, 18 Oct 2015 16:19:41 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Sun, 18 Oct 2015 16:19:52 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t9IGJd4w008353; Sun, 18 Oct 2015 10:19:39 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1445185179.71631.50.camel@freebsd.org> Subject: Re: svn commit: r289477 - head/sys/arm/mv From: Ian Lepore To: Konstantin Belousov Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Date: Sun, 18 Oct 2015 10:19:39 -0600 In-Reply-To: <20151018094602.GF2257@kib.kiev.ua> References: <201510180103.t9I13h0w056671@repo.freebsd.org> <20151018094602.GF2257@kib.kiev.ua> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2015 16:19:42 -0000 On Sun, 2015-10-18 at 12:46 +0300, Konstantin Belousov wrote: > On Sun, Oct 18, 2015 at 01:03:43AM +0000, Ian Lepore wrote: > > Author: ian > > Date: Sun Oct 18 01:03:43 2015 > > New Revision: 289477 > > URL: https://svnweb.freebsd.org/changeset/base/289477 > > > > Log: > > Fix a strange macro re-definition compile error. If the > > VM_MAXUSER_ADDRESS > > value is defined as a config option the definition is emitted > > into > > opt_global.h which is force-included into everything. In > > addition, the > > symbol is emitted by the genassym mechanism, but that by its > > nature reduces > > the value to a 0xnnnnnnnn number. When compiling a .S file you > > end up > > with two different definitions of the macro (they evaluate to the > > same > > number, but the text is different, upsetting the compiler). > > > > Nothing has changed about this code for a while but the compile > > error is > > new, so this must be fallout from the clang 3.7 update or > > something. > > > > Modified: > > head/sys/arm/mv/std-pj4b.mv > > > > Modified: head/sys/arm/mv/std-pj4b.mv > > =================================================================== > > =========== > > --- head/sys/arm/mv/std-pj4b.mv Sun Oct 18 00:59:28 2015 > > (r289476) > > +++ head/sys/arm/mv/std-pj4b.mv Sun Oct 18 01:03:43 2015 > > (r289477) > > @@ -5,4 +5,8 @@ cpu CPU_MV_PJ4B > > machine arm armv6 > > makeoptions CONF_CFLAGS="-march=armv7a" > > > > -options VM_MAXUSER_ADDRESS="(KERNBASE > > -(1024*1024*1024))" > > +# This was originally defined as "(KERNBASE-(1024*1024*1024))" but > > that > > +# (in opt_global.h) clashed with the value emitted by genassym > > which > > +# reduces the original macro text to its numeric value. The only > > way > > +# to avoid that is to define it here as the numeric value genassym > > emits. > > +options VM_MAXUSER_ADDRESS="0x80000000" > > Genassym started to generate VM_MAXUSER_ADDRESS after r289372. > Strange that I did not saw the error. > > Why does marvell need this override ? > That is a very good question, to which I found no answer in the svn history... this value was in the file from day one and the commit message just says it was obtained from Marvell and Semihalf. There's other strange stuff in the arm/mv hierarchy that nobody (except maybe marvell and semihalf) knows why it's different. I finally bought myself an ARMADAXP-based system (which this config is for) about six months ago, but I literally haven't had a chance to take it out of the box since it arrived. ::sigh:: -- Ian