qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PULL 00/53] Misc patches for QEMU 5.1 soft freeze


From: Claudio Fontana
Subject: Re: [PULL 00/53] Misc patches for QEMU 5.1 soft freeze
Date: Wed, 8 Jul 2020 20:34:07 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]