You should now be able to easily recreate what I believe is (and hope isn't) a gcc bug that causes a segfault when X86_FS is run in timing mode. I checked that the code still segfaults, although I didn't double check it was the same bug. You should be able to see it with any run of X86_FS that uses -t.
Gabe Gabe Black wrote: > changeset e649cb8af113 in /z/repo/m5 > details: http://repo.m5sim.org/m5?cmd=changeset;node=e649cb8af113 > description: > X86: Record the memory mode when building an X86 system. > > diffstat: > > 1 file changed, 2 insertions(+) > configs/common/FSConfig.py | 2 ++ > > diffs (12 lines): > > diff -r 353726c415f4 -r e649cb8af113 configs/common/FSConfig.py > --- a/configs/common/FSConfig.py Sat Dec 19 01:48:31 2009 -0800 > +++ b/configs/common/FSConfig.py Sat Dec 19 01:49:34 2009 -0800 > @@ -216,6 +216,8 @@ > mdesc.diskname = 'x86root.img' > self.readfile = mdesc.script() > > + self.mem_mode = mem_mode > + > # Physical memory > self.membus = MemBus(bus_id=1) > self.physmem = PhysicalMemory(range = AddrRange(mdesc.mem())) > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
