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
Describe the bug
Certain functions when decompiled will produce code that doesn't match the original behavior of the function due to a read being re-ordered to after a multi-byte write has overridden the source value. This seems to happen only when the write and read don't happen at the exact same address. For example, the compiled code
which will always return 0 due to the first line overriding the value of param_1[4].
To Reproduce
Steps to reproduce the behavior:
I've attached a source file that when compiled and decompiled shows the issue. It was tested by building with Visual Studio/MSVC, targeting Windows x64, and importing the built exe into Ghidra. Optimizations must be disabled in this example so the function doesn't get removed from the final binary. To confirm the behavior is different, the decompiled C can be copied into the original program which will cause the output to change.
Expected behavior
The decompiled source should preserve the order of reads and writes in all cases where it is significant, for example
Describe the bug
Certain functions when decompiled will produce code that doesn't match the original behavior of the function due to a read being re-ordered to after a multi-byte write has overridden the source value. This seems to happen only when the write and read don't happen at the exact same address. For example, the compiled code
will decompile to
which will always return 0 due to the first line overriding the value of param_1[4].
To Reproduce
Steps to reproduce the behavior:
I've attached a source file that when compiled and decompiled shows the issue. It was tested by building with Visual Studio/MSVC, targeting Windows x64, and importing the built exe into Ghidra. Optimizations must be disabled in this example so the function doesn't get removed from the final binary. To confirm the behavior is different, the decompiled C can be copied into the original program which will cause the output to change.
Expected behavior
The decompiled source should preserve the order of reads and writes in all cases where it is significant, for example
Screenshots
Attachments
I've attached the source code I used to test this issue.
test.c.txt
Environment (please complete the following information):
The text was updated successfully, but these errors were encountered: