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
First of all, it's incrementing the variable representing r4 before accessing it, but the instruction set manual says [r4+] means to access the address in r4 and then increment it.
Second, it appears to be ignoring the exts line entirely, instead interpreting r4 as a 16-bit address. exts s, n means that the next n instructions should use 32-bit addressing, using s as the upper word for all addresses. Instead, it's using the DPP registers, which define the 16-bit address space.
Less importantly, even if the decompilation were correct, it seems far too verbose. Code using a lot of 16-bit addressing (which is extremely common) becomes very hard to read due to all the repetitive lines of code. Wouldn't it make more sense to use near/far pointer syntax, and just treat all the DPP stuff as implied whenever a near pointer is dereferenced? Or if Ghidra doesn't support that, you could probably define pointers as 24-bit (or 32-bit if it must be a power of two) and define an intrinsic for converting 16-bit addresses, like *__dpp(address) = value;
The text was updated successfully, but these errors were encountered:
Yes, you are right, extsextp opcodes not supported now.
Also, I have no ideas, how to do it only with SLEIGH. Looks like there is need special analyzer plugin, written in java. I have no expirence with it...
define an intrinsic for converting 16-bit addresses, like *__dpp(address) = value
It is not good idea, because it breaks all cross-references, even for variables with constant addresses. I think, it should be done in that plugin too.
Right now I dont have enought time to investigate it.
I can just add some README, that describes flaws in current implementation.
About the first thing, it's possible that a later decompilation step changes the order, and it only leaves it like that because it knows the order doesn't matter in this case. Like how an optimizing compiler may write instructions in a different order than a literal start-to-finish reading of the source code would indicate, if it knows it won't make a difference. I haven't tested, but maybe it was an instruction where the order mattered (e.g. mov r4, [r4+]) it would generate the correct code.
Here's an example:
The lines
should decompile to something like:
Instead, they decompile to:
First of all, it's incrementing the variable representing
r4
before accessing it, but the instruction set manual says[r4+]
means to access the address inr4
and then increment it.Second, it appears to be ignoring the
exts
line entirely, instead interpreting r4 as a 16-bit address.exts s, n
means that the nextn
instructions should use 32-bit addressing, usings
as the upper word for all addresses. Instead, it's using the DPP registers, which define the 16-bit address space.Less importantly, even if the decompilation were correct, it seems far too verbose. Code using a lot of 16-bit addressing (which is extremely common) becomes very hard to read due to all the repetitive lines of code. Wouldn't it make more sense to use near/far pointer syntax, and just treat all the DPP stuff as implied whenever a near pointer is dereferenced? Or if Ghidra doesn't support that, you could probably define pointers as 24-bit (or 32-bit if it must be a power of two) and define an intrinsic for converting 16-bit addresses, like
*__dpp(address) = value;
The text was updated successfully, but these errors were encountered: