Re: [Valgrind-developers] Switching to GPLv3+ for next release (Was: Using objdump code for disassembly)

[Florian K. <fl...@ei...>]

On 17.06.25 11:53, Mark Wielaard wrote:
> 
>> The motivation seemed to be about replacing Valgrind's disassembly code
>> with some third-party code. Which sounds like an enormously large and
>> invasive change.
> 
> The direct motivation was indeed Florian wanting to reuse binutils
> objdump code to support the many extended mnemonics for s390 vector
> insns. I believe he already has a working patch for that, so maybe he
> could post that so you can see if it is a sane approach.
> 

Yes, I do have a working patch for s390. But it is not a good example to show 
because it is not examplary. Most of the changes are in the guest_s390_toIR.c 
code which is organised quite differently from the other architectures because 
large parts of it were generated from a machine description at the time.
So let me explain for amd64.

guest_amd64_toIR.c
The macro DIP and its 912 invocations will go away. This change is largely 
mechanical but one would have to make sure that the macro arguments have no side 
effects.
In function disInstr_AMD64_WRK after handling the "special insns" there would be 
a call to amd64_disasm(guest_code + delta) which performs the disassembly using 
the machinery from objdump and writes the result via vex_vsprintf.

For arm, ppc, mips, etc. this will be similar because they also use the 
venerable DIP macro.

host_amd64_defs.c
At the end of function  emit_AMD64Instr  call amd64_disasm(buf) again to show 
the disassembled insn.

So the patch will be biggish but largely because lots of code will be removed.

I think it makes sense to consolidate the disassembly business this way. Future 
architectures will get it almost for free.
And I'd be willing to do the work if that is so desired.

    Florian