Andrea, "track-origins=yes" is the flag. On Fri, May 27, 2011 at 6:05 PM, Korey Sewell <[email protected]> wrote:
> 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 > -- - Korey
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
