Re: Re: [RFC PATCH 2/2] gitlab-ci: Add a job building TCI with Clang

[Wataru Ashihara <wataash@wataash.com>]

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é <f4bug@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