On 2021/01/21 22:27, Philippe Mathieu-Daudé wrote: > On 1/21/21 1:02 PM, Daniel P. Berrangé wrote: >> On Thu, Jan 21, 2021 at 12:48:21PM +0100, Philippe Mathieu-Daudé wrote: >>> On 1/21/21 12:21 PM, Daniel P. Berrangé wrote: >>>> On Thu, Jan 21, 2021 at 12:18:18PM +0100, Philippe Mathieu-Daudé wrote: >>>>> On 1/21/21 11:32 AM, Daniel P. Berrangé wrote: >>>>>> On Thu, Jan 21, 2021 at 11:08:29AM +0100, Thomas Huth wrote: >>>>>>> On 10/01/2021 17.27, Philippe Mathieu-Daudé wrote: >>>>>>>> Split the current GCC build-tci job in 2, and use Clang >>>>>>>> compiler in the new job. >>>>>>>> >>>>>>>> Signed-off-by: Philippe Mathieu-Daudé <f4...@amsat.org> >>>>>>>> --- >>>>>>>> RFC in case someone have better idea to optimize can respin this patch. >>>>>>>> >>>>>>>> .gitlab-ci.yml | 22 ++++++++++++++++++++-- >>>>>>>> 1 file changed, 20 insertions(+), 2 deletions(-) >>>>>>> >>>>>>> I'm not quite sure whether we should go down this road ... if we wanted >>>>>>> to >>>>>>> have full test coverage for clang, we'd need to duplicate *all* jobs to >>>>>>> run >>>>>>> them once with gcc and once with clang. And that would be just overkill. >>>>>>> >>>>>>> I think we already catch most clang-related problems with the clang jobs >>>>>>> that we already have in our CI, so problems like the ones that you've >>>>>>> tried >>>>>>> to address here should be very, very rare. So I'd rather vote for not >>>>>>> splitting the job here. >>>>>> >>>>>> We can't possibly cope with the fully expanded matrix of what are >>>>>> theoretically possible combinations. Thus I think we should be guided >>>>>> by what is expected real world usage by platforms we target. >>>>>> >>>>>> Essentially for any given distro we're testing on, our primary focus >>>>>> should be to use the toolchain that distro will build QEMU with. >>>>>> >>>>>> IOW, for Windows and Linux distros our primary focus should be GCC, >>>>>> while for macOS, and *BSD, our focus should be CLang. >>>>> >>>>> Sounds good. >>>>> >>>>> Do we need a TCI job on macOS then? >>>> >>>> TCI is only relevant if there is no native TCG host impl. >>>> >>>> macOS only targets aarch64 and x86_64, both of which have TCG, so there >>>> is no reason to use TCI on macOS AFAICT >>> >>> Yes, fine by me, but Wataru Ashihara reported the bug... ¯\_(ツ)_/¯ >> >> It doesn't look like they were using macOS - the message suggests >> Ubuntu host, and AFAIK, all Ubuntu architectures have support >> for TCG, so using TCI shouldn't have been required in the first >> place. >> >> I guess we could benefit from a TCI job of some kind that uses >> CLang on at least 1 platform, since none exists. >> >> This does yet again open up the question of whether we should be >> supporting TCI at all in this particular user's scenario though, >> since both KVM and TCG are available on Ubuntu x86 hosts already. > > I understand Stefan envisions other use cases for TCI, which is > why it is still maintained. See: > https://www.mail-archive.com/qemu-devel@nongnu.org/msg461131.html > > I agree with your previous comment: >> we should be guided by what is expected real world usage by >> platforms we target. Essentially for any given distro we're >> testing on, our primary focus should be to use the toolchain >> that distro will build QEMU with. > > This rarely used config does not justify adding yet another CI job. > > Thanks, > > Phil. > >
Actually I use TCI also on macOS. Like the use case quoted by Philippe, there're even other reasons to use TCI: 1. Learning TCG ops. 2. Debugging QEMU with gdb. e.g. diagnose codegen or stepping into helper functions from tci.c:tcg_qemu_tb_exec(). 3. Guest instruction tracing. TCI is faster than TCG or KVM when tracing the guest ops [1]. I guess qira is using TCI for this reason [2]. [1]: https://twitter.com/wata_ash/status/1352899988032942080 [2]: https://github.com/geohot/qira/blob/v1.3/tracers/qemu_build.sh#L55
