Ali,

Thank you for responding.
Basically what I have set up now is a separate branch monitor program running on a second core; I want to compare this against instrumentation on one core. My thread context idea was to have the monitor running in a separate thread context. Then it would be similar to how my two-core version works where some branch information is stored within the simulator, thread context is switched to the monitor to handle it, then switched back to the original application.

The applications I'm using are fairly large (one has more than 2000 lines) so I wanted to avoid manual instrumentation. Compiler modification might be ideal, but I have no experience or time to attempt modifying LLVM at this time.

I'll look into modifying the branch instructions.

Thanks,
David G.

On 03/25/2013 07:28 AM, gem5-users-requ...@gem5.org wrote:
Hi David,

It's certainly possible, but it's going to take some work. My random idea would 
be to change how all the branch instructions are defined, so the stash their 
real target address somewhere and jump to your handler. Other than that 
manually instrumenting the program (or doing it with some compiler 
modifications) would probably be your best bet. While it doesn't take any time 
to switch thread contexts, by definition the context has all the state from the 
thread in it, so I'm not sure how switching would solve your problem.


Ali

On Mar 24, 2013, at 11:18 PM, David Gloe<gloex...@umn.edu>  wrote:

>Hello,
>
>I am attempting to instrument branch instructions in a program in gem5. So 
far, I have code in AtomicSimpleCPU which determines when branch instructions are 
executed. For every branch, I would like to call an instrumentation function and 
then return to execution of the simulated program. This would be fairly simple, 
but I would like to execute the instrumentation function within the simulator, so 
the instrumentation time is taken into account on the simulator statistics.
>
>Is it possible to do something like this? Any ideas on how to do this? The 
function could be compiled in with the program, so we might be able to instrument 
by manually setting up arguments and changing the PC to the instrumentation 
function. Another idea I had would be to have two thread contexts for one CPU with 
one running the application and one doing instrumentation, and switching between 
them as needed. Is this sort of thing possible; is there any simulation time used 
by thread context switches?
>
>Thanks,
>David G.
>
>-- >David Gloe
>gloex...@umn.edu  da...@cs.umn.edu  dcg...@gmail.com
>Masters Student, Computer Science
>University of Minnesota
>
>_______________________________________________
>gem5-users mailing list
>gem5-users@gem5.org
>http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>


--
David Gloe
gloex...@umn.edu da...@cs.umn.edu dcg...@gmail.com
Masters Student, Computer Science
University of Minnesota

_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Reply via email to