Version and Platform (required):
- Binary Ninja Version: 4.2.6187-dev
- OS: Ubuntu
- OS Version: 24.04.1
- CPU Architecture: x64
Bug Description:
While working on a custom architecture, I was having issues with 64-bit returns from functions only showing the 32-bit primary return register value in MLIL and HLIL. After some investigation, it seems this also applies to other architectures like ARMv7 - even after setting the return type for a trivial function to uint64_t, Binary Ninja only presents the value in r0 as the value returned from the function.
Steps To Reproduce:
- Save the hex
01 00 a0 e3 02 10 a0 e3 1e ff 2f e1 into a new .bin file (also provided in the .zip attached to the issue)
- Load the .bin file in Binary Ninja with the architecture set to armv7
- Switch to mapped view
- Create a function at the start of the file
- Change the return type of the function to
uint64_t
- Switch to MLIL or HLIL views
- Observe that the return value is shown as
1 rather than 0x200000001
Even if the function properties are edited to include r1 in the return registers, the HLIL still does not return 0x200000001 as expected, showing return 1, 2 instead.
Expected Behavior:
HLIL should show a return value of 0x200000001 since the calling convention has high_int_return_reg = 'r1' and the return type is wider than the normal return value register.
Screenshots/Video Recording:
Binary:
test.zip
Version and Platform (required):
Bug Description:
While working on a custom architecture, I was having issues with 64-bit returns from functions only showing the 32-bit primary return register value in MLIL and HLIL. After some investigation, it seems this also applies to other architectures like ARMv7 - even after setting the return type for a trivial function to
uint64_t, Binary Ninja only presents the value inr0as the value returned from the function.Steps To Reproduce:
01 00 a0 e3 02 10 a0 e3 1e ff 2f e1into a new .bin file (also provided in the .zip attached to the issue)uint64_t1rather than0x200000001Even if the function properties are edited to include
r1in the return registers, the HLIL still does not return0x200000001as expected, showingreturn 1, 2instead.Expected Behavior:
HLIL should show a return value of
0x200000001since the calling convention hashigh_int_return_reg = 'r1'and the return type is wider than the normal return value register.Screenshots/Video Recording:
Binary:
test.zip