Re: [RFC PATCH 0/3] Remove some of the old libopcode based disassemblers

[Thomas Huth <thuth@redhat.com>]

On 09/05/2022 14.20, Philippe Mathieu-Daudé wrote:
> On 12/4/22 18:58, Thomas Huth wrote:
>> Many of the disassemblers in the disas folder are based on old
>> versions from the GNU tools (libopcode, GDB, ...) that were still
>> licensed under the GPL v2. The GNU tools switched to GPL v3 at one
>> point in time, so QEMU is stuck with the old versions, i.e. these
>> files did not see much updates for new processors anymore. But
>> for most architectures, we're preferring the Capstone disassembler
>> now anyway, so the old libopcode disassemblers are also hardly
>> used anymore.
>>
>> I'm not 100% sure (thus this is marked as RFC), but I think we could
>> simply drop the old disassemblers nowadays, and hardly anybody would
>> miss them, since we now always embed capstone as a submodule anyway.
>> Or is there still an advantage in keeping these old files around?
>>
>> This RFC series tackles with s390, arm (32-bit) and i386 ... I wanted
>> to get some feedback first, but if we agree that these can be removed,
>> the sparc, mips and ppc disassemblers likely can be removed, too.
>> (I think we should keep m68k.c since Capstone does not have support
>> for Coldfire CPUs yet).
>>
>> Thomas Huth (3):
>>    disas: Remove old libopcode s390 disassembler
>>    disas: Remove old libopcode arm disassembler
>>    disas: Remove old libopcode i386 disassembler
> 
>>   disas/arm.c             | 4012 -----------------------
>>   disas/i386.c            | 6771 ---------------------------------------
>>   disas/s390.c            | 1892 -----------
> 
>>   10 files changed, 12700 deletions(-)
> 
> o_O Nice!
> 
> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>

Thanks, just a little bit too late - it's in my current pull request already :-)

By the way, what about MIPS? Could MIPS be switched to Capstone, too, so 
that we could finally remove disas/mips.c ? (We're not using capstone there 
yet, and MIPS has so many flavours, big and little endian, 32- and 64-bit 
... so that I'm unsure whether there was a reason for not using Capstone 
there, or whether it just hasn't been tried out yet?)

  Thomas