What to do with the nanomips disassembler (was: [PATCH] disas: Remove libvixl disassembler)

[Thomas Huth]

On 09/06/2022 16.15, Claudio Fontana wrote:
> 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:
[...]
> > > > > > > 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.
> >
> > I'll take a look at it, maybe I can turn it to C fairly quickly.
>
> It seems to be generated code, getting the original authors involved in the 
> thread.

Not sure whether the original mips folks are still around ... but the folks 
from MediaTek recently expressed their interest in nanoMIPS:


https://lore.kernel.org/qemu-devel/20220504110403.613168-8-stefan.pejic@syrmia.com/

Maybe they could help with the nanoMIPS disassembler?

I know it's likely a lot of work, but the best solution would maybe be to 
add nanoMIPS support to capstone instead, then other projects could benefit 
from the support in this library, too...

If I googled that right, there is a LLVM implementation of nanoMIPS 
available here:


https://github.com/milos1397/nanomips-outliner/tree/master/llvm/lib/Target/Mips

... so maybe that could be used as input for capstone (which is based on llvm)?

 Thomas