It should always fault in the same place; the simulator is deterministic. Faulting in advancePC() indicates that it's an instruction fetch that's faulting, which is particularly unusual.
You should look at an execution trace to see why execution is heading off into the weeds, if that's what's happening. You can use --debug-start to turn on the trace just a little bit before the fault, so you don't have to waste time tracing from the beginning. Steve On Fri, Oct 31, 2014 at 12:38 PM, Ahmad Hassan <ahmad.has...@gmail.com> wrote: > More interestingly, it always page faults in advancePC method: > > #0 0x00007ffff6416425 in __GI_raise (sig=<optimised out>) at > ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > #1 0x00007ffff6419b8b in __GI_abort () at abort.c:91 > #2 0x0000000000a37bde in __exit_epilogue(int, char const*, char const*, > int, char const*) () > #3 0x00000000008c09a6 in X86ISA::PageFault::invoke(ThreadContext*, > RefCountingPtr<StaticInst> const&) () > #4 0x000000000097c8b8 in > BaseSimpleCPU::advancePC(RefCountingPtr<FaultBase> const&) () > #5 0x0000000000974ed7 in AtomicSimpleCPU::tick() () > #6 0x0000000000903c91 in EventQueue::serviceOne() () > #7 0x00000000009211ca in doSimLoop(EventQueue*) () > #8 0x0000000000921775 in simulate(unsigned long) () > > Regards, > > > On 31 October 2014 17:17, Ahmad Hassan <ahmad.has...@gmail.com> wrote: > >> Hi Steve, >> >> If I just do allocateMem and don't do 'writeBlob', then simulation runs >> fine without errors but I get '0' values in the result. This is >> understandable. But If I do writeBlob then I always get page fault >> exception exactly at the same clock tick (just before the benchmark >> finishing the execution) >> >> Regards, >> >> >> On 31 October 2014 17:11, Steve Reinhardt <ste...@gmail.com> wrote: >> >>> I don't know... that's basically a page fault. Do you know the address >>> range that your file is mapped to? It may or may not be directly related >>> to mmap. >>> >>> Steve >>> >>> On Fri, Oct 31, 2014 at 6:33 AM, Ahmad Hassan <ahmad.has...@gmail.com> >>> wrote: >>> >>>> Hi Steve, >>>> >>>> I am running x96 SE mode. The writeBlob() works fine for very small >>>> test application. For real benchmark with 1GB working set, the simulation >>>> ends with exception: >>>> >>>> panic: Tried to read unmapped address >>>> 0x2800000002d773b0. >>>> 0x2aaaaaaab000ULL >>>> @ tick 771687885000 >>>> [invoke:build/X86/arch/x86/faults.cc, line 160] >>>> Memory Usage: 11788528 KBytes >>>> Program aborted at tick 771687885000 >>>> >>>> Any ideas why 0x2800 range is getting problems by writeBlob? >>>> >>>> Thanks. >>>> >>>> >>>> >>>> On 7 October 2014 15:20, Steve Reinhardt <ste...@gmail.com> wrote: >>>> >>>>> We have a patch internally that implements more of mmap(), but >>>>> unfortunately it's not quite ready to post. >>>>> >>>>> If you just want to do a read mapping (you don't care if writes to the >>>>> mmap'd region get written back to disk), and you don't mind just reading >>>>> the whole mmap region in up front (which you need to do, since SE mode >>>>> doesn't support page faulting), it's not too hard; just call >>>>> p->allocateMem() to allocate the memory in the simulated process, and then >>>>> read the data out of the file and use writeBlob() to copy it into the >>>>> memory you just allocated. >>>>> >>>>> Steve >>>>> >>>>> On Tue, Oct 7, 2014 at 6:14 AM, Ahmad Hassan via gem5-users < >>>>> gem5-users@gem5.org> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> The existing implementation in GEM5 SE mode only supports MMAP to >>>>>> /dev/zero. Has anyone implemented MMAP in gem5 that can map a file from >>>>>> the >>>>>> disk? If not, how can I extend this? >>>>>> >>>>>> Regards, >>>>>> >>>>>> _______________________________________________ >>>>>> 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
