Now that the valgrind license has changed, objdump can be integrated and used for disassembly in VEX. s390 goes first. That will remove all the stuff added in https://bugs.kde.org/show_bug.cgi?id=495817 Yay!
I have concerns about this line of action. * It sounds like it will involve importing a large amount of code for gains that are (to me at least) unclear. What problem will this solve? * I am concerned that decoupling the disassembly printing from generation of the IR will make it harder to debug new instruction front-end work. With the current code, it can be that mistakes in decoding the instruction become obvious because the printed disassembly is wrong. If we give disassembly printing to objdump then that possibility goes away; objdump will print a correct disassembly even if the generated IR is wrong.
(In reply to Julian Seward from comment #1) > I have concerns about this line of action. > > * It sounds like it will involve importing a large amount of code for gains > that are (to me at least) unclear. What problem will this solve? To give you an idea about the amount of code... I have done this for s390 back in March. There would be a new directory VEX/priv/objdump with this contents: 502 2907 21057 dis-asm.h 56 215 1914 dis-init.c 702 2447 19987 s390-dis.c 814 7130 49871 s390-opc.c 197 806 6128 s390.h 49 235 1672 stubs.h 2774 41087 309483 s390-opc.tab 5094 54827 410112 total With the exception of stubs.h those files come from various directories within binutils. With ifdeffery of course to keep the amount of imported code small. Not a lot of code I'd say. > What problem will this solve? It solves a double maintenance problem on s390. There are two places where we disassemble: when building IR and when emitting insns. This isn't much of a problem when disassembly means just writing out the mnemonic followed by the opcode fields. But if there are extended mnemonics (aka alternate spellings) which at the same time drop opcode fields then this becomes a pain (been there done that). s390 has *many* of those in particular with vector insns - some of them quite irregular in syntax. I've used objdump along valgrind occasionally when debugging something and find it quite convenient if disassembly looks the same everywhere. Added bonus: Come new insns you get the disassembly machinery for free. > * I am concerned that decoupling the disassembly printing from generation of > the IR will make it harder to debug new instruction front-end work. With > the > current code, it can be that mistakes in decoding the instruction become > obvious because the printed disassembly is wrong. If we give disassembly > printing to objdump then that possibility goes away; objdump will print a > correct disassembly even if the generated IR is wrong. True, but the wrong IR would probably also be found in the insn testcases. For s390 the problem does not exist (at least in the initial code drop it did not) because the decoder, IR generation and emit code was largely generated from a machine description. And quite possibly decoding s390 insns is much easier to do than for x86-64. Also note, that I am not saying that all architectures must do their disassembly with objdump. I can probably be convinced to do the work. But whether it should be done is the respective maintainer's or core developer's call not mine. For s390 it's a nobrainer.
> [..] new directory VEX/priv/objdump with this contents: > 5094 54827 410112 total Hmm, that's not as much new code as I had expected. > Added bonus: Come new insns you get the disassembly machinery for free. .. although you do presumably need to update the in-tree copy from time to time. > Also note, that I am not saying that all architectures must do their > disassembly with objdump. That wasn't clear from comment #0. If it's just s390, I take back my objection. I must be honest though and say, I don't think the balance between overall benefit and total-code-in-the-system for this change is favourable, and I wouldn't want it for the amd64 or arm64 front ends. And those back ends just `pp{AMD64,ARM64}Instr` the code they generate. But all that said, I am not a maintainer of any of this, so my opinion doesn't count for much. Others may well have different views.
Fixed in 370531396ad180a30332caa6a22bb08e836e266b for s390. Other architectures are left as an exercise.