On 7/8/20 7:03 PM, Claudio Fontana wrote: > On 7/8/20 6:55 PM, Paolo Bonzini wrote: >> On 08/07/20 18:45, Claudio Fontana wrote: >>> C++ is used to link the final qemu-system binary and on my system c++ has >>> LTO: >>> >>> c++ -v >>> Using built-in specs. >>> COLLECT_GCC=c++ >>> COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/7/lto-wrapper >>> OFFLOAD_TARGET_NAMES=hsa:nvptx-none >>> Target: x86_64-suse-linux >>> Configured with: ../configure --prefix=/usr --infodir=/usr/share/info >>> --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 >>> --enable-languages=c,c++,objc,fortran,obj-c++,ada,go >>> --enable-offload-targets=hsa,nvptx-none=/usr/nvptx-none, >>> --without-cuda-driver --enable-checking=release --disable-werror >>> --with-gxx-include-dir=/usr/include/c++/7 --enable-ssp --disable-libssp >>> --disable-libvtv --disable-libcc1 --disable-plugin >>> --with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' >>> --with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new >>> --disable-libstdcxx-pch --enable-version-specific-runtime-libs >>> --with-gcc-major-version-only --enable-linker-build-id --enable-linux-futex >>> --enable-gnu-indirect-function --program-suffix=-7 >>> --without-system-libunwind --enable-multilib --with-arch-32=x86-64 >>> --with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux >>> Thread model: posix >>> gcc version 7.5.0 (SUSE Linux) >>> >>> >>> I checked cc but did not think to check c++ . I will find a way to disable >>> this thing and will correct the patch accordingly. >> >> Having LTO support is not the same thing as having it enabled. Are you >> compiling and linking with "-flto"? >> >> Paolo >> > > no, the compilation and link stage do not show this explicit parameter. I am > puzzled. > > C >
This is really weird, as I cannot reproduce it. What I did notice is that all the code that directly or indirectly uses the functions is under an if (0) ( ) since tcg_enabled is the constant 0. By "indirectly" I mean that the static void qemu_tcg_cpu_thread_fn() function that calls those is referenced only by static void qemu_tcg_init_vcpu(), which is called only under an if (0), ie if (tcg_enabled()). For me this builds with --disable-tcg and with --enable-tcg . Maybe the issue is actually the name clash of the stub and the module? I admit I am not familiar with the rationale of why the stubs are all built regardless, could we have that icount.o from stubs/ is replacing softmmu/icount.o to cause this? Thanks, Claudio
