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 list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
