From owner-freebsd-ppc@FreeBSD.ORG Thu Apr 10 23:56:25 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 B1441C15 for ; Thu, 10 Apr 2014 23:56:25 +0000 (UTC) Received: from mail-yh0-f42.google.com (mail-yh0-f42.google.com [209.85.213.42]) (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 733051469 for ; Thu, 10 Apr 2014 23:56:25 +0000 (UTC) Received: by mail-yh0-f42.google.com with SMTP id t59so4672887yho.1 for ; Thu, 10 Apr 2014 16:56:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:content-type :content-transfer-encoding:subject:message-id:date:to:mime-version; bh=yckRDsrNR0hI2VFGpSFwAJxNiQvQcnvAFiOLAp+Qq5Q=; b=Lg5mdmkOntuNDK4aA5PjG68m9RdW0z3xE1R5p/EdIgRYG06RJXs4XjUUZ3mC1Pqbiw s0CWLFQOVp9f8Fr8MKKjhqrKndncO7wSEQi3mQMVejM9cxp1NjJdiMQFopFmSV/NJksY Hgd/n1P9LGk7Jlzt8jH61GlcV2lwdyEjrEYIyxmsbZs7GwNSdSPRrwi4UHesD1pevpb7 VRjYYYahZyxkWUQPBhYO6+DhtWTsTcY3gtJLYdrq2KbS7WIOIbOshAU7EOKOW6tQTGjj Lar241q+2SfJYvrlQlc8luZVrfj+0TS4u3kSDhon+/1yXsYIyEQWnu/VMzLO3tNkDNRY azcg== X-Gm-Message-State: ALoCoQnoqVRBQRciO+jOs1UeFjcApYNSisFmev6kgXu5Z7R8J/zyI0AZN2zvBiqlQDYQWxvSNS5L X-Received: by 10.236.206.7 with SMTP id k7mr27152317yho.84.1397170685087; Thu, 10 Apr 2014 15:58:05 -0700 (PDT) Received: from ?IPv6:2620::1003:1007:e58e:92bd:23b1:5fcb? ([2620:0:1003:1007:e58e:92bd:23b1:5fcb]) by mx.google.com with ESMTPSA id f62sm10230539yhq.6.2014.04.10.15.58.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Apr 2014 15:58:04 -0700 (PDT) Sender: Julio Merino From: Julio Merino Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Fix db48 in powerpc64 Message-Id: <13D61493-60D9-480A-A0ED-DC29C3795C73@freebsd.org> Date: Thu, 10 Apr 2014 18:58:02 -0400 To: freebsd-ppc@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 23:56:25 -0000 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" : "=3D&r" (__r), "+r" (tsl) : : "cr0", "memory"); return (int)tsl; } static inline int MUTEX_UNSET(tsl_t *tsl) { __asm__ volatile("sync" : : : "memory"); return *tsl =3D 0; } #define MUTEX_INIT(tsl) MUTEX_UNSET(tsl) #endif #endif ----- diff ----- Index: files/patch-dbinc_mutex_int.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- 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) { + : "=3D&r" (__r), "+r" (tsl) + : + : "cr0", "memory"); +- return (int)tsl; ++ return !__r; + } +=20 + static inline int