Open commial opened 8 years ago
Hi,
If we use Container as a wrapper over disasmEngine, we could just use disasmEngine.symbol_pool as Container's symbol_pool. That would look like this:
def __init__(....):
.....
self.disasmEngine = Machine(self.arch).dis_engine(self.bin_stream)
and then:
@property
def symbol_pool(self):
"asm_symbol_pool instance preloaded with container and disasmEngine symbols (if any)"
return self.disasmEngine.symbol_pool.
Container could also have a dis_multibloc function that only call dis_multibloc from its disasmEngine, resolve addresses if asked, and then return disassembled blocks.
I have started to think about it (see my fork), but as I am relatively new on miasm, I'm trying to figure all the side effects that could bring.
Well, following this thinking, we may end with a Container
wrapping all API like a "catch all" object, which seems a bad implication for the maintainability and the usability of the code. I prefer having different classes doing one thing, and doing it well (or at least, trying to do it well).
We are currently testing a few other way of doing, such as instantiating a crafted symbol_pool
from Container
and using it instead of wrapping symbol_pool
API in Container
; and the opposite way, that is to say replacing all symbol_pool
uses by call on Container
...
So, to be continued :smile:
This issue continues the debate of #343 .
From the current state, a few steps are needed before applying the described solution:
dis_bloc
anddis_bloc_all
intodisasmEngine
, and remove their use outside ofdisasmEngine
(as injitter
...)Container
to its internalbin_stream
disasmEngine
and their caller to always useContainer
, and no morepool_bin
,symbol_pool
, ...Container
to gen a label from itssymbol_pool
, and use it indis_bloc
Once these steps are done, we can override the gen label method in
ContainerELF
to use symbols and relative symbols. In addition, once these work done, we also can introduce aContainerIDA
mapping symbols to the one of IDA,arch
to the IDA architecture, ...