-
Notifications
You must be signed in to change notification settings - Fork 252
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
8051 bank switch / jump table #826
Comments
It seems some of sort of support for overlays would be needed to support this. Alternatively, you would decompile the individual banks separately, providing support for missing code by specifying (function-address, function-siguature) place holders. Regarding switch statements: I'm relatively new to the 8051 processor so I need to spend some time looking at that sample you provided. Watch this space for updates. |
Thank you for rocket fast response. |
I've looked at the binary further. The bank-switching is accomplished by writing values to a model-specific register, then transferring control by pushing values on the stack and abusing the Reko in its current state is a little naive and assumes that no shenanigans are being done with return addresses. It's becoming clear that even in non-malware/obfuscated software, the trick of pushing the a transfer address on the stack and jumping to it via The new notion is that, just like the logical frame pointer is made explicit in the Reko IR, we must also reify the
and the
The analysis phase will hopefully propagate registers and discover that the last statements become
and that Another way of stating this is to make Reko generate code in continuation passing style (CPS) and in later stages clean up the CPS. As for switch statements, the one in the 8051 code is following a pattern Reko is failing to detect. I will be working on improving the switch detector during the week. |
Here is the relevant switch code:
Reko is failing because of the "clever" hack used to perform bounds checking on the switch. The |
Reko can now handle the code above. You mentioned earlier you were considering preparing a few more samples of switch statements. Those would be greatly appreciated -- I don't have the toolset to make them myself. If you do make such samples, consider separating code banking from switch statements at first, to simplify the work. |
Keil have few paradigms explained here
|
Nice IDA "Switch Idiom" screenshots here: https://reverseengineering.stackexchange.com/questions/20112/how-can-i-make-ida-understand-this-switch-statement-with-a-signed-jump-table?rq=1 |
Reko has a similar dialog already. It should appear when clicking on a warning that an indirect jump cannot be resolved. I will look at this in a few hrs |
@kimstik: Reko's i8051 implementation now understands Keil's "sparse" switch statements. I will close this issue now, as the immediate concern has been addressed. Let me know if you discover further issues. |
May we keep it open for bank switch? |
Sure. I'll look at bank switching next. |
I reduced SDCC switch testcase by removing banking.
|
Please find Keil ICASE & LCASE tests attached |
Update: I'm working on getting these three cases to pass. Thanks for providing the samples BTW. |
Few public 8051 binaries with bank switching (TI CC2451): https://github.com/RedBearLab/CCLoader/tree/master/Bin |
Code banking: Many modern 8051 chips (cc2530/C8051F120/..) have code memory address extension by banking. Ref1, Ref2
How can I deal with it?
Switch jump table: Compilers usually emit jump table for switch statement.
How can i specify switch paradigm for 8051?
simple test code attached
The text was updated successfully, but these errors were encountered: