Date: Sat, 28 Mar 2015 11:25:44 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: alc@rice.edu Cc: src-committers@FreeBSD.org, alc@FreeBSD.org, svn-src-all@FreeBSD.org, bdrewery@FreeBSD.org, portmgr@FreeBSD.org, svn-src-head@FreeBSD.org, clusteradm@FreeBSD.org Subject: Re: svn commit: r280327 - in head/sys: kern vm Message-ID: <201503281825.t2SIPi6d081565@gw.catspoiler.org> In-Reply-To: <5516EB31.7000309@rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 28 Mar, Alan Cox wrote: > On 03/28/2015 12:29, Bryan Drewery wrote: >> On 3/27/2015 9:41 PM, Don Lewis wrote: >>> I was not seeing this problem on my older package builder running >>> 10.1-STABLE. Since this problem has not shown up on the FreeBSD package >>> building cluster, I got suspicious that the change was quite recent. >>> >>> This old gcc bug report: >>> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940>; led me to suspect >>> mmap(). >>> >>> The old gcc source file /usr/src/contrib/gcc/ggc-common.c does a couple >>> of mmap() calls. Tne first is in mmap_gt_pch_get_address() where a >>> NULL first argument is used. The address that gets returned is stashed >>> away and the region is unmapped. Then a later call in >>> mmap_gt_pch_use_address() passes this saved address to mmap() as a >>> hint. It expects the mapped region to get mapped to the same base >>> address. If this does not happen, the above error is the result. >> I don't know what I'm talking about but that doesn't sound like a very >> safe assumption for the gcc code to make. > > > Your intuition is correct. It is not. And, in fact, under Solaris and > Linux, gcc does not make this assumption. > > I suspect that the solution used by gcc under Solaris would work for > us. However, that would entail modifying gcc in older branches. That's somewhat problematic because we use releases + official updates for package building. To continue doing this, we'd have to treat the gcc fix as an EN.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201503281825.t2SIPi6d081565>