note that valgrind will also tell you if use a value that is not initialized. The flag should be "show-uninitialized" or something like that.
On Fri, May 27, 2011 at 6:03 PM, Gabriel Michael Black < [email protected]> wrote: > 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 <[email protected]>: > > 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 < >> [email protected]> 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 >>> [email protected] >>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>> >>> >> >> >> -- >> - Korey >> >> > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > -- - Korey
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
