Re: [gem5-users] M5 changes behavior when running in GDB
Andrea, track-origins=yes is the flag. On Fri, May 27, 2011 at 6:05 PM, Korey Sewell ksew...@umich.edu 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 gbl...@eecs.umich.edu 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 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 0x7fffef4c --- 15479500: global: RegFile: Setting int register 249 to 0x7fffef4e 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 -- - Korey -- - Korey ___ gem5-users mailing list gem5-users@m5sim.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] M5 changes behavior when running in GDB
On Fri, 27 May 2011, Andrea Pellegrini 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 0x7fffef4c --- 15479500: global: RegFile: Setting int register 249 to 0x7fffef4e 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 Andrea, from my personal experience, I would say that gdb does not modify the visible behavior unless there is some bug in the program. I would expect that some memory access is going on wrongly some where. Try to traceback from the point where you first spot the two executions diverging. -- Nilay ___ gem5-users mailing list gem5-users@m5sim.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] M5 changes behavior when running in GDB
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 0x7fffef4c --- 15479500: global: RegFile: Setting int register 249 to 0x7fffef4e 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
Re: [gem5-users] M5 changes behavior when running in GDB
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 0x7fffef4c --- 15479500: global: RegFile: Setting int register 249 to 0x7fffef4e 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
Re: [gem5-users] M5 changes behavior when running in GDB
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 gbl...@eecs.umich.edu 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 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 0x7fffef4c --- 15479500: global: RegFile: Setting int register 249 to 0x7fffef4e 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 -- - Korey ___ gem5-users mailing list gem5-users@m5sim.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
