On Nov 23, 2:59 pm, Experand <[email protected]> wrote: > This seems to suggest that there is no way that the opcode handler > (written in assembly code) returns back to the 'C' code before > executing next instruction. This is making it harder to insert a print > statement to catch the point where the interpreter executes the > "return" opcode. I can only find one possible place : assembly code > handler for "return" opcode. But I am trying to avoid writing print > statement in assembly code. (I will have to do that, if there is no > other option.)
You don't have to implement the print functionality in assembly, you just have to call it with arguments from assembly. The arm calling conventions that apply to C code aren't too complicated, handcoding them in assembly isn't a big deal, you'll just need to shuffle some registers around and then restore when the C code returns. First look at the source of where you want to insert it and figure out if it's running in arm or thumb mode at that point, and work out your insertion to match so that you avoid having to switch modes. I'm not sure if the name of the invoked class at that point is a string, or if it becomes something numeric after the ODEX conversion? If it's not a string, it's probably better to use some kind of post- processing tool on your logs to do a lookup in data extracted from the current platform and convert it back rather than try to convert it before printing. You'll probably want to do this on a platform without JIT or with that disabled. -- You received this message because you are subscribed to the Google Groups "Android Discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/android-discuss?hl=en.
