On 7/8/20 8:25 PM, Claudio Fontana wrote: > 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 > >
So I guess if you could Peter, are you building there with --disable-tcg or with --enable-tcg when you got that error? Ciao, Claudio
