Re: [PATCH] disas: Remove libvixl disassembler

["Daniel P. Berrangé" <berrange@redhat.com>]

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
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|