It is fairly easy to get a stack trace in C... it has a well formed stack. (Never mind the fact that the ARM chip, in common with most CPU's, has instructions defined almost exclusively for calling functions & building the stack, so even if they are using lots of assembler, you'll still probably be able to do a stack trace).The main problem is that you can trace a stack when decompiling Java or Flash bytecode for instance, but it's much harder to trace a register set, because the sequence of instructions is pretty much lost. On top of that, functions are merely adresses in rom space, and are not named. Variables are also unnamed, and there's simply no way to retrieve information about structs and classes.
Emulating I/O is also quite impossible since most gaming systems use memory mapped I/O. This means you have to recompile every memory access into a function or macro that checks wether that memory access is doing I/O. And you have to do this for EVERY memory access, making memory access so incredibly slow the program crawls.
Functions are only addresses, but you really don't need to know where the functions are. If you really want to, you can probably work out how many parameters each function takes, and some other info on the parameters, as C compilers have very regular function entry routines.
But all you really need to do in the GBA case is emulate the IO (which includes GPU and stuff). While you might have to do a macro for every memory IO, there are two reasons why this probably won't be as bad as you might expect:
1) A large number of read/writes will be absolutely specified addresses, so you will know if you need to do anything emulation wise. In addition, you'll probably be able to work out where most indirect accesses go at "conversion" stage too... this is what my friend does for a PhD. It is very hard, and doing it for GBA program would be a big leap above the state of the art (they have managed to do a similar thing with small PICs, with a few k of memory). However, you don't need to do it in every case, and you can leave little macro's in where you can't do this.
2) The CPU probably isn't doing that much data I/O... Large memory writes will probably be done through DMA, and ARM chips have lots of registers so they can do almost all their "working" without accessing memory.
Gone on about this subject a bit too much... however, would like to add my lot to the possible just improbable.
Also like to correct my statement about the Halting problem making it impossible... after some consultation, not really an issue.
There are problems with self modifying code, which could be an issue if any code is decompressed etc... However this is unlikely with the GBA architecture.
Last edited by a moderator:
