jrozner / msp430-asm Goto Github PK

This code has been rewritten a number of times and there are slight difference between what downstream providers show vs this. We should verify we're displaying all the correct data in what makes sense here.

Using an i16 here causes problems when incorporating this into Binary Ninja because all ints are represented as a u64. It means additional error prone casting is required to get the correct behavior (eg. cast i16 to u16 and then u16 to u64) to avoid turning negative numbers into to the wrong number when up cast. This likely won't have a significant impact within this library itself but the Display logic may need to be slightly tweaked.

This is likely only going to be relevant for actions dependencies because currently there are no rust dependencies. It might be worth turning on cargo anyway in case some are ever added.

Currently there are not tests to verify that the emulation behavior is correct but based on some manual review they do appear to be so. It would be good to add some to ensure that there are no missing edge cases and we're not underfit or overfit.

It would be good to have an example that can take a binary of machine code and print the disassembly. it doesn't need to do anything fancy like attempting to understand basic blocks, function boundaries, etc. Simply printing the disassembly with it's offset and maybe allowing for rebasing the file?

Currently all implementations of the Emulate trait for TwoOperand instructions choose to consume self rather than call it on a reference to self. The idea here was that the instruction would consume, moving the TwoOperand instruction allowing the emulated instruction to take ownership, rather than simply storing a reference. This ended up not actually being ideal because the emulate method will return None if the instruction isn't emulated (which means the original TwoOperand instruction is still used) and we're not actually moving ownership anyway. Currently this is probably pretty efficient because all of the types are Copy but there is probably a more elegant solution here, which may just end up moving back to using references.

Based on the current architecture adding assembling capabilities to the library should be pretty straight forward assuming a list of Instruction objects. It simply requires implementing a method for each of the types of instructions to handle encoding. This however would not provide an assembler frontend to be able to take text and assemble it.

It's probably worth implementing this first and then look into how difficult it would be to add a real frontend to translate the text to instructions. This is something that will likely be needed to integrate into disassemblers, such as Binary Ninja, to support patching. It's unclear if the frontend will be needed as well or how complex of a frontend would be needed.

Have dependabot manage cargo and github action versions