Version and Platform (required):
- Binary Ninja Version: 5.4.10147-dev
- Edition: Ultimate
- OS: macOS
- OS Version: 26.5
- CPU Architecture: arm64
Bug Description:
When analyzing a fastcall function that takes many arguments, the PDB parser incorrectly handles certain register-based parameters and produces an incorrect type signature.
Steps To Reproduce:
Please provide all steps required to reproduce the behavior:
- Extract callconv.zip
- Open callconv.dll and make sure callconv.pdb is loaded
- Navigate to 0x10001030
- Observe function signature looks broken
Expected Behavior:
I expected the parameters to the function to all be in their default locations and not have any cruft in the decompilation about register entry values.
Screenshots/Video Recording:

Additional Information:
Loading the binary without the pdb produces the expected HLIL:

Investigating the PDB further reveals that the PDB stores the locations of those parameters as their stack slots assigned in the function prologue, versus at call-time which is what binja expects.
Function : static, [00001030][0001:00000030], len = 00000024, @Fastcall@24
Function attribute:
Function info: asyncheh
FuncDebugStart : static, [0000103C][0001:0000003C]
FuncDebugEnd : static, [0000104E][0001:0000004E]
Data : VFrame Relative, [FFFFFFFC], Param, Type: int, arg1
Data : VFrame Relative, [FFFFFFF8], Param, Type: int, arg2
Data : VFrame Relative, [00000008], Param, Type: int, arg3
Data : VFrame Relative, [0000000C], Param, Type: int, arg4
Data : VFrame Relative, [00000010], Param, Type: int, arg5
Data : VFrame Relative, [00000014], Param, Type: int, arg6
Note FuncDebugStart being 0xC bytes into the function right after where arg1/arg2 are saved to stack slots
Version and Platform (required):
Bug Description:
When analyzing a fastcall function that takes many arguments, the PDB parser incorrectly handles certain register-based parameters and produces an incorrect type signature.
Steps To Reproduce:
Please provide all steps required to reproduce the behavior:
Expected Behavior:
I expected the parameters to the function to all be in their default locations and not have any cruft in the decompilation about register entry values.
Screenshots/Video Recording:

Additional Information:

Loading the binary without the pdb produces the expected HLIL:
Investigating the PDB further reveals that the PDB stores the locations of those parameters as their stack slots assigned in the function prologue, versus at call-time which is what binja expects.
Note FuncDebugStart being 0xC bytes into the function right after where arg1/arg2 are saved to stack slots