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] > <mailto:[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] > <mailto:[email protected]>> wrote: > >> On Sat, Apr 28, 2012 at 9:43 AM, Mahmood Naderan > >> <[email protected] <mailto:[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] <mailto:[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
