From owner-freebsd-sparc64@FreeBSD.ORG  Tue Sep  4 21:31:39 2007
Return-Path: <owner-freebsd-sparc64@FreeBSD.ORG>
Delivered-To: freebsd-sparc64@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id D368816A417
	for <freebsd-sparc64@freebsd.org>; Tue,  4 Sep 2007 21:31:39 +0000 (UTC)
	(envelope-from nox@saturn.kn-bremen.de)
Received: from gwyn.kn-bremen.de (gwyn.kn-bremen.de [212.63.36.242])
	by mx1.freebsd.org (Postfix) with ESMTP id 8EA5113C458
	for <freebsd-sparc64@freebsd.org>; Tue,  4 Sep 2007 21:31:39 +0000 (UTC)
	(envelope-from nox@saturn.kn-bremen.de)
Received: by gwyn.kn-bremen.de (Postfix, from userid 10)
	id 7A0C52189B5; Tue,  4 Sep 2007 23:31:38 +0200 (CEST)
Received: from saturn.kn-bremen.de (nox@localhost [127.0.0.1])
	by saturn.kn-bremen.de (8.13.8/8.13.6) with ESMTP id l84LUXS3082718;
	Tue, 4 Sep 2007 23:30:33 +0200 (CEST)
	(envelope-from nox@saturn.kn-bremen.de)
Received: (from nox@localhost)
	by saturn.kn-bremen.de (8.13.8/8.13.6/Submit) id l84LUX74082717;
	Tue, 4 Sep 2007 23:30:33 +0200 (CEST) (envelope-from nox)
From: Juergen Lock <nox@jelal.kn-bremen.de>
Date: Tue, 4 Sep 2007 23:30:33 +0200
To: Christian Weisgerber <naddy@mips.inka.de>
Message-ID: <20070904213033.GA82554@saturn.kn-bremen.de>
References: <20070901165653.GA38448@saturn.kn-bremen.de>
	<fbhcev$26p0$1@kemoauc.mips.inka.de>
	<200709031945.l83JjcBZ079835@kemoauc.mips.inka.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200709031945.l83JjcBZ079835@kemoauc.mips.inka.de>
User-Agent: Mutt/1.5.16 (2007-06-09)
Cc: freebsd-sparc64@freebsd.org
Subject: Re: weird sparc64/-current issue!? (p7zip)
X-BeenThere: freebsd-sparc64@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Porting FreeBSD to the Sparc <freebsd-sparc64.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64>, 
	<mailto:freebsd-sparc64-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-sparc64>
List-Post: <mailto:freebsd-sparc64@freebsd.org>
List-Help: <mailto:freebsd-sparc64-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-sparc64>,
	<mailto:freebsd-sparc64-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Sep 2007 21:31:39 -0000

On Mon, Sep 03, 2007 at 09:45:39PM +0200, Christian Weisgerber wrote:
> Christian Weisgerber <naddy@mips.inka.de> wrote:
> 
> > > 		UInt32 GetNumberOfProcessors() {
> > > 		  		int nbcpu = 1;
> > > 			size_t value;
> > > 			size_t len = sizeof(value);
> > > 			if (sysctlbyname("hw.ncpu", &value, &len, NULL, 0) == 0)
> > > 				nbcpu = value;
> > > 			return nbcpu;
> > > 		}
> > 
> > Are you sure that value is of type size_t here?  I think it is an
> > int.  (Remember, size_t is 64 bits on all our 64-bit platforms, int
> > is 32 bits.)
> 
> I should expand on this, because it is a really tricky LP64 bug.
> 
> sysctlbyname() writes a 32-bit value to the supplied address, but
> we then read a 64-bit value.  On a little-endian machine (alpha,
> amd64) we get the actual value in the lower 32 bits and random
> garbage in the upper 32.  Then the assignment nbcpu=value drops the
> upper 32 bits.  Quite by accident, we always end up with the correct
> result.
> 
> On a big-endian machine (sparc64), it's the other way around:  We
> get the actual value in the upper 32 bits and random garbage in the
> lower 32.  Then the assignment nbcpu=value drops the upper 32 bits.
> Thus we always end up with a garbage result.

[Ooops, I didn't see at first you did post this to the list too!]

 Yup, hw.ncpu seems to be an int indeed, no wonder it didn't work.
So I guess I'll just patch that and wait for the next sparc64 build... :)

 Thanx again,
	Juergen