Re: [PATCH v2 4/8] configure: Disable out-of-line atomic operations on Aarch64

2022-03-06 Thread Philippe Mathieu-Daudé

On 18/2/22 16:36, Paolo Bonzini wrote:

On 2/18/22 02:46, Richard Henderson wrote:


I don't have gobjc/g++ installed, so ./configure defaulted to Clang to
compile these languages, but compiled C files using GCC. At the end 
the

Clang linker is used (the default c++ symlink).


This is another form of compiler mis-configuration.
If you don't have g++ to go with gcc, use --cxx=false to avoid picking 
up a different compiler.


This would be the kind of problem that this test is trying to cover:

     if do_cxx $CXXFLAGS $EXTRA_CXXFLAGS $CONFIGURE_CXXFLAGS 
$QEMU_CXXFLAGS -o $TMPE $TMPCXX $TMPO $QEMU_LDFLAGS; then

     # C++ compiler $cxx works ok with C compiler $cc
     :
     else
     echo "C++ compiler $cxx does not work with C compiler $cc"
     echo "Disabling C++ specific optional code"
     cxx=
     fi

In the past it detected issues with libasan/libtsan incompatibilities.
We should either add a test for atomic operations, or just drop the
test.


We shouldn't assume gcc is GCC:

$ c++ --version
Apple clang version 13.0.0 (clang-1300.0.29.30)
Target: arm64-apple-darwin21.3.0
Thread model: posix
InstalledDir: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin


$ g++ --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
--with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1

Apple clang version 13.0.0 (clang-1300.0.29.30)
Target: arm64-apple-darwin21.3.0
Thread model: posix
InstalledDir: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin


$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
--with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1

Apple clang version 13.0.0 (clang-1300.0.29.30)
Target: arm64-apple-darwin21.3.0
Thread model: posix
InstalledDir: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin


$ clang --version
Apple clang version 13.0.0 (clang-1300.0.29.30)
Target: arm64-apple-darwin21.3.0
Thread model: posix
InstalledDir: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin




Re: [PATCH v2 4/8] configure: Disable out-of-line atomic operations on Aarch64

2022-02-18 Thread Paolo Bonzini

On 2/15/22 18:01, Philippe Mathieu-Daudé via wrote:

+
+case "$cpu" in
+  aarch64)
+write_c_skeleton;
+if compile_prog "$CPU_CFLAGS -Werror -mno-outline-atomics" "" ; then
+  CPU_CFLAGS="-mno-outline-atomics $CPU_CFLAGS"
+fi
+;;


Apart from the question of whether/how to work around this issue, this 
should not be added to CPU_CFLAGS.  CPU_CFLAGS is only for things that 
change the ABI.


Paolo



Re: [PATCH v2 4/8] configure: Disable out-of-line atomic operations on Aarch64

2022-02-18 Thread Paolo Bonzini

On 2/18/22 02:46, Richard Henderson wrote:


I don't have gobjc/g++ installed, so ./configure defaulted to Clang to
compile these languages, but compiled C files using GCC. At the end the
Clang linker is used (the default c++ symlink).


This is another form of compiler mis-configuration.
If you don't have g++ to go with gcc, use --cxx=false to avoid picking 
up a different compiler.


This would be the kind of problem that this test is trying to cover:

if do_cxx $CXXFLAGS $EXTRA_CXXFLAGS $CONFIGURE_CXXFLAGS $QEMU_CXXFLAGS -o 
$TMPE $TMPCXX $TMPO $QEMU_LDFLAGS; then
# C++ compiler $cxx works ok with C compiler $cc
:
else
echo "C++ compiler $cxx does not work with C compiler $cc"
echo "Disabling C++ specific optional code"
cxx=
fi

In the past it detected issues with libasan/libtsan incompatibilities.
We should either add a test for atomic operations, or just drop the
test.

Paolo



Re: [PATCH v2 4/8] configure: Disable out-of-line atomic operations on Aarch64

2022-02-17 Thread Richard Henderson

On 2/17/22 04:18, Philippe Mathieu-Daudé wrote:

On 16/2/22 17:42, Akihiko Odaki wrote:

On 2022/02/17 0:08, Philippe Mathieu-Daudé wrote:

On 16/2/22 11:19, Richard Henderson wrote:
These should have been supplied by libgcc.a, which we're supposed to be linking 
against. Something is wrong with your installation.


