Re: [rvm-research] Instrumenting machine codes to find memory addresses
Michael Bond <[email protected]>
| Newsgroups | gmane.comp.java.jikes.rvm.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi Shashank, Sorry, I don't know the answers to your questions. It seems like trial and error could work for the first one. And perhaps not letting the compiler use forwardShortBranch would work for the second one? To get better feedback, it might help to describe what you're trying to do (i.e., at a high level, what's the problem you're trying to solve?). Other researchers might have suggestions for other approaches that you could use. For example, it's not clear to me (and probably others) why you can't run Jikes RVM in Valgrind or Pin and collect the same information more easily. Cheers, Mike On 05/02/2013 01:36 PM, Shashank Gupta wrote: > Hi, > > I investigated my code better, and I seem to have found the main > problems. For each instruction that uses a memory address, i also add > my code to the machine code array which pushed the value of the > address on the stack and also moved it to EAX, and called a function > inside JIKES which right now prints it on the screen. This was > creating a problem, as i was modifying the register state. To fix > this, I saved the registers EAX, ECX, and EDX on the stack and later > restore them, and this seems to have solved the problem for cases I > tried. Do i need to save other registers as well and restore them as > well, like ESI, EDI etc ? And are there any other things i need to > care about, like EFLAGS register? > > Also, I extended my trace to include the instruction trace, basically > i am trying to get all the instructions executed as well. For this I > pushed the instruction that is going to be executed on the stack and > again call a function inside JIKES with that as argument. However, > this is creating problems in the forwardShortBranch function as now > due to the extra machine codes added the offset to the label to branch > to becomes too large and can't fit into 8 bits, giving a VM assertion > fail during compile . Right now I temporarily turn off instrumentation > during the forwardShortBranch function, but is there any better way > around for this? > > Thanks > > On Wed, May 1, 2013 at 6:22 PM, Michael Bond > <[email protected] <mailto:[email protected]>> wrote: > > Hi Shashank, > > It's hard to say without seeing exactly how you instrumented > "new." It seems tricky (or at least different from instrumenting > other accesses) since the instrumentation presumably occurs after > the allocation, whereas read/write instrumentation occurs before > the access if you're following Pacer's approach. To instrument > after an allocation, it seems like you'd want the instrumentation > to push the address (which is on the stack) onto the stack *again* > so it's both the top and next element on the stack, and then call > your instrumentation method. For better feedback, please show the > code for exactly how you instrumented "new." :) > > Cheers, > Mike > > > On 04/28/2013 02:14 PM, Shashank Gupta wrote: >> Hi, >> >> We are inserting some machine codes in the machine code array of >> a sample Java program running on Jikes RVM dynamically. We want >> to find the memory addresses accessed, and hence inserted our own >> instructions to calls a function within Jikes passing address as >> an argument. We are using an approach almost similar as done in >> Pacer Patch in Jikes Archive. >> >> It was working for simple programs without constructors of a >> separate class being called. However in case of using "new" >> operator for creating instance of a class, we are either getting >> sysFail error or a Null Pointer Exception. >> >> What might be possible reasons for this? >> >> Thanks >> >> -- >> Shashank Gupta >> 4th Year, B.Tech >> Department of Computer Science and Engineering >> Indian Institute of Technology Delhi >> >> >> >> ------------------------------------------------------------------------------ >> Try New Relic Now & We'll Send You this Cool Shirt >> New Relic is the only SaaS-based application performance monitoring service >> that delivers powerful full stack analytics. Optimize and monitor your >> browser, app, & servers with just a few lines of code. Try New Relic >> and get this awesome Nerd Life shirt!http://p.sf.net/sfu/newrelic_d2d_apr >> >> >> _______________________________________________ >> Jikesrvm-researchers mailing list >> [email protected] <mailto:[email protected]> >> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > > > ------------------------------------------------------------------------------ > Introducing AppDynamics Lite, a free troubleshooting tool for > Java/.NET > Get 100% visibility into your production application - at no cost. > Code-level diagnostics for performance bottlenecks with <2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 > _______________________________________________ > Jikesrvm-researchers mailing list > [email protected] > <mailto:[email protected]> > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > > > > > -- > Shashank Gupta > 4th Year, B.Tech > Department of Computer Science and Engineering > Indian Institute of Technology Delhi > ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ Jikesrvm-researchers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers