From owner-svn-src-all@FreeBSD.ORG Mon Mar 30 18:31:36 2015 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 84A12E84; Mon, 30 Mar 2015 18:31:36 +0000 (UTC) Received: from gw.catspoiler.org (cl-1657.chi-02.us.sixxs.net [IPv6:2001:4978:f:678::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 339E1F19; Mon, 30 Mar 2015 18:31:36 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id t2UIVClw095330; Mon, 30 Mar 2015 10:31:16 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <201503301831.t2UIVClw095330@gw.catspoiler.org> Date: Mon, 30 Mar 2015 11:31:12 -0700 (PDT) From: Don Lewis Subject: Re: svn commit: r280327 - in head/sys: kern vm To: kostikbel@gmail.com In-Reply-To: <20150330091209.GC2379@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: src-committers@FreeBSD.org, alc@rice.edu, alc@FreeBSD.org, svn-src-all@FreeBSD.org, bdrewery@FreeBSD.org, portmgr@FreeBSD.org, svn-src-head@FreeBSD.org, clusteradm@FreeBSD.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 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: Mon, 30 Mar 2015 18:31:36 -0000 On 30 Mar, Konstantin Belousov wrote: > On Sun, Mar 29, 2015 at 11:25:14PM -0700, Don Lewis wrote: >> On amd64, with an amd64 jail, and kernel rev r280326, I observe the >> following: >> One gcc process calls mmap() with addr=0 and len=0x657a000, and >> the value 0x811400000 is returned. Subsequent gcc processes >> call mmap() with addr=0x811400000 and len=0x657a000, getting >> 0x811400000 in return. >> >> With kernel rev r280327 I see: >> One gcc process calls mmap() with addr=0 and len=0x657a000, and >> the value 0x811400000 is returned. Subsequent gcc processes >> call mmap() with addr=0x811400000 and len=0x657a000, getting >> 0x8115f4000 in return. What I later noticed is that the subsequent >> calls are passing offset=0x1f4000. Not so coincidentally, >> 0x811400000 + 0x1f4000 = 0x8115F4000. >> >> My first attempt at a fix subtracted offset from address, but the mmap() >> return value changed to 0x8113f4000 instead of the 0x811400000 I was >> expecting. It looked to me like the code must be doing superpage >> alignment on the start of the file and then adding the offset to get the >> start of the mapped region. > So the real fix is to make gcc pass MAP_FIXED. This PR explains why MAP_FIXED can't be used. Basically MAP_FIXED will silently clobber any other mappings in that range, introducing other bugs. MAP_FIXED | MAP_EXCL would work, but we didn't get that until FreeBSD 10. I think if the compiler specified the same offset to both mmap() calls, it might work properly. But that leaves the problem of actually fixing the compiler since it is a binary that is part of some number of supported releases. The usual practice for port building is to populate the jails with releases. It is possible to set up jails that build from source, but that's not commonly done and is broken in the case of 8.4 without extreme hackery. The ports versions of gcc might also be affected, but that's less of an issue. It just requires patching those ports. There is also the issue of customers who have a policy of only running official release code. When 11.0-RELEASE comes around, is is going to have a release note that says that the compiler in a 9.3-RELEASE jail doesn't work as well on an 11.0-RELEASE host vs. a 10.x-RELEASE host? Also, is there any other code out in the wild that assumes the old way that mmap() handled hints and will break when I runs on FreeBSD 11, either in an older jail or on bare metal? >> >> This somewhat hacking patch disables this alignment if a non-zero >> address is passed as a hint, and allows the code to make the start of >> the mapped region match the hint. With this patch, I've been able to >> build openjdk7 in a FreeBSD 9.3 amd64 jail. >> > This is for precompiled headers, right ? Could port disable pch ? Correct. I'm guessing that it is likely that the port could be tweaked to disable pch. I only build about 1100-1200 ports and found one that broke. We would need to do an exp run to find out how many others there are. That would take care of the problems of building the ports, but the other issues would still remain.