Date: Wed, 18 Mar 2015 08:39:51 +0200 From: Jukka Ukkonen <jau789@gmail.com> To: Justin Hibbits <jrh29@alumni.cwru.edu> Cc: FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: Something missing perhaps? Message-ID: <55091DB7.7010601@gmail.com> In-Reply-To: <CAHSQbTBtQeoKLrhsrd7idE9O4W7GGfKx8dKUTgn5EeCUpAip6g@mail.gmail.com> References: <55082540.1020001@gmail.com> <CAHSQbTBtQeoKLrhsrd7idE9O4W7GGfKx8dKUTgn5EeCUpAip6g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jau789@gmail.com> 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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55091DB7.7010601>