| Message ID | 20220412165836.355850-1-thuth@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Remove some of the old libopcode based disassemblers | expand |
On 4/12/22 09: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 > Reviewed-by: Richard Henderson <richard.henderson@linaro.org> r~
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>
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
On 9/5/22 15:18, Thomas Huth wrote: > 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 :-) NP, trying to catch up. > 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?) Last I remember is Richard saying "the capstone backend for mips is not in terribly good shape": https://lore.kernel.org/qemu-devel/0c7827df-c9d4-8dad-a38c-4881ce7dd22b@linaro.org/ My long-term hope is to switch to decodetree.
On 09/05/2022 15.42, Philippe Mathieu-Daudé wrote: > On 9/5/22 15:18, Thomas Huth wrote: [...] >> 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?) > > Last I remember is Richard saying "the capstone backend for mips is not > in terribly good shape": > https://lore.kernel.org/qemu-devel/0c7827df-c9d4-8dad-a38c-4881ce7dd22b@linaro.org/ That was in 2017, in the Capstone 3.x days ... maybe the situation has improved nowadays? Thomas
On 5/17/22 00:18, Thomas Huth wrote: > On 09/05/2022 15.42, Philippe Mathieu-Daudé wrote: >> On 9/5/22 15:18, Thomas Huth wrote: > [...] >>> 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?) >> >> Last I remember is Richard saying "the capstone backend for mips is not >> in terribly good shape": >> https://lore.kernel.org/qemu-devel/0c7827df-c9d4-8dad-a38c-4881ce7dd22b@linaro.org/ > > That was in 2017, in the Capstone 3.x days ... maybe the situation has improved nowadays? I don't see any substantive changes to the capstone mips backend since 2016. Almost all changes to arch/Mips since then are changes to function prototypes as the internal api evolves. I.e. just enough to keep it compiling. r~