On 03/30/2015 13:31, Don Lewis wrote: > 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 <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940> 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.
This is precisely why config/host-solaris.c does a series of mincore() calls. > 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. > > _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
