| Author |
Message |
m++
Guest
|
 Posted:
Wed Dec 15, 2004 7:07 pm Post subject:
Memory trace tool |
|
|
Hi,
Does anyone know a tool to generate a memory trace for a given
program(my c++ benchmarks) ? I need the memory reference traces as an
input to a trace driven cache simulator ( something like "dinero") .
Any suggestions , would be greatly appreciated. |
|
| Back to top |
|
 |
Paul Pluzhnikov
Guest
|
| Posted:
Wed Dec 15, 2004 9:05 pm Post subject:
Re: Memory trace tool |
|
|
"m++" <modarressi@ce.sharif.edu> writes:
| Quote: | I need the memory reference traces as an
input to a trace driven cache simulator ( something like "dinero") .
|
You didn't specify platform. On Linux/x86, 'valgrind --tool=cachegrind'
might give you what you need.
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email. |
|
| Back to top |
|
|
Jesus Hernandez Tapia
Guest
|
| Posted:
Wed Dec 15, 2004 9:33 pm Post subject:
Re: Memory trace tool |
|
|
m++ wrote:
| Quote: | Hi,
Does anyone know a tool to generate a memory trace for a given
program(my c++ benchmarks) ? I need the memory reference traces as an
input to a trace driven cache simulator ( something like "dinero") .
Any suggestions , would be greatly appreciated.
|
Hi,
These tools may be useful for you:
Pin - A Binary Instrumentation Tool
http://rogue.colorado.edu/Pin/
Simics - A full system simulator
http://www.virtutech.com/products/simics.html
Regards,
Jesus |
|
| Back to top |
|
|
m++
Guest
|
| Posted:
Thu Dec 16, 2004 1:20 pm Post subject:
Re: Memory trace tool |
|
|
Hi,
Thanx 4 ur answers!
I'm sorry,I forgot to mention that the platform is linux,BSD or win
/x86.
Regards,
--modaressi |
|
| Back to top |
|
|
Phil Armstrong
Guest
|
| Posted:
Thu Dec 16, 2004 6:33 pm Post subject:
Re: Memory trace tool |
|
|
m++ <modarressi@ce.sharif.edu> wrote:
| Quote: | Thanx 4 ur answers!
I'm sorry,I forgot to mention that the platform is linux,BSD or win
/x86.
|
Under Linux on x86, valgrind is the tool you want.
I've been told of companies porting their software to linux
specifically in order to use valgrind.
Phil
--
http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt |
|
| Back to top |
|
|
Paul Pluzhnikov
Guest
|
| Posted:
Thu Dec 16, 2004 8:40 pm Post subject:
[OT] Re: Memory trace tool |
|
|
Phil Armstrong <phil-news@kantaka.co.uk> writes:
| Quote: | I've been told of companies porting their software to linux
specifically in order to use valgrind.
|
Interesting. Most other popular UNIXes have commercial tools to do
what VG does (Purify, Insure++, ZeroFault).
Yet companies are willing to spend untold thousands of $$$ to port,
just so they could use VG "for free"?
OTOH, if the company already wanted to do the Linux port anyway,
then VG comes as a nice bonus.
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email. |
|
| Back to top |
|
|
David Edwards
Guest
|
| Posted:
Thu Dec 16, 2004 11:22 pm Post subject:
Re: [OT] Re: Memory trace tool |
|
|
Paul Pluzhnikov <ppluzhnikov-nsp@charter.net> wrote:
| Quote: | Phil Armstrong <phil-news@kantaka.co.uk> writes:
I've been told of companies porting their software to linux
specifically in order to use valgrind.
Interesting. Most other popular UNIXes have commercial tools to do
what VG does (Purify, Insure++, ZeroFault).
Yet companies are willing to spend untold thousands of $$$ to port,
just so they could use VG "for free"?
|
VG has a big advantage over Purify (which my group also uses) in that
Purify requires an instrumented build... which means that the build
we're testing is not quite the same as the build we provide to a
customer. We didn't port just to use VG for free (for starters, we
supported Linux since the 1.x days, which predates VG by rather a lot),
but we use it a lot more than we do Purify, because we find it a lot
more useful. |
|
| Back to top |
|
|
Paul Pluzhnikov
Guest
|
| Posted:
Fri Dec 17, 2004 12:15 am Post subject:
Re: [OT] Re: Memory trace tool |
|
|
David Edwards <dpe@invalid.domain.com> writes:
| Quote: | VG has a big advantage over Purify (which my group also uses) in that
Purify requires an instrumented build... which means that the build
we're testing is not quite the same as the build we provide to a
customer.
|
Unless you ship debug builds to the customer, the build you test
with VG is also likely not the build you ship.
Further, under VG you test non-NPTL threads (assuming any of your
executables are threaded), which is "not all" what the customer
will likely be using.
| Quote: | We didn't port just to use VG for free
|
I think that statement agrees with my argument, not contradicts it.
| Quote: | but we use it a lot more than we do Purify, because we find it a lot
more useful.
|
Faster, more convenient maybe? But more useful?
The set of bugs the 2 tools find is exactly the same (actually Purify
now finds quite a bit more then VG -- they implemented guard zones
around global variables, which VG can do nothing about).
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email. |
|
| Back to top |
|
|
Phil Armstrong
Guest
|
| Posted:
Fri Dec 17, 2004 4:34 pm Post subject:
Re: [OT] Re: Memory trace tool |
|
|
Paul Pluzhnikov <ppluzhnikov-nsp@charter.net> wrote:
| Quote: | Phil Armstrong <phil-news@kantaka.co.uk> writes:
I've been told of companies porting their software to linux
specifically in order to use valgrind.
Interesting. Most other popular UNIXes have commercial tools to do
what VG does (Purify, Insure++, ZeroFault).
Yet companies are willing to spend untold thousands of $$$ to port,
just so they could use VG "for free"?
|
No. Don't be silly -- they ported to linux because valgrind can do
things that purify can't.
Most importantly, you can get useful information from running valgrind
on an ordinary compiled binary, whereas purify requires an
instrumented build. If you've got a serious bug that goes away when
you look at an instrumented build then valgrind is manna from heaven.
Phil
--
http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt |
|
| Back to top |
|
|
Andi Kleen
Guest
|
| Posted:
Fri Dec 17, 2004 5:18 pm Post subject:
Re: [OT] Re: Memory trace tool |
|
|
Phil Armstrong <phil-news@kantaka.co.uk> writes:
| Quote: | Most importantly, you can get useful information from running valgrind
on an ordinary compiled binary, whereas purify requires an
instrumented build. If you've got a serious bug that goes away when
you look at an instrumented build then valgrind is manna from heaven.
|
To be fair valgrind runs often behave significantly differently
from normal runs, especially when the debuggee is multithreaded
(valgrind doesn't do real multi processor threading, but time shares
multiple threads on a single CPU)
But valgrind is in some ways more powerful than Purify. AFAIK P.
cannot do the bit level undefinedness tracking that valgrind does.
On the other hand Purify can do some things valgrind can't
(like array overflow checking based on objects when there is no
gap between objects)
-Andi |
|
| Back to top |
|
|
Phil Armstrong
Guest
|
| Posted:
Fri Dec 17, 2004 5:57 pm Post subject:
Re: [OT] Re: Memory trace tool |
|
|
Andi Kleen <freitag@alancoxonachip.com> wrote:
| Quote: | But valgrind is in some ways more powerful than Purify. AFAIK P.
cannot do the bit level undefinedness tracking that valgrind does.
On the other hand Purify can do some things valgrind can't
(like array overflow checking based on objects when there is no
gap between objects)
|
Absolutely. It's not that valgrind is 'better' than purify, but that
the different implementation approaches have different strengths and
weaknesses. For a specific problem in question one may certainly be
better than the other, but neither have universal applicability.
Phil
--
http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in