great thanks for your quick reply. it is now fine // Naderan *Mahmood;
On Sun, Apr 29, 2012 at 2:36 PM, Gabe Black <gbl...@eecs.umich.edu> 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 <gbl...@eecs.umich.edu> 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 <ste...@gmail.com> wrote: >> >> On Sat, Apr 28, 2012 at 9:43 AM, Mahmood Naderan >> >> <mahmood...@gmail.com>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 >> gem5-users@gem5.org >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > > > > _______________________________________________ > gem5-users mailing > listgem5-users@gem5.orghttp://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