I don't have gobjc/g++ installed, so ./configure defaulted to Clang to
compile these languages, but compiled C files using GCC. At the end the
Clang linker is used (the default c++ symlink).


This is another form of compiler mis-configuration.
If you don't have g++ to go with gcc, use --cxx=false to avoid picking up a different 
compiler.



Could there be a mismatch between Clang (-mno-outline-atomics) and GCC
(-moutline-atomics)?


I have no idea if those options do the same thing.

I think you have to instruct Clang to use libgcc instead of compiler-rt and link the 
objects with GCC. Here is the documentation of Clang about the runtime I could find:

https://clang.llvm.org/docs/Toolchain.html#libgcc-s-gnu


Thanks for the pointer. And the next section is
https://clang.llvm.org/docs/Toolchain.html#atomics-library :)

   Clang does not currently automatically link against libatomic when
    using libgcc_s. You may need to manually add -latomic to support
   this configuration when using non-native atomic operations (if you
   see link errors referring to __atomic_* functions).

I'll try that.


-moutline-atomics is *not* the same as libatomic.
You should not need libatomic at all.


r~



Re: [PATCH v2 4/8] configure: Disable out-of-line atomic operations on Aarch64

2022-02-16 Thread Peter Maydell
On Wed, 16 Feb 2022 at 17:18, Philippe Mathieu-Daudé  wrote:
> Thanks for the pointer. And the next section is
> https://clang.llvm.org/docs/Toolchain.html#atomics-library :)
>
>Clang does not currently automatically link against libatomic when
> using libgcc_s. You may need to manually add -latomic to support
>this configuration when using non-native atomic operations (if you
>see link errors referring to __atomic_* functions).

We deliberately don't link against libatomic at the moment...

-- PMM



Re: [PATCH v2 4/8] configure: Disable out-of-line atomic operations on Aarch64

2022-02-16 Thread Philippe Mathieu-Daudé via

On 16/2/22 17:42, Akihiko Odaki wrote:

On 2022/02/17 0:08, Philippe Mathieu-Daudé wrote:

On 16/2/22 11:19, Richard Henderson wrote:

On 2/16/22 04:01, Philippe Mathieu-Daudé via wrote:

GCC 10.1 introduced the -moutline-atomics option on Aarch64.
This options is enabled by default, and triggers a link failure:

   Undefined symbols for architecture arm64:
 "___aarch64_cas1_acq_rel", referenced from:
 _qmp_migrate_recover in migration_migration.c.o
 _cpu_atomic_cmpxchgb_mmu in accel_tcg_cputlb.c.o
 _cpu_atomic_fetch_sminb_mmu in accel_tcg_cputlb.c.o
 _cpu_atomic_fetch_uminb_mmu in accel_tcg_cputlb.c.o
 _cpu_atomic_fetch_smaxb_mmu in accel_tcg_cputlb.c.o
 _cpu_atomic_fetch_umaxb_mmu in accel_tcg_cputlb.c.o
 _cpu_atomic_smin_fetchb_mmu in accel_tcg_cputlb.c.o
 ...
 "___aarch64_ldadd4_acq_rel", referenced from:
 _multifd_recv_new_channel in migration_multifd.c.o
 _monitor_event in monitor_hmp.c.o
 _handle_hmp_command in monitor_hmp.c.o
 _colo_compare_finalize in net_colo-compare.c.o
 _flatview_unref in softmmu_memory.c.o
 _virtio_scsi_hotunplug in hw_scsi_virtio-scsi.c.o
 _tcg_register_thread in tcg_tcg.c.o
 ...
 "___aarch64_swp4_acq", referenced from:
 _qemu_spin_lock in softmmu_cpu-timers.c.o
 _cpu_get_ticks in softmmu_cpu-timers.c.o
 _qemu_spin_lock in softmmu_icount.c.o
 _cpu_exec in accel_tcg_cpu-exec.c.o
 _page_flush_tb_1.isra.0 in accel_tcg_translate-all.c.o
 _page_entry_lock in accel_tcg_translate-all.c.o
 _do_tb_phys_invalidate in accel_tcg_translate-all.c.o
 ...

QEMU implements its own atomic operations using C11 builtin helpers.
Disable the GCC out-of-line atomic ops.

Signed-off-by: Philippe Mathieu-Daudé
---
Cc: Stefan Hajnoczi
Cc: Paolo Bonzini

Clearly out of my understanding, but at least it links and the qtests
pass.
---
  configure | 12 
  1 file changed, 12 insertions(+)


