If you have any more difficulty figuring out how to do it with arguments, try arm-linux-objdumping or compiling only to assembly a C program that calls the function in question and see how it's setting things up.
On Nov 24, 2:09 pm, Experand <[email protected]> wrote: > Thanks for the quick replies. That was helpful. > > I didn't know that calling C function from assembly is not that > difficult. I tried calling a function which has no arguments from > inside dalvik/vm/mterp/armv5te/OP_RETURN.S, and it worked, although it > generated tons of output. > > I had another question, but I would redirect it to another forum as > pointed by Mark. > > Amruta > > On Nov 23, 3:21 pm, Chris Stratton <[email protected]> wrote: > > > 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.
