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 <th...@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