These should have been supplied by libgcc.a, which we're supposed to 
be linking against. Something is wrong with your installation.


I don't have gobjc/g++ installed, so ./configure defaulted to Clang to
compile these languages, but compiled C files using GCC. At the end the
Clang linker is used (the default c++ symlink).

Could there be a mismatch between Clang (-mno-outline-atomics) and GCC
(-moutline-atomics)?


I think you have to instruct Clang to use libgcc instead of compiler-rt 
and link the objects with GCC. Here is the documentation of Clang about 
the runtime I could find:

https://clang.llvm.org/docs/Toolchain.html#libgcc-s-gnu


Thanks for the pointer. And the next section is
https://clang.llvm.org/docs/Toolchain.html#atomics-library :)

  Clang does not currently automatically link against libatomic when
   using libgcc_s. You may need to manually add -latomic to support
  this configuration when using non-native atomic operations (if you
  see link errors referring to __atomic_* functions).

I'll try that.



Re: [PATCH v2 4/8] configure: Disable out-of-line atomic operations on Aarch64

2022-02-16 Thread Akihiko Odaki

On 2022/02/17 0:08, Philippe Mathieu-Daudé wrote:

On 16/2/22 11:19, Richard Henderson wrote:

On 2/16/22 04:01, Philippe Mathieu-Daudé via wrote:

GCC 10.1 introduced the -moutline-atomics option on Aarch64.
This options is enabled by default, and triggers a link failure:

   Undefined symbols for architecture arm64:
 "___aarch64_cas1_acq_rel", referenced from:
 _qmp_migrate_recover in migration_migration.c.o
 _cpu_atomic_cmpxchgb_mmu in accel_tcg_cputlb.c.o
 _cpu_atomic_fetch_sminb_mmu in accel_tcg_cputlb.c.o
 _cpu_atomic_fetch_uminb_mmu in accel_tcg_cputlb.c.o
 _cpu_atomic_fetch_smaxb_mmu in accel_tcg_cputlb.c.o
 _cpu_atomic_fetch_umaxb_mmu in accel_tcg_cputlb.c.o
 _cpu_atomic_smin_fetchb_mmu in accel_tcg_cputlb.c.o
 ...
 "___aarch64_ldadd4_acq_rel", referenced from:
 _multifd_recv_new_channel in migration_multifd.c.o
 _monitor_event in monitor_hmp.c.o
 _handle_hmp_command in monitor_hmp.c.o
 _colo_compare_finalize in net_colo-compare.c.o
 _flatview_unref in softmmu_memory.c.o
 _virtio_scsi_hotunplug in hw_scsi_virtio-scsi.c.o
 _tcg_register_thread in tcg_tcg.c.o
 ...
 "___aarch64_swp4_acq", referenced from:
 _qemu_spin_lock in softmmu_cpu-timers.c.o
 _cpu_get_ticks in softmmu_cpu-timers.c.o
 _qemu_spin_lock in softmmu_icount.c.o
 _cpu_exec in accel_tcg_cpu-exec.c.o
 _page_flush_tb_1.isra.0 in accel_tcg_translate-all.c.o
 _page_entry_lock in accel_tcg_translate-all.c.o
 _do_tb_phys_invalidate in accel_tcg_translate-all.c.o
 ...

QEMU implements its own atomic operations using C11 builtin helpers.
Disable the GCC out-of-line atomic ops.

Signed-off-by: Philippe Mathieu-Daudé
---
Cc: Stefan Hajnoczi
Cc: Paolo Bonzini

Clearly out of my understanding, but at least it links and the qtests
pass.
---
  configure | 12 
  1 file changed, 12 insertions(+)


These should have been supplied by libgcc.a, which we're supposed to 
be linking against. Something is wrong with your installation.


I don't have gobjc/g++ installed, so ./configure defaulted to Clang to
compile these languages, but compiled C files using GCC. At the end the
Clang linker is used (the default c++ symlink).

Could there be a mismatch between Clang (-mno-outline-atomics) and GCC
(-moutline-atomics)?


I think you have to instruct Clang to use libgcc instead of compiler-rt 
and link the objects with GCC. Here is the documentation of Clang about 
the runtime I could find:

https://clang.llvm.org/docs/Toolchain.html#libgcc-s-gnu



Re: [PATCH v2 4/8] configure: Disable out-of-line atomic operations on Aarch64

2022-02-16 Thread Philippe Mathieu-Daudé via

