Vector35
RISCV plugins throws mapping errors on fresh install
Version and Platform (required):
- Binary Ninja Version: 4.0.4911-dev Personal ( 15e9149)
- OS: MacOS
- OS Version: 14.3.1 (23D60)
- CPU Architecture: M1
Bug Description: When loading a RISCV binary the following error is printed on the console:
[Default] Unable to restore arch id mappings for 'rv32gc'
[Default] Unable to restore arch id mappings for 'rv32gc'
Steps To Reproduce: Please provide all steps required to reproduce the behavior:
- Open a raw riscv binary, not a elf just a memory dump
- Select rv32gc
- Load the binary
- Look at console
The nanoMIPS plugin also sees this. It seems we are missing something in common
I am not sure about what's happening in the original report, but I do think I understand what is happening in the case I am currently running into on RISC-V.
If you have a function that uses non-standard parameters (e.g. sub_57af2(struct _Unwind_Exception* arg1, int32_t* arg2 @ s0)) and those get saved as part of, for example, a type in a type library...we will try to look those up when you open the database back up. In days long past, these mappings were stored in the code that did serialization/deserialization. But, we now store these mappings within the database itself, which allows us to support these mappings for custom architectures.
Unfortunately, at least in the type library example, it appears when we go looking for the mappings, we wind up with a key-value store that is NULL, which causes it to go down the codepath we left in for backward-compatibility with old databases. This codepath is supposed to wind up printing an info message that says Detected an old database or there is a programming error! Attempting to restore from fallback architecture translation map., but this is only printed in the case where the key-value store is not NULL. So, we hit the fallback architecture translation map, which prints the Unable to restore arch id mappings, which doesn't have an entry for things like rv32gc because this code pre-dates these architectures.
I don't really know this code well at all, but I believe the fix here is to find places where we go down this codepath outside the context of a database and force them to have the database available. This, I believe, would cause us to go down the correct code path (which tries to resolve things using the ArchitectureEnumTranslation) and avoid all of these error messages.
