On Thu, Jun 9, 2022 at 10:34AM, Thomas Huth wrote: > 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.pe...@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__;!!CTRNKA9wMg0ARbw!ypaF-7vGkOBh5G3xybGwIuJdGpUfrMavQlYF_4T9iocgw5x994tABF_B_RsCJIdqY4vwVzA$ > > > ... so maybe that could be used as input for capstone (which is based on > llvm)? > > Thomas
Yes, we are working on an LLVM port for nanoMIPS. It's functionally complete and pretty usable, although we're still tuning performance. The more official location is https://github.com/MediaTek-Labs/llvm-project. However, for now we're still using the binutils assembler; there's no encoding information in the current LLVM description. We have tentative plans to work on encoding and integrated-as later this year. Correct me if I'm wrong, but I would assume that, before that's available, it's not feasible to use capstone? Regardless, I think we can look at converting the existing disassembler from C++ to C. That would address the current concern, right? -Vince