On 16/2/22 11:19, Richard Henderson wrote:

On 2/16/22 04:01, Philippe Mathieu-Daudé via wrote:

GCC 10.1 introduced the -moutline-atomics option on Aarch64.
This options is enabled by default, and triggers a link failure:

   Undefined symbols for architecture arm64:
 "___aarch64_cas1_acq_rel", referenced from:
 _qmp_migrate_recover in migration_migration.c.o
 _cpu_atomic_cmpxchgb_mmu in accel_tcg_cputlb.c.o
 _cpu_atomic_fetch_sminb_mmu in accel_tcg_cputlb.c.o
 _cpu_atomic_fetch_uminb_mmu in accel_tcg_cputlb.c.o
 _cpu_atomic_fetch_smaxb_mmu in accel_tcg_cputlb.c.o
 _cpu_atomic_fetch_umaxb_mmu in accel_tcg_cputlb.c.o
 _cpu_atomic_smin_fetchb_mmu in accel_tcg_cputlb.c.o
 ...
 "___aarch64_ldadd4_acq_rel", referenced from:
 _multifd_recv_new_channel in migration_multifd.c.o
 _monitor_event in monitor_hmp.c.o
 _handle_hmp_command in monitor_hmp.c.o
 _colo_compare_finalize in net_colo-compare.c.o
 _flatview_unref in softmmu_memory.c.o
 _virtio_scsi_hotunplug in hw_scsi_virtio-scsi.c.o
 _tcg_register_thread in tcg_tcg.c.o
 ...
 "___aarch64_swp4_acq", referenced from:
 _qemu_spin_lock in softmmu_cpu-timers.c.o
 _cpu_get_ticks in softmmu_cpu-timers.c.o
 _qemu_spin_lock in softmmu_icount.c.o
 _cpu_exec in accel_tcg_cpu-exec.c.o
 _page_flush_tb_1.isra.0 in accel_tcg_translate-all.c.o
 _page_entry_lock in accel_tcg_translate-all.c.o
 _do_tb_phys_invalidate in accel_tcg_translate-all.c.o
 ...

QEMU implements its own atomic operations using C11 builtin helpers.
Disable the GCC out-of-line atomic ops.

Signed-off-by: Philippe Mathieu-Daudé
---
Cc: Stefan Hajnoczi
Cc: Paolo Bonzini

Clearly out of my understanding, but at least it links and the qtests
pass.
---
  configure | 12 
  1 file changed, 12 insertions(+)


These should have been supplied by libgcc.a, which we're supposed to be 
linking against. Something is wrong with your installation.


I don't have gobjc/g++ installed, so ./configure defaulted to Clang to
compile these languages, but compiled C files using GCC. At the end the
Clang linker is used (the default c++ symlink).

Could there be a mismatch between Clang (-mno-outline-atomics) and GCC
(-moutline-atomics)?



Re: [PATCH v2 4/8] configure: Disable out-of-line atomic operations on Aarch64

2022-02-16 Thread Richard Henderson

On 2/16/22 04:01, Philippe Mathieu-Daudé via wrote:

GCC 10.1 introduced the -moutline-atomics option on Aarch64.
This options is enabled by default, and triggers a link failure:

   Undefined symbols for architecture arm64:
 "___aarch64_cas1_acq_rel", referenced from:
 _qmp_migrate_recover in migration_migration.c.o
 _cpu_atomic_cmpxchgb_mmu in accel_tcg_cputlb.c.o
 _cpu_atomic_fetch_sminb_mmu in accel_tcg_cputlb.c.o
 _cpu_atomic_fetch_uminb_mmu in accel_tcg_cputlb.c.o
 _cpu_atomic_fetch_smaxb_mmu in accel_tcg_cputlb.c.o
 _cpu_atomic_fetch_umaxb_mmu in accel_tcg_cputlb.c.o
 _cpu_atomic_smin_fetchb_mmu in accel_tcg_cputlb.c.o
 ...
 "___aarch64_ldadd4_acq_rel", referenced from:
 _multifd_recv_new_channel in migration_multifd.c.o
 _monitor_event in monitor_hmp.c.o
 _handle_hmp_command in monitor_hmp.c.o
 _colo_compare_finalize in net_colo-compare.c.o
 _flatview_unref in softmmu_memory.c.o
 _virtio_scsi_hotunplug in hw_scsi_virtio-scsi.c.o
 _tcg_register_thread in tcg_tcg.c.o
 ...
 "___aarch64_swp4_acq", referenced from:
 _qemu_spin_lock in softmmu_cpu-timers.c.o
 _cpu_get_ticks in softmmu_cpu-timers.c.o
 _qemu_spin_lock in softmmu_icount.c.o
 _cpu_exec in accel_tcg_cpu-exec.c.o
 _page_flush_tb_1.isra.0 in accel_tcg_translate-all.c.o
 _page_entry_lock in accel_tcg_translate-all.c.o
 _do_tb_phys_invalidate in accel_tcg_translate-all.c.o
 ...

QEMU implements its own atomic operations using C11 builtin helpers.
Disable the GCC out-of-line atomic ops.

Signed-off-by: Philippe Mathieu-Daudé
---
Cc: Stefan Hajnoczi
Cc: Paolo Bonzini

Clearly out of my understanding, but at least it links and the qtests
pass.
---
  configure | 12 
  1 file changed, 12 insertions(+)


These should have been supplied by libgcc.a, which we're supposed to be linking against. 
Something is wrong with your installation.



r~



Re: [PATCH v2 4/8] configure: Disable out-of-line atomic operations on Aarch64

2022-02-15 Thread Akihiko Odaki
On Wed, Feb 16, 2022 at 2:01 AM Philippe Mathieu-Daudé  wrote:
>
> GCC 10.1 introduced the -moutline-atomics option on Aarch64.
> This options is enabled by default, and triggers a link failure:
>
>   Undefined symbols for architecture arm64:
> "___aarch64_cas1_acq_rel", referenced from:
> _qmp_migrate_recover in migration_migration.c.o
> _cpu_atomic_cmpxchgb_mmu in accel_tcg_cputlb.c.o
> _cpu_atomic_fetch_sminb_mmu in accel_tcg_cputlb.c.o
> _cpu_atomic_fetch_uminb_mmu in accel_tcg_cputlb.c.o
> _cpu_atomic_fetch_smaxb_mmu in accel_tcg_cputlb.c.o
> _cpu_atomic_fetch_umaxb_mmu in accel_tcg_cputlb.c.o
> _cpu_atomic_smin_fetchb_mmu in accel_tcg_cputlb.c.o
> ...
> "___aarch64_ldadd4_acq_rel", referenced from:
> _multifd_recv_new_channel in migration_multifd.c.o
> _monitor_event in monitor_hmp.c.o
> _handle_hmp_command in monitor_hmp.c.o
> _colo_compare_finalize in net_colo-compare.c.o
> _flatview_unref in softmmu_memory.c.o
> _virtio_scsi_hotunplug in hw_scsi_virtio-scsi.c.o
> _tcg_register_thread in tcg_tcg.c.o
> ...
> "___aarch64_swp4_acq", referenced from:
> _qemu_spin_lock in softmmu_cpu-timers.c.o
> _cpu_get_ticks in softmmu_cpu-timers.c.o
> _qemu_spin_lock in softmmu_icount.c.o
> _cpu_exec in accel_tcg_cpu-exec.c.o
> _page_flush_tb_1.isra.0 in accel_tcg_translate-all.c.o
> _page_entry_lock in accel_tcg_translate-all.c.o
> _do_tb_phys_invalidate in accel_tcg_translate-all.c.o
> ...
>
> QEMU implements its own atomic operations using C11 builtin helpers.
> Disable the GCC out-of-line atomic ops.
>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> Cc: Stefan Hajnoczi 
> Cc: Paolo Bonzini 
>
> Clearly out of my understanding, but at least it links and the qtests
> pass.
> ---
>  configure | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/configure b/configure
> index 06c03cebd3..3217aa22cb 100755
> --- a/configure
> +++ b/configure
> @@ -2826,6 +2826,18 @@ else
>avx512f_opt="no"
>  fi
>
> +#
> +# Disable out-of-line atomic operations.
> +
> +case "$cpu" in
> +  aarch64)
> +write_c_skeleton;
> +if compile_prog "$CPU_CFLAGS -Werror -mno-outline-atomics" "" ; then
> +  CPU_CFLAGS="-mno-outline-atomics $CPU_CFLAGS"
> +fi
> +;;
> +esac
> +
>  
>  # check if __[u]int128_t is usable.
>
> --
> 2.34.1
>

This change would (slightly) increase the code size and is harmful to
the other proper GCC installations. The flag should be specified by
the user (or the user should fix the GCC installation.)