You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now the handling of calling conventions for PE files is wrong for most analyses:
The PointerInference (and most other analyses) assume that internal function calls adhere to a standard calling convention, which is either named __stdcall or __cdecl (this happens in the Project::get_standard_calling_convention method). But for example in the x64-PE acceptance test binaries the only known calling conventions are __fastcall and __thiscall. So we either have to choose the right one as a standard calling convention for PE binaries or we have guess the correct one (or let Ghidra guess for us, if Ghidra provides this information).
Note: There are probably some more bugs with respect to the handling of PE calling conventions.
The text was updated successfully, but these errors were encountered:
A short update on this: Thanks to PR #269 we now have a fix for this for x86_64-PE files. The fix is not yet integrated into all analyses, I will update the issue when it is (I should have time for doing this myself soon).
For x86_32-PE files we should still have problems with calling conventions where the callee is responsible for removing parameters from the stack. I expect the stack offset computations to be wrong in most cases for functions using these calling conventions. We probably also do not have enough acceptance test cases to cover all the possible cases for 32-bit x86 PE-files.
Right now the handling of calling conventions for PE files is wrong for most analyses:
The PointerInference (and most other analyses) assume that internal function calls adhere to a standard calling convention, which is either named
__stdcall
or__cdecl
(this happens in theProject::get_standard_calling_convention
method). But for example in the x64-PE acceptance test binaries the only known calling conventions are__fastcall
and__thiscall
. So we either have to choose the right one as a standard calling convention for PE binaries or we have guess the correct one (or let Ghidra guess for us, if Ghidra provides this information).Note: There are probably some more bugs with respect to the handling of PE calling conventions.
The text was updated successfully, but these errors were encountered: