From owner-freebsd-ppc@FreeBSD.ORG Thu Jun 12 15:39:51 2014 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA6EDD60; Thu, 12 Jun 2014 15:39:51 +0000 (UTC) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D5A5296F; Thu, 12 Jun 2014 15:39:51 +0000 (UTC) Received: by mail-yk0-f172.google.com with SMTP id 142so1100571ykq.31 for ; Thu, 12 Jun 2014 08:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=EqfGY7QNksYuCN8m0o62wr8MTb/NBLidaW97H8MLytQ=; b=EDhzJdY+hEy86cKO9a8Zktlv0hDm9ilS4XXi1y1Kq6EcDvqicrbQl+8kYcDrRAWrLZ 4WAedGOIGBS9GRE5SRgiNFBe2NRJNRk3MobwvjAHqhRtV388JbdH0oZ/UKAzEiSKR7vu DkU++HL+WEcArnK0hMdDOpr1ECMkr17JMEaPKrjNzddYiZWbgqDg6ObOVsMom2Q2/eHL SZvMfH+fH0TwPHQQVKvbrXDXIOvXPls3czqARaVv10o3nXypurt4La4mhUAtW1VtcZuc n9SNJdTKFcbIM1OyyjzLLdqmDKbNOa1q8K6Fl3ForQDCAsMHS/lUVT04Y+0E27hgztz7 U7Mw== X-Received: by 10.236.32.65 with SMTP id n41mr16792221yha.117.1402587590819; Thu, 12 Jun 2014 08:39:50 -0700 (PDT) Received: from zhabar.att.net (107-222-186-3.lightspeed.sntcca.sbcglobal.net. [107.222.186.3]) by mx.google.com with ESMTPSA id k66sm1849379yhg.39.2014.06.12.08.39.50 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Thu, 12 Jun 2014 08:39:50 -0700 (PDT) Date: Thu, 12 Jun 2014 08:39:46 -0700 From: Justin Hibbits To: Julio Merino Subject: Re: Fix db48 in powerpc64 Message-ID: <20140612083946.53a09762@zhabar.att.net> In-Reply-To: <13D61493-60D9-480A-A0ED-DC29C3795C73@freebsd.org> References: <13D61493-60D9-480A-A0ED-DC29C3795C73@freebsd.org> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; powerpc64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-ppc@freebsd.org X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 15:39:52 -0000 On Thu, 10 Apr 2014 18:58:02 -0400 Julio Merino wrote: > Hello, > > The databases/db48 port does not build under FreeBSD powerpc64 due to > a return type mismatch in an assembly routine. > > The patch below fixes the *build*, but I have zero clue if it's > correct or not; I'm just following the structure of all other > routines. I'm also pasting below everything related to powerpc in > the relevant files, hoping that the comments give enough context. > > Could someone that understands powerpc assembly please review this? > > Thanks! > > > ----- existing contents ----- > > /********************************************************************* > * PowerPC/gcc assembly. > *********************************************************************/ > #if defined(HAVE_MUTEX_PPC_GCC_ASSEMBLY) > typedef u_int32_t tsl_t; > > #ifdef LOAD_ACTUAL_MUTEX_CODE > /* > * The PowerPC does a sort of pseudo-atomic locking. You set up a > * 'reservation' on a chunk of memory containing a mutex by loading > the > * mutex value with LWARX. If the mutex has an 'unlocked' (arbitrary) > * value, you then try storing into it with STWCX. If no other > process or > * thread broke your 'reservation' by modifying the memory containing > the > * mutex, then the STCWX succeeds; otherwise it fails and you try to > get > * a reservation again. > * > * While mutexes are explicitly 4 bytes, a 'reservation' applies to an > * entire cache line, normally 32 bytes, aligned naturally. If the > mutex > * lives near data that gets changed a lot, there's a chance that > you'll > * see more broken reservations than you might otherwise. The only > * situation in which this might be a problem is if one processor is > * beating on a variable in the same cache block as the mutex while > another > * processor tries to acquire the mutex. That's bad news regardless > * because of the way it bashes caches, but if you can't guarantee > that a > * mutex will reside in a relatively quiescent cache line, you might > * consider padding the mutex to force it to live in a cache line by > * itself. No, you aren't guaranteed that cache lines are 32 bytes. > Some > * embedded processors use 16-byte cache lines, while some 64-bit > * processors use 128-bit cache lines. But assuming a 32-byte cache > line > * won't get you into trouble for now. > * > * If mutex locking is a bottleneck, then you can speed it up by > adding a > * regular LWZ load before the LWARX load, so that you can test for > the > * common case of a locked mutex without wasting cycles making a > reservation. * > * gcc/ppc: 0 is clear, 1 is set. > */ > static inline int > MUTEX_SET(int *tsl) { > int __r; > __asm__ volatile ( > "0: \n\t" > " lwarx %0,0,%1 \n\t" > " cmpwi %0,0 \n\t" > " bne- 1f \n\t" > " stwcx. %1,0,%1 \n\t" > " isync \n\t" > " beq+ 2f \n\t" > " b 0b \n\t" > "1: \n\t" > " li %1,0 \n\t" > "2: \n\t" > : "=&r" (__r), "+r" (tsl) > : > : "cr0", "memory"); > return (int)tsl; > } > > static inline int > MUTEX_UNSET(tsl_t *tsl) { > __asm__ volatile("sync" : : : "memory"); > return *tsl = 0; > } > #define MUTEX_INIT(tsl) MUTEX_UNSET(tsl) > #endif > #endif > > > ----- diff ----- > > Index: files/patch-dbinc_mutex_int.h > =================================================================== > --- files/patch-dbinc_mutex_int.h (revision 0) > +++ files/patch-dbinc_mutex_int.h (working copy) > @@ -0,0 +1,11 @@ > +--- ../dbinc/mutex_int.h.orig 2014-04-04 12:52:15.255739375 > -0400 ++++ ../dbinc/mutex_int.h 2014-04-04 12:52:27.454733578 > -0400 +@@ -596,7 +596,7 @@ MUTEX_SET(int *tsl) { > + : "=&r" (__r), "+r" (tsl) > + : > + : "cr0", "memory"); > +- return (int)tsl; > ++ return !__r; > + } > + > + static inline int It looks like the 'correct' solution is 'return (tsl != NULL);' or 'return (tsl != 0);' I just ran into this problem again myself. With that, a bug should be filed so that in the future we can have a working db4x (my db48 working dir was just erased by portmaster). - Justin