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

Reply via email to