Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unexpected argument order when decompiling program #1338

Open
uxmal opened this issue Apr 17, 2024 · 0 comments
Open

Unexpected argument order when decompiling program #1338

uxmal opened this issue Apr 17, 2024 · 0 comments
Assignees
Labels
bug This issue describes a defect in Reko

Comments

@uxmal
Copy link
Owner

uxmal commented Apr 17, 2024

(See #1337 opened by @yangzao for the binary in question, program1)

Original code:

set_var(i_l, s_l, l_l);
str = str_l;
printf("%s", str);

Decompiled code:

set_var(qwLoc18_141, wLoc0E_140, dwLoc0C_144);
str = qwLoc20_142;
printf("%s", str);

The argument order of set_var() is recovered incorrectly.
The order of qwLoc18_141 (corresponds to l_l) and dwLoc0C_144 (corresponds to i_l) gets reversed.

@uxmal uxmal self-assigned this Apr 17, 2024
@uxmal uxmal added the bug This issue describes a defect in Reko label Apr 17, 2024
uxmal added a commit that referenced this issue Apr 19, 2024
Start of implementation of parameter ordering respecting the ABI
of the Platform.

Create AbstractCallingConvention implementation base class.
uxmal added a commit that referenced this issue Apr 30, 2024
Completed core implementation of parameter ordering respecting the ABI
of the Platform. Individual ABIs need to be adjusted individually.

Created AbstractCallingConvention implementation base class.

Added CallingConventionMatcher class, which tries to find a calling convention that matches the parameters by a Procedure.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This issue describes a defect in Reko
Projects
None yet
Development

No branches or pull requests

1 participant