Open SimonKagstrom opened 11 years ago
Yeah, I had considered fixing the PC-rel targets as objdump does, but decided that it would make more sense for the application to do that if it wanted.
It might make sense to have a function that returns the jump target (or NULL, which admittedly sucks as an error-return value) for an instruction. That would be useful for analysis, but not for display.
For me, both are actually important. My application is just a graphical disassembler, so I'd really like to have insn->ascii have the fixed up targets. However, it also displays branches as arrows, so there it also needs jump target addresses.
For that particular case, I resolve it myself with
if (insn->target->category == opdis_op_cat_immediate)
targetAddress = m_startAddress + (uint64_t)insn->target->value.immediate.vma;
// Assume a flat address space model
else if (insn->target->category == opdis_op_cat_absolute)
targetAddress = (uint64_t)insn->target->value.abs.offset;
Objdump resolves addresses used in instructions when possible, so that PC-relative jumps etc display the target address. I think this would be good to have for libopdis as well.
There is a print_address callback in the struct disassemble_info structure in libopcodes, which objdump uses for this purpose. I'm not sure if this can be implemented directly in libopdis, or if the same functionality would have to be exported outwards. At least objdump looks up symbols etc which I guess should be kept outside of libopdis.
I guess in most cases, it would be fine to simply resolve the PC-relative addresses transparently, perhaps as a setter-function in opdis.