I recommended he use the debug build for looking at what was happening under gdb. It's true that the opt build is preferable if you're not expecting to use gdb.
Steve On Sun, Apr 29, 2012 at 3:06 AM, Gabe Black <[email protected]> wrote: > It was a microcode bug which is now fixed. If you sync the development > repository you'll get the fix. > > Also, to pass input to stdin from a file, you should use the -i option > with se.py (use --help to get all the options), and you probably want to > use gem5.opt, not m5.debug. > > Gabe > > > On 04/28/12 23:08, Mahmood Naderan wrote: > > I will send the binary and input to you. the benchmark is Tonto from > spec2k6 > You can use the se.py script and since it doesn't take any argument, the > command is : > > build/X86/m5.debug configs/example/se.py --caches --l2cache -c > tonto_base.amd64-m64-gcc44-nn > > // Naderan *Mahmood; > > > > On Sun, Apr 29, 2012 at 3:10 AM, Gabe Black <[email protected]> wrote: > >> What do I need to reproduce the problem? What scripts and binaries other >> than gem5 itselfdo I need (please provide them somehow), what changes >> have you made to gem5, and what command line do I use? This is starting >> to sound like an instruction/microcode/decode problem. >> >> Gabe >> >> On 04/28/12 11:26, Mahmood Naderan wrote: >> > I think it is worth to paste the messages while >> > "SyscallVerbose,IntRegs,Stack,Thread,X86,ExecAll" flags are on: >> > >> > 339054000: system.cpu + A0 T0 : 0x83d48d.4 : CALL_NEAR_I : wrip , >> > t7, t1 : IntAlu : >> > 339054500: system.cpu.[tid:0]: Setting int reg 16 (16) to 0. >> > 339054500: global: The data size is 8 >> > 339054500: system.cpu.[tid:0]: Reading int reg 10 (10) as 0xbb3ac0. >> > 339054500: system.cpu.[tid:0]: Reading int reg 1 (1) as 0x22. >> > 339054500: system.cpu.[tid:0]: Reading int reg 10 (10) as 0xbb3ac0. >> > 339054500: global: Picking with size 8 >> > 339054500: system.cpu.[tid:0]: Setting int reg 10 (10) to 0x22. >> > 339054500: system.cpu + A0 T0 : 0x852f90 : mov r10, rcx >> > 339054500: system.cpu + A0 T0 : 0x852f90.0 : MOV_R_R : mov r10, >> > r10, rcx : IntAlu : D=0x0000000000000022 >> > 339055000: system.cpu.[tid:0]: Setting int reg 16 (16) to 0. >> > 339055000: system.cpu.[tid:0]: Setting int reg 0 (0) to 0x9. >> > 339055000: system.cpu + A0 T0 : 0x852f93 : mov eax, 0x9 >> > 339055000: system.cpu + A0 T0 : 0x852f93.0 : MOV_R_I : limm eax, >> > 0x9 : IntAlu : D=0x0000000000000009 >> > 339055500: system.cpu.[tid:0]: Setting int reg 16 (16) to 0. >> > 339055500: system.cpu.[tid:0]: Reading int reg 0 (0) as 0x9. >> > 339055500: system.cpu.[tid:0]: Reading int reg 7 (7) as 0. >> > 339055500: system.cpu.[tid:0]: Reading int reg 6 (6) as >> 0x4d00001e4ce4b000. >> > 339055500: system.cpu.[tid:0]: Reading int reg 2 (2) as 0x3. >> > 339055500: system.cpu.[tid:0]: Reading int reg 10 (10) as 0x22. >> > 339055500: system.cpu: syscall mmap called w/arguments >> > 34,3,5548434871059525632,0 >> > 339055500: system.cpu.[tid:0]: Reading int reg 7 (7) as 0. >> > 339055500: system.cpu.[tid:0]: Reading int reg 6 (6) as >> 0x4d00001e4ce4b000. >> > 339055500: system.cpu.[tid:0]: Reading int reg 10 (10) as 0x22. >> > 339055500: system.cpu.[tid:0]: Reading int reg 8 (8) as 0xffffffff. >> > >> > >> > Int register 6 has odd value I think. >> > Thanks for any comment. >> > >> > >> > On 4/28/12, Steve Reinhardt <[email protected]> wrote: >> >> On Sat, Apr 28, 2012 at 9:43 AM, Mahmood Naderan >> >> <[email protected]>wrote: >> >> >> >>> why the 'length' is so much large? >> >>> >> >> That is indeed the question. >> >> >> >> My guess is that there's some bug in the way we're interpreting the >> syscall >> >> arguments being passed in from the application (via registers or on the >> >> stack). >> >> >> >> You could use strace on the application running natively to see what >> the >> >> mmap arguments should be. >> >> >> >> Then it's mostly a matter of poking around to see at what point things >> are >> >> getting confused about the value. Do the register contents look right >> on >> >> entry to the syscall? What is getSyscallArg doing, and where is it >> getting >> >> that ridiculous value from? At this point, there's probably no >> substitute >> >> for single-stepping through some of this code with gdb. >> >> >> >> I'm not familiar enoiugh with the x86 ABI to say off the top of my head >> >> where that argument is being passed. Anyone? >> >> >> >> Steve >> >> >> > >> >> _______________________________________________ >> gem5-users mailing list >> [email protected] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > > > > _______________________________________________ > gem5-users mailing > [email protected]http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
