Open evpobr opened 2 years ago
Should be simple enough to add another calling convention to the the SuperH4 cspec: https://github.com/NationalSecurityAgency/ghidra/blob/master/Ghidra/Processors/SuperH4/data/languages/SuperH4_le.cspec and https://github.com/NationalSecurityAgency/ghidra/blob/master/Ghidra/Processors/SuperH4/data/languages/SuperH4_be.cspec
Do you have a link to the Dreamcast cdecl calling convention?
Hi @pjsoberoi . No, I don't have a specification, but I found someone who can help:
https://www.angelcode.com/angelscript/credits.html
- Fredrik Ehnbom, a.k.a quarnster - alignment fixes, calling conventions for SH4 (Dreamcast) and ARM processors (WinCE, IPhone, Android), JIT compiler plug-in interface
@quarnster, could you help us, please?
Thanks for the link. It looks like gcc supports two calling conventions for SH4: a default calling convention and a Hitachi (-mhitachi) convention. I see information regarding how the arguments 4+ are pushed on the stack, but I'm not seeing anything regarding who cleans up the stack. stdcall the callee cleans up the stack, cdecl, the caller cleans up the stack.
Sorry I'm a bit stumped here.
But I do not know if it will be useful. I suspect that a MS compiler was used for my file:
In the IDA Pro example you have, the function is taking two args which will be passed via register. So cdecl\stdcall doesn't matter there. Do you have an example in IDA of a function taking more than 4 args? Do you have a way to compile a test binary with the Windows CE compiler?
Do you have an example in IDA of a function taking more than 4 args?
Do you have a way to compile a test binary with the Windows CE compiler?
I've never done that.
@pjsoberoi , after some researching i guess i found the answer. The problem is not missing cdecl.
MS compiler puts first 4 arguments in registers R4-R7, and puts other arguments on stack and Ghidra knows it. But Ghidra starts 5th argument with offset 0 (stack[0x0]), but MS compiler reserves extra space (sum of R4-R7 registers), so it should be 16 (stack[0x10]).
For the record, binaries compiled with Hitachi / Renesas C/C++ compiler follow the calling convention detailed in the document # R20UT0704EJ0102 ( https://www.renesas.com/us/en/document/mat/superh-cc-compiler-package-v904-users-manual?language=en&r=1054751 ) ;
Table 9.6 " General Rules on Parameter Area Allocation" , p.319
R4 to R7 char, unsigned char, bool, short, unsigned short, int, unsigned int, long, unsigned long, float (when CPU is other than SH-2E, SH2A- FPU, SH-4, or SH-4A), pointer, pointer to a data member, and reference
Parameters Allocated to a Stack (1) Parameters whose types are other than target types for register passing (2) Parameters of a function which has been declared by a prototype declaration to have variable-number parameters*3 (3) When other parameters are already allocated to R4 to R7. (4) When other parameters are already allocated to FR4 (DR4) to FR11 (DR10). (5) long long type and unsigned long long type parameters
(6) _ fixed type, long fixed type, accum type, and long _accum type parameters
In general, I now manually set the addresses of the parameters that are passed in the stack with an offset of 0x10 and this solves the problem. But I would like an official fix. I suspect this affects the analysis of the code as a whole.
Describe the bug
There is no __cdecl calling convention for Dreamcast SH4.
To Reproduce
Expected behavior
"calling convention" drop down list should contain "__cdecl".
Screenshots
Ghidra:
IDA Pro:
Attachments If applicable, please attach any files that caused problems or log files generated by the software.
Environment (please complete the following information):
Additional context Add any other context about the problem here.