Make disassembler more process-memory-oriented

[10110111]

I'm thinking of making a couple of DebuggerCore variants, which would use unusual (when compared to ptrace and kernel32 debugging API) backends like GDB and Bochs. But to take a better advantage of this, namely to be able to find out how the backend sees an instruction, it'd be good if CapstoneEDB (or something better named) had an interface like Instruction(pid,address) instead of the current Instruction(bytesInDebuggerMemory,address) (in this case we'd of course lose the ability to inspect the instruction, but this mode can still be useful).
Do you see any reasons why this shouldn't be done to the EDB's disassembler interface?
OTOH, this is only needed for QDisassemblyView I think, so maybe it's better to just have an overloaded constructor for Instruction and just use it inside the disassembly view code?
In any case I guess the disassembler API should be made more extensible — something similar to the plugin-based IDebugger API.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[eteran]

Firstly, I like the idea of finding a good way to make the disassembler more of a plugin. I've thought about this for a while, but never settled on what felt like a good API for it.

That being said, this is interesting. Is it really just a matter of efficiency? Or is it something deeper?

I ask because even with the current API, we can read arbitrary memory from a PID using any API into a block of memory, and then disassemble it. Is the idea that we just want to be able to ask things like GDB "how would YOU disassemble this address?" Is there a specific goal you are striving for?

Just trying to figure out what the use case we're going after is.

[10110111]

Yes, the idea is to ask the backend how it would disassemble the address. I've not seen any easy way to disassemble bytes neither in GDB nor in Bochs — all one could do is write the bytes into debuggee address space and then use disassemble command.
The general use case is supporting an arch which EDB doesn't even know of — e.g. for comparison when porting etc.. But this would also be useful in Bochs because it'd show how Bochs interprets the instruction at hand (after its new disassembly engine becomes the default).