I'd say valgrind is a good idea, but it's probably something that's
not initialized rather than a memory leak. You could look at what
instruction is writing the register that's different and see what it's
operands are and which version is correct. That looks like a stack
address, so there may be some memory fault related to the stack that's
not being handled correctly.
Gabe
Quoting Korey Sewell <ksew...@umich.edu>:
Valgrind could be your best friend here. I'd say run your program for a
non-trivial amount of ticks (~1 billion?) in valgrind with the
"tool=memcheck" and "leak-check=yes" on and usually that reveals some memory
leak somewhere. If that leak is in your edited part of the code, then you
probably have found the issue of instability.
@note: Are you allocating or deleting things on your own?
On Fri, May 27, 2011 at 3:25 PM, Andrea Pellegrini <
andrea.pellegr...@gmail.com> wrote:
Hi all,
I heavily modified the O3 cpu to implement my own architecture and I am
still debugging it for some corner cases.
However, I am experiencing a really weird behavior in m5. When I debug m5
in gdb (either with eclipse or kdbg) I see the outputs deviate from the
expected behavior.
The runs are consistent within running m5 in console and running it in gdb,
differing always in the same way. The two runs have *exactly* the same
arguments.
This is the command line I use (I added my own trace flags and some extra
parameters):
m5/build/X86_SE/m5.debug
--trace-flags=O3CPU,TLB,Fetch,Decode,Rename,IEW,IQ,Commit,ROB,Writeback,IntRegs,ROB,LSQUnit,TSU,TGCluster,TGFetch,TGDecode,TGRename,TGIEW,TGCommit,TGDATAFlow,TGCrossbar
/m5/configs/example/se_andrea.py -d --caches -n 1 -c
m5/tests/test-progs/hello/bin/x86/linux/hello --num_faults=0
========================================================================================================
This is what I get when I diff the log files:
10c10
< M5 started May 26 2011 23:26:49
---
> M5 started May 26 2011 22:55:04
12c12
---
< 15479500: global: RegFile: Setting int register 249 to 0x7fffffffef4c
---
> 15479500: global: RegFile: Setting int register 249 to 0x7fffffffef4e
2164282,2164283c2164282,2164283
...
other differences from here
========================================================================================================
I have no idea why running in gdb should modify the behavior of the
simulation. I tried to valgrind m5 to check if I was using some initialized
variable or pointer, but everything seems fine.
I currently working on understanding what is wrong with it, and I was
wondering if somebody else already experienced this odd behavior.
Thanks!
-Andrea
_______________________________________________
gem5-users mailing list
gem5-users@m5sim.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
--
- Korey
_______________________________________________
gem5-users mailing list
gem5-users@m5sim.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
