cfircohen
commented
3 years ago Thanks for submitting this!
Presently, GetInstructionInfo and GetInstructionText architecture callbacks don't pass the current BinaryView object, and I couldn't find a direct way to get it.
I'll have to ask the Binary ninja forks how to address this, since I think this is currently a limitation in the API.
Didn't see this caveat in the docs, when there are multiple hexagon binaries open in the same binary ninja process, the disassembly for both of them at a specific address is the same despite them having different instructions.
Looks like packets are being cached by address and the plugin does not take into account the current BinaryView for that address. When a user opens a different hexagon binary and goes to the same address that was previously cached, instead of attempting to disassemble the current bytes, it disassembles the already cached bytes from the other tab.
Since it is cached at the plugin level and not the view, closing all hexagon tabs and opening up a new file (that isn't the original file cached) will still show the cached data from the initial file.