Re: [systemd-devel] udev-212 and up on Sparc v8
On Mon, 23.06.14 11:59, Chase Rayfield (cusbr...@yahoo.com) wrote: I haven't inquired directly with the GCC mailing list. But it seems thier current stance is to implement the builtins for architectures that have the instructions to support them and require the architectures that do not to supply a library. Can you point me to some place where they declare that? Is that also their intention for C11 atomic ops? I'd be willing to add a patch to systemd that uses C11 atomic ops if they are available and falls back to gcc atomic ops otherwise. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev-212 and up on Sparc v8
On Sat, 21.06.14 09:05, Chase Rayfield (cusbr...@yahoo.com) wrote: If I interpret that correctly, systemd would need to define _sync_sub_and_fetch_4 when building for 32-bit processors which do not support the __sync_sub_and_fetch operation natively. Yes exactly... I think libatomic_ops can help with that and I have built it from git on Sparc v8 (This flag is required -DAO_NO_SPARC_V9). But I am not sure how to implement __sync_sub_and_fetch with it. Details on getting it to build here: https://github.com/ivmai/libatomic_ops/issues/9 I can give a systemd developer access to a box to fix this on if someone wants to give it a shot. I believe the reason GCC doesn't provide an implementation there are some pretty huge trade offs to be made with either performance or functionality. Thanks, but please work with the gcc developers to solve this generically for all gcc users, instead of work around this limitation in every individual project independently. It's certainly time much better spent. Thanks, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev-212 and up on Sparc v8
On 23/06/14 15:30, Lennart Poettering wrote: On Sat, 21.06.14 09:05, Chase Rayfield (cusbr...@yahoo.com) wrote: If I interpret that correctly, systemd would need to define _sync_sub_and_fetch_4 when building for 32-bit processors which do not support the __sync_sub_and_fetch operation natively. Yes exactly... I think libatomic_ops can help with that and I have built it from git on Sparc v8 (This flag is required -DAO_NO_SPARC_V9). But I am not sure how to implement __sync_sub_and_fetch with it. Details on getting it to build here: https://github.com/ivmai/libatomic_ops/issues/9 I can give a systemd developer access to a box to fix this on if someone wants to give it a shot. I believe the reason GCC doesn't provide an implementation there are some pretty huge trade offs to be made with either performance or functionality. Thanks, but please work with the gcc developers to solve this generically for all gcc users, instead of work around this limitation in every individual project independently. It's certainly time much better spent. Thanks, Lennart IIRC, he told me when we discussed at IRC that systemd-udevd was the showstopper, and rest of the 'core' system built fine. Mike seems to also think this should be solved in systemd, http://bugs.gentoo.org/show_bug.cgi?id=514016#c9 But, too bad this goes beyond my knowledge a bit :-/ :/ Thanks, Samuli ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev-212 and up on Sparc v8
On Mon, 23.06.14 16:11, Samuli Suominen (ssuomi...@gentoo.org) wrote: Thanks, but please work with the gcc developers to solve this generically for all gcc users, instead of work around this limitation in every individual project independently. It's certainly time much better spent. IIRC, he told me when we discussed at IRC that systemd-udevd was the showstopper, and rest of the 'core' system built fine. Sure. Again. It's sounds like time much better spend if you solve this atomic ops problems for all users of it (and believe me there are a number, especially outside of the 'core' system. PulseAudio for example being one which hwoever has ugly fallbacks to libatomic_ops, which are much slower and uglier, and pull in a dep). Mike seems to also think this should be solved in systemd, http://bugs.gentoo.org/show_bug.cgi?id=514016#c9 But, too bad this goes beyond my knowledge a bit :-/ Well, I am pretty sure the Gentoo SPARC people will have people who work on the toolchain (I am mean, if they have the task of porting an OS to an exotic/new arch, then they better have), and instead I am sure they will acknowledge that fixing this with one gcc patch for everybody instead of many patches for just one user would be much better and in total less work. Thanks, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev-212 and up on Sparc v8
On Mon, Jun 23, 2014 at 9:25 AM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 23.06.14 16:11, Samuli Suominen (ssuomi...@gentoo.org) wrote: Thanks, but please work with the gcc developers to solve this generically for all gcc users, instead of work around this limitation in every individual project independently. It's certainly time much better spent. IIRC, he told me when we discussed at IRC that systemd-udevd was the showstopper, and rest of the 'core' system built fine. Sure. Again. It's sounds like time much better spend if you solve this atomic ops problems for all users of it (and believe me there are a number, especially outside of the 'core' system. PulseAudio for example being one which hwoever has ugly fallbacks to libatomic_ops, which are much slower and uglier, and pull in a dep). I just want to point out that the GCC manual labels the __sync_* functions as being legacy functions, which would imply that a more modern alternative exists. Are they referring to atomic variables in C11, or something else? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev-212 and up on Sparc v8
I haven't inquired directly with the GCC mailing list. But it seems thier current stance is to implement the builtins for architectures that have the instructions to support them and require the architectures that do not to supply a library. Yes libatomic_ops is ugly but necessary unless the GCC developers change thier minds. I have been able to build it on Sparc v8 and it passes it's own testsuite. Sparc v8 doesn't have a CAS instruction in the spec so any implementation will be slow and ugly regardless but it should just work. @Mike It would be nice if C11 atomic ops worked on Sparc v8 but I expect they do not. On Monday, June 23, 2014 10:58 AM, Mike Gilbert flop...@gentoo.org wrote: On Mon, Jun 23, 2014 at 9:25 AM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 23.06.14 16:11, Samuli Suominen (ssuomi...@gentoo.org) wrote: Thanks, but please work with the gcc developers to solve this generically for all gcc users, instead of work around this limitation in every individual project independently. It's certainly time much better spent. IIRC, he told me when we discussed at IRC that systemd-udevd was the showstopper, and rest of the 'core' system built fine. Sure. Again. It's sounds like time much better spend if you solve this atomic ops problems for all users of it (and believe me there are a number, especially outside of the 'core' system. PulseAudio for example being one which hwoever has ugly fallbacks to libatomic_ops, which are much slower and uglier, and pull in a dep). I just want to point out that the GCC manual labels the __sync_* functions as being legacy functions, which would imply that a more modern alternative exists. Are they referring to atomic variables in C11, or something else? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev-212 and up on Sparc v8
I have attached the output of export CFLAGS=-mcpu=v8 ; ./configure make for systemd-214 Hopefully that will be more helpful. Chase Rayfield On Saturday, June 21, 2014 1:57 AM, Samuli Suominen ssuomi...@gentoo.org wrote: On 21/06/14 08:38, Chase Rayfield wrote: udev up to version 208 builds correctly on Sparc v8. However 212 and greater does not. Complete build logs of 208 and 214 can be found here: https://bugs.gentoo.org/show_bug.cgi?id=514016 Any suggestions or alternatives to how we can fix this would be appreciated. This affects old Sun hardware, Leon Sparc, and the sparc implementation being developed at temlib.org it may also affect other architectures that I am not aware of. Thanks, Chase Rayfield When I suggested you report this to the mailing list, I expected you to extract systemd tarball, run export CFLAGS=-mcpu=v8, ./configure and make And post the output from that here I also didn't expect the bug to be referenced, but instead the relavent information posted here, so non-Gentoo people don't have to parse the Gentoo-specific bug Sorry, I should have been more clear about it Thanks, Samuli ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel./configure checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... 64 checking whether to enable maintainer-specific portions of Makefiles... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking whether make supports nested variables... yes checking how to create a pax tar archive... gnutar checking dependency style of gcc... gcc3 checking whether make supports nested variables... (cached) yes checking build system type... sparc64-unknown-linux-gnu checking host system type... sparc64-unknown-linux-gnu checking how to print strings... printf checking for a sed that does not truncate output... /bin/sed checking for fgrep... /bin/grep -F checking for ld used by gcc... /usr/sparc-unknown-linux-gnu/bin/ld checking if the linker (/usr/sparc-unknown-linux-gnu/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 1572864 checking whether the shell understands some XSI constructs... yes checking whether the shell understands +=... yes checking how to convert sparc64-unknown-linux-gnu file names to sparc64-unknown-linux-gnu format... func_convert_file_noop checking how to convert sparc64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop checking for /usr/sparc-unknown-linux-gnu/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for dlltool... no checking how to associate runtime and link libraries... printf %s\n checking for ar... ar checking for archiver @FILE support... @ checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from gcc object... ok checking for sysroot... no checking for mt... no checking if : is a manifest tool... no checking for dlfcn.h... yes checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC -DPIC checking if gcc PIC flag -fPIC -DPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker
Re: [systemd-devel] udev-212 and up on Sparc v8
El 21/06/14 01:38, Chase Rayfield escribió: udev up to version 208 builds correctly on Sparc v8. However 212 and greater does not. Complete build logs of 208 and 214 can be found here: https://bugs.gentoo.org/show_bug.cgi?id=514016 Any suggestions or alternatives to how we can fix this would be appreciated. This affects old Sun hardware, Leon Sparc, and the sparc implementation being developed at temlib.org it may also affect other architectures that I am not aware of. Thanks, Chase Rayfield Not a systemd problem. please ix your tool-chain. systemd does not even use __sync_sub_and_fetch_4(), this is a function that ought to be proviided by the compiler or libgcc . ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev-212 and up on Sparc v8
On Sat, Jun 21, 2014 at 10:04 AM, Cristian Rodríguez crrodrig...@opensuse.org wrote: El 21/06/14 01:38, Chase Rayfield escribió: udev up to version 208 builds correctly on Sparc v8. However 212 and greater does not. Complete build logs of 208 and 214 can be found here: https://bugs.gentoo.org/show_bug.cgi?id=514016 Any suggestions or alternatives to how we can fix this would be appreciated. This affects old Sun hardware, Leon Sparc, and the sparc implementation being developed at temlib.org it may also affect other architectures that I am not aware of. Thanks, Chase Rayfield Not a systemd problem. please ix your tool-chain. systemd does not even use __sync_sub_and_fetch_4(), this is a function that ought to be proviided by the compiler or libgcc . systemd does use __sync_sub_and_fetch, which probably gets mapped to __sync_sub_and_fetch_4 somewhere. src/shared/refcnt.h:#define REFCNT_DEC(r) (__sync_sub_and_fetch((r)._value, 1)) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev-212 and up on Sparc v8
On Sat, Jun 21, 2014 at 11:31 AM, Mike Gilbert flop...@gentoo.org wrote: On Sat, Jun 21, 2014 at 10:04 AM, Cristian Rodríguez crrodrig...@opensuse.org wrote: El 21/06/14 01:38, Chase Rayfield escribió: udev up to version 208 builds correctly on Sparc v8. However 212 and greater does not. Complete build logs of 208 and 214 can be found here: https://bugs.gentoo.org/show_bug.cgi?id=514016 Any suggestions or alternatives to how we can fix this would be appreciated. This affects old Sun hardware, Leon Sparc, and the sparc implementation being developed at temlib.org it may also affect other architectures that I am not aware of. Thanks, Chase Rayfield Not a systemd problem. please ix your tool-chain. systemd does not even use __sync_sub_and_fetch_4(), this is a function that ought to be proviided by the compiler or libgcc . systemd does use __sync_sub_and_fetch, which probably gets mapped to __sync_sub_and_fetch_4 somewhere. src/shared/refcnt.h:#define REFCNT_DEC(r) (__sync_sub_and_fetch((r)._value, 1)) Also, from the gcc manual: https://gcc.gnu.org/onlinedocs/gcc-4.7.4/gcc/_005f_005fsync-Builtins.html Not all operations are supported by all target processors. If a particular operation cannot be implemented on the target processor, a warning will be generated and a call an external function will be generated. The external function will carry the same name as the builtin, with an additional suffix ‘_n’ where n is the size of the data type. If I interpret that correctly, systemd would need to define _sync_sub_and_fetch_4 when building for 32-bit processors which do not support the __sync_sub_and_fetch operation natively. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev-212 and up on Sparc v8
If I interpret that correctly, systemd would need to define _sync_sub_and_fetch_4 when building for 32-bit processors which do not support the __sync_sub_and_fetch operation natively. Yes exactly... I think libatomic_ops can help with that and I have built it from git on Sparc v8 (This flag is required -DAO_NO_SPARC_V9). But I am not sure how to implement __sync_sub_and_fetch with it. Details on getting it to build here: https://github.com/ivmai/libatomic_ops/issues/9 I can give a systemd developer access to a box to fix this on if someone wants to give it a shot. I believe the reason GCC doesn't provide an implementation there are some pretty huge trade offs to be made with either performance or functionality. Chase___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev-212 and up on Sparc v8
On 21/06/14 08:38, Chase Rayfield wrote: udev up to version 208 builds correctly on Sparc v8. However 212 and greater does not. Complete build logs of 208 and 214 can be found here: https://bugs.gentoo.org/show_bug.cgi?id=514016 Any suggestions or alternatives to how we can fix this would be appreciated. This affects old Sun hardware, Leon Sparc, and the sparc implementation being developed at temlib.org it may also affect other architectures that I am not aware of. Thanks, Chase Rayfield When I suggested you report this to the mailing list, I expected you to extract systemd tarball, run export CFLAGS=-mcpu=v8, ./configure and make And post the output from that here I also didn't expect the bug to be referenced, but instead the relavent information posted here, so non-Gentoo people don't have to parse the Gentoo-specific bug Sorry, I should have been more clear about it Thanks, Samuli ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
