From owner-freebsd-ppc@FreeBSD.ORG Wed Mar 18 06:38:49 2015 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F31D9FD4 for ; Wed, 18 Mar 2015 06:38:48 +0000 (UTC) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 61E02196 for ; Wed, 18 Mar 2015 06:38:48 +0000 (UTC) Received: by lbbsy1 with SMTP id sy1so22793342lbb.1 for ; Tue, 17 Mar 2015 23:38:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=4jKplhUHBOSDesAs6uFnv4afYV9g49ptBYyR6km+nIs=; b=lkgmpLMFZm/TL4wQZLQ5hOJXtJGkYnkWPoCyc4ylR1NO97HagBm79ee0N7exlrv2Hv 8ItJkklSw+CPMr7Z1B7NqfB3RRX45K0CAlqj/5wMJNPtUbhKNg3V4D5ahJrmTHP9qeuJ tCQpuEE8rws1n7An1Yq4GD7dTc79LOiQ1K0y0XgQFP3y81/+OekQRc9FVxusJIAVOU4C 9WrUfNPCTXHRg7GQcoJbM1Nd8p0YaSEmeO5yOq6ygnMV4LskZOIj+i5YbfDUtQllm0aP HsaA8MqdfMA+pP3LBKq6kXn4kN43jEhj5h4S/y06Qct90ie0Uo/JoL98txEnibIYot8K 5UXA== X-Received: by 10.152.19.9 with SMTP id a9mr63844463lae.80.1426660725981; Tue, 17 Mar 2015 23:38:45 -0700 (PDT) Received: from [192.168.1.130] (xdsl-205-163.nblnetworks.fi. [83.145.205.163]) by mx.google.com with ESMTPSA id d6sm3197241lbp.16.2015.03.17.23.38.45 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Mar 2015 23:38:45 -0700 (PDT) Message-ID: <55091DB7.7010601@gmail.com> Date: Wed, 18 Mar 2015 08:39:51 +0200 From: Jukka Ukkonen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Justin Hibbits Subject: Re: Something missing perhaps? References: <55082540.1020001@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 06:38:49 -0000 Right, it did not occur to me to blame it on the compiler, but that certainly is an excellent explanation. If I understood correctly sync_lock_test_and_set_8 should then be an alias to***atomic_testandset_64* , sync_fetch_and_add_8 an alias to *atomic_fetchadd_* *64*, and sync_bool_compare_and_swap an alias to* atomic_cmpset_acq_64*. Then the problem is shifted to the 64 bit atomic operations not having been implemented at all for 32 bit ppc. This is clearly due to the fact that the ldarx instruction etc, which would be the native HW method for implementing the 64 bit atomic operations, are only available on ppc64, not on ppc32. Ref. sys/powerpc/include/atomic.h and http://www-01.ibm.com/support/knowledgecenter/ssw_aix_53/com.ibm.aix.aixassem/doc/alangref/ldarx.htm This being the case it kind of makes sense to ask why should the compiler try to use 64 bit atomic operations in the first place on a system which does not support them natively? In my mind it would be immensely better (read more efficient) to drop the ball back to the programmers forcing them to use data types suitable for the hardware. --jau On 2015-03-17 20:35, Justin Hibbits wrote: > These symbol references are generated by the compiler to handle 64-bit > atomic operations. I don't think there's currently any support, even > in libgcc, for 64-bit atomics on 32-bit powerpc. Something *could* be > hacked together to handle it, using a mutex wrapper, but to the best > of my knowledge, nobody's done the work for it. > > - Justin > > On Tue, Mar 17, 2015 at 5:59 AM, Jukka Ukkonen wrote: >> Hello all, >> >> I was trying to build kyotocabinet from the ports tree >> on an old PowerMac G4 Quicksilver, but the attempt failed >> in a very peculiar manner... >> Do these complaints from cc ring any bells... >> >> ./libkyotocabinet.so: undefined reference to `__sync_lock_test_and_set_8' >> ./libkyotocabinet.so: undefined reference to `__sync_fetch_and_add_8' >> ./libkyotocabinet.so: undefined reference to >> `__sync_bool_compare_and_swap_8' >> ./libkyotocabinet.so: undefined reference to `__sync_lock_test_and_set_8' >> ./libkyotocabinet.so: undefined reference to `__sync_fetch_and_add_8' >> ./libkyotocabinet.so: undefined reference to >> `__sync_bool_compare_and_swap_8' >> >> Those missing names are apparenly being referenced by >> work/kyotocabinet-1.2.76/kcthread.cc. Since I failed >> to find the definition of these names anywhere in the >> kyotocabinet source, I assume the names are used in >> some compiler header file. >> Were those names really intended to be in the headers >> as-is or were they actually some sort of place holders >> for something which have then been completely forgotten >> for some reason? >> >> The all important details of the system are... >> >> # uname -a >> FreeBSD yggdrasil 10.1-STABLE FreeBSD 10.1-STABLE #0 r280132: Mon Mar 16 >> 06:12:57 EET 2015 root@yggdrasil:/opt2/obj/usr/src-10.1/sys/GENERIC >> powerpc >> >> # uname -KU >> 1001510 1001510 >> >> # freebsd-version -ku >> 10.1-STABLE >> 10.1-STABLE >> >> >> --jau >> _______________________________________________ >> freebsd-ppc@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ppc >> To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org"