Re: [PATCH] disas: Remove libvixl disassembler

[Claudio Fontana]

On 6/9/22 13:27, Claudio Fontana wrote:
> On 6/9/22 10:57, Daniel P. Berrangé wrote:
>> On Thu, Jun 09, 2022 at 10:47:24AM +0200, Thomas Huth wrote:
>>> On 08/06/2022 17.51, Paolo Bonzini wrote:
>>>> On 6/3/22 19:35, Thomas Huth wrote:
>>>>> On 03/06/2022 19.26, Claudio Fontana wrote:
>>>>>> On 6/3/22 18:42, Thomas Huth wrote:
>>>>>>> The disassembly via capstone should be superiour to our old vixl
>>>>>>> sources nowadays, so let's finally cut this old disassembler out
>>>>>>> of the QEMU source tree.
>>>>>>>
>>>>>>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>>>>>>
>>>>>> agreed, one thought: at the time I added this thing, I had to
>>>>>> add C++ compilation support,
>>>>>> maybe something we can now drop if there are no more C++ users?
>>>>>
>>>>> I thought about that, too, but we still have disas/nanomips.cpp left
>>>>> and the Windows-related files in qga/vss-win32/* .
>>>>
>>>> That is pure C++ so it does not need the extra complication of "detect
>>>> whether the C and C++ compiler are ABI-compatible" (typically due to
>>>> different libasan/libtsan implementation between gcc and clang).  So
>>>> it's really just nanoMIPS that's left.
>>>
>>> Ok, so the next theoretical question is: If we get rid of the nanomips.cpp
>>> file or convert it to plain C, would we then simplify the code in configure
>>> again (and forbid C++ for the main QEMU code), or would we rather keep the
>>> current settings in case we want to re-introduce more C++ code again in the
>>> future?
>>
>> It doesn't feel very compelling to have just 1 source file that's
>> C++ in QEMU. I'm curious how we ended up with this nanomips.cpp
>> file - perhaps it originated from another project that was C++
>> based ?
>>
>> The code itself doesn't look like it especially needs to be using
>> C++. There's just 1 class there and every method is associated
>> with that class, and external entry point from the rest of QEMU
>> is just one boring method. Feels like it could easily have been
>> done in C.
>>
>> Personally I'd prefer it to be converted to C, and if we want to
>> add any C++ in future it should be justified & debated on its
>> merits, rather than as an artifact of any historical artifacts
>> such as the code in configure happening to still exist.
>>
>> With regards,
>> Daniel
> 
> I'll take a look at it, maybe I can turn it to C fairly quickly.
> 
> Ciao,
> 
> Claudio
> 

It seems to be generated code, getting the original authors involved in the 
thread.

Thanks,

Claudio