From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Petazzoni Date: Mon, 17 Apr 2017 15:45:32 +0200 Subject: [Buildroot] [PATCH 1/1] package/ffmpeg: depends on BR2_TOOLCHAIN_HAS_SYNC_4 In-Reply-To: References: <20170416114135.5080-1-bernd.kuhls@t-online.de> <20170416170537.5eee03e2@free-electrons.com> Message-ID: <20170417154532.2d410eac@free-electrons.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net Hello, Adding Waldemar, as there are some m68k toolchain questions/issues below. On Sun, 16 Apr 2017 20:10:36 +0200, Bernd Kuhls wrote: > afaics both __atomic and __sync functions are used at the same time, for > example: > http://git.videolan.org/? > p=ffmpeg.git;a=blob;f=libavcodec/mediacodecdec_common.c;h=2ec25c581d34f8f50 > 09b84161a79589dbaf21683;hb=refs/heads/release/3.3#l145 > > calls > > atomic_fetch_add(&s->refcount, 1); > > which translates to __sync_fetch_and_add: > http://git.videolan.org/? > p=ffmpeg.git;a=blob;f=compat/atomics/gcc/stdatomic.h;h=e13ed0e068b8fb50c7a6 > 9ca19a2600dae31a5a21;hb=refs/heads/release/3.3#l132 > > And http://git.videolan.org/? > p=ffmpeg.git;a=blob;f=libavutil/buffer.c;h=8d1aa5fa841eb934b9b1846672d9c43d > be23bca3;hb=refs/heads/release/3.3#l102 > > calls > > atomic_fetch_add_explicit(&buf->buffer->refcount, 1, memory_order_relaxed); > > which translates to atomic_fetch_add: > http://git.videolan.org/? > p=ffmpeg.git;a=blob;f=compat/atomics/gcc/stdatomic.h;h=e13ed0e068b8fb50c7a6 > 9ca19a2600dae31a5a21;hb=refs/heads/release/3.3#l135 I really would like to see a better investigation here, rather than one-off fixes. Looking at the ffmpeg configure script: if disabled stdatomic_h; then if enabled atomics_gcc; then add_cppflags '-I\$(SRC_PATH)/compat/atomics/gcc' elif enabled atomics_win32; then add_cppflags '-I\$(SRC_PATH)/compat/atomics/win32' elif enabled atomics_suncc; then add_cppflags '-I\$(SRC_PATH)/compat/atomics/suncc' elif enabled pthreads; then add_compat atomics/pthread/stdatomic.o add_cppflags '-I\$(SRC_PATH)/compat/atomics/pthread' else enabled threads && die "Threading is enabled, but no atomics are available" add_cppflags '-I\$(SRC_PATH)/compat/atomics/dummy' fi fi So, in our Linux case: - It tries to use if available - Otherwise, it uses the atomics/gcc built-ins, i.e __sync built-ins - Otherwise, it uses pthread based locks So, for the m68k case, why isn't the fallback to pthread locks not working? Also, if you look at the config.log for the m68k toolchain, you see: check_builtin stdatomic_h stdatomic.h atomic_int foo, bar = ATOMIC_VAR_INIT(-1); atomic_store(&foo, 0) check_code ld stdatomic.h atomic_int foo, bar = ATOMIC_VAR_INIT(-1); atomic_store(&foo, 0) cc check_ld cc check_cc BEGIN /tmp/ffconf.oqKy0y9w.c 1 #include 2 int main(void) { atomic_int foo, bar = ATOMIC_VAR_INIT(-1); atomic_store(&foo, 0); return 0; } END /tmp/ffconf.oqKy0y9w.c /home/thomas/projets/buildroot/output/host/usr/bin/m68k-linux-gcc -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 --sysroot=/home/thomas/projets/buildroot/output/host/usr/m68k-buildroot-uclinux-uclibc/sysroot -isysroot /home/thomas/projets/buildroot/output/host/usr/m68k-buildroot-uclinux-uclibc/sysroot -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -Wl,-elf2flt -static -std=c11 -fomit-frame-pointer -c -o /tmp/ffconf.5kFw4oXu.o /tmp/ffconf.oqKy0y9w.c So no error at all on , so why does it fall back to __sync built-ins? Also Waldemar, you marked __sync 4 bytes built-in as not available for m68k_cf (commit df00b174f6c965be52d58a7911cec74de1426f8d), but it seems to also fail on __atomic builtins with a gcc ICE. Has this issue been reported to upstream gcc? Buildroot currently assumes that the m68k toolchain provides __atomic built-ins. You can try to test the toolchain with the following C program: #include int main(void) { uint8_t a; uint16_t b; uint32_t c; uint64_t d; __sync_fetch_and_add(&a, 3); __sync_fetch_and_add(&b, 3); __sync_fetch_and_add(&c, 3); __sync_fetch_and_add(&d, 3); __sync_val_compare_and_swap(&a, 1, 2); __sync_val_compare_and_swap(&b, 1, 2); __sync_val_compare_and_swap(&c, 1, 2); __sync_val_compare_and_swap(&d, 1, 2); __atomic_add_fetch(&a, 3, __ATOMIC_RELAXED); __atomic_add_fetch(&b, 3, __ATOMIC_RELAXED); __atomic_add_fetch(&c, 3, __ATOMIC_RELAXED); __atomic_add_fetch(&d, 3, __ATOMIC_RELAXED); __atomic_compare_exchange_n(&a, &a, 2, 1, __ATOMIC_RELAXED, __ATOMIC_RELAXED); __atomic_compare_exchange_n(&b, &b, 2, 1, __ATOMIC_RELAXED, __ATOMIC_RELAXED); __atomic_compare_exchange_n(&c, &c, 2, 1, __ATOMIC_RELAXED, __ATOMIC_RELAXED); __atomic_compare_exchange_n(&d, &d, 2, 1, __ATOMIC_RELAXED, __ATOMIC_RELAXED); return 0; } Thanks, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com