reko icon indicating copy to clipboard operation
reko copied to clipboard

Strange memory access

Open rfalke opened this issue 5 years ago • 1 comments

Subject: https://github.com/rfalke/decompiler-subjects/tree/master/from_holdec/dmi/value_prop/ia32_elf

Output:

Eq_369 advanced_2_mem_values_can_be_propagated_for_non_write_calls(char * dwArg04)
{
	g_t804A02C = 0x01;
	return strlen(dwArg04) + Mem16[0x0804A02C<p32>:word32];
}

Expected:

Eq_369 advanced_2_mem_values_can_be_propagated_for_non_write_calls(char * dwArg04)
{
	g_t804A02C = 0x01;
	return strlen(dwArg04) + g_t804A02C;
}

I'm also not sure what Mem16 should be. The read access is 32bit.

rfalke avatar Jun 30 '20 09:06 rfalke

What you are seeing is a crash in the type inference part of Reko. Trying to recover, it emits in desperation the low-level RTL representation of a memory access. Memory accesses in Reko are expressed as a tuple (MemorySpace, effective address) -- ignoring the x86-specific SegmentedMemoryAccesses). Memory spaces are SSA numbered, just like identifiers are. A future version will be able to take advantage of SSA-numbered memory spaces to make decisions about memory accesses aliasing each other.

The crash should ofc never happen. I'm assigning this to myself for investigation.

uxmal avatar Jun 30 '20 09:06 uxmal

Output of version 0.11.4.0-931ca7d:

Eq_360 advanced_2_mem_values_can_be_propagated_for_non_write_calls(char * dwArg04)
{
	global_var = 0x01;
	return (word32) strlen(dwArg04) + global_var;
}

Fixed -> close issue.

rfalke avatar Aug 26 '23 21:08 rfalke