Message ID | 20220215170106.95848-5-f4bug@amsat.org (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | buildsys: More fixes to use GCC on macOS | expand |
On Wed, Feb 16, 2022 at 2:01 AM Philippe Mathieu-Daudé <f4bug@amsat.org> 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é <f4bug@amsat.org> > --- > Cc: Stefan Hajnoczi <stefanha@redhat.com> > Cc: Paolo Bonzini <pbonzini@redhat.com> > > 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.)
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é<f4bug@amsat.org> > --- > Cc: Stefan Hajnoczi<stefanha@redhat.com> > Cc: Paolo Bonzini<pbonzini@redhat.com> > > 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~
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é<f4bug@amsat.org> >> --- >> Cc: Stefan Hajnoczi<stefanha@redhat.com> >> Cc: Paolo Bonzini<pbonzini@redhat.com> >> >> 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)?
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é<f4bug@amsat.org> >>> --- >>> Cc: Stefan Hajnoczi<stefanha@redhat.com> >>> Cc: Paolo Bonzini<pbonzini@redhat.com> >>> >>> 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
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é<f4bug@amsat.org> >>>> --- >>>> Cc: Stefan Hajnoczi<stefanha@redhat.com> >>>> Cc: Paolo Bonzini<pbonzini@redhat.com> >>>> >>>> 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.
On Wed, 16 Feb 2022 at 17:18, Philippe Mathieu-Daudé <f4bug@amsat.org> 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
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~
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
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
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
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.
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é <f4bug@amsat.org> --- Cc: Stefan Hajnoczi <stefanha@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Clearly out of my understanding, but at least it links and the qtests pass. --- configure | 12 ++++++++++++ 1 file changed, 12 insertions(+)