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