From owner-freebsd-current Sun Feb 23 22:38:11 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 777D537B401 for ; Sun, 23 Feb 2003 22:38:09 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72F8543F85 for ; Sun, 23 Feb 2003 22:38:08 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id RAA07989; Mon, 24 Feb 2003 17:37:58 +1100 Date: Mon, 24 Feb 2003 17:39:12 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Terry Lambert Cc: David Syphers , Kirk McKusick , Subject: Re: BOOT2_UFS=UFS1_ONLY works for today's current In-Reply-To: <3E59B5DA.66EDBC85@mindspring.com> Message-ID: <20030224173124.X5702-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 23 Feb 2003, Terry Lambert wrote: > Bruce Evans wrote: > > > Personally, I think the changes should be #ifdef'ed the current > > > version of GCC; when GCC rev's, hopefully its 64 bit operations > > > handling will have improved. > > > > This would wrong, since ufs2 depends on the changes to actually work > > for file systems larger than about 1TB. > > If it's not going to compile correctly, it's not going to work. That is a feature :-). > What we are bitching about here is that someone wants to use > 64 bit operations that GCC can't handle. Waving our hands isn't > going to make the problem go away, and adding code that doesn't > compile correctly with the current compiler won't, either. I doubt that it is a problem with 64-bitness. Handling 64 bits just takes more code, and the macro is apparently used a lot (it is used deeply nested so it is not obvious how often it is expanded). I suspect the problem is more from increased register pressure that happens to afect the current compiler more. > > This changes a (32, 32) -> 32 bit (possibly overflowing) operation to a > > (32, 32) -> 64 bit (never overflowing) operation. The 1386 hardware > > already does the wider operation so all gcc has to do is not discard the > > high 32-bits, which it does reasonably well. > > So it is agreed that this is good? I hope so. The result doesn't always fit in 32 bits when the file system size exceeds about 1TB. Discarding nonzero high bits probably causes corrupt file systems. > OK... so what should be done? Just the cgbase() change? Does > this fix the compiler revision dependent problem in such a way > that the code does not need to be conditionalized on the compiler > revision to avoid being broken? Kirk committed a quick fix. The bug is unlikely to matter in boot code. Root file systems shouldn't be larger than 1TB. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message