https://bugs.kde.org/show_bug.cgi?id=510840
--- Comment #2 from Florian Krohm <[email protected]> --- (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. -- You are receiving this mail because: You are watching all bug changes.
