Hi Mingkai, Can you run under gdb, put a breakpoint on this fatal statement (which is in Process::fixupStackFault() in sim/process.cc), print out the stack trace when you hit it, and mail that to the list?
I wonder if the new branch predictor is causing some different wrong-path execution, and that we are erroneously calling fatal() on something that looks like a stack fault but is actually a misspeculated instruction. Given that all the regressions pass, I doubt the new branch predictor is actually changing the committed execution path. That's why I think it may have something to do with a bug in how we handle misspeculation. If anyone knows the code well enough to say whether this seems likely or unlikely, that would be helpful. Steve On Wed, May 16, 2012 at 3:09 PM, Geoffrey Blake <bla...@umich.edu> wrote: > Unfortunately the CheckerCPU does not work for x86 and is only > verified as working on ARM. It needs some additional work to support > the representation of machine instructions for x86. > > Geoff > > On Tue, May 15, 2012 at 7:43 AM, Gabe Black <gbl...@eecs.umich.edu> wrote: > > The change may have made the branch predictor code behave incorrectly, > > for instance an instruction could execute twice, a misspeculated > > instruction could sneak through and commit, an instruction could be > > skipped, a branch could be "corrected" to go down the wrong path. There > > are lots of things that could go wrong. Alternatively, the branch > > predictor might have just gotten better and put more stress on some > > other part of the CPU, or coincidentally lined up circumstances which > > expose another bug. You should try to find where execution diverges > > between O3 and the atomic CPU, possibly using tracediff or possibly > > using the checker CPU. I'm not sure the checker works correctly with > > x86, but if it does this is pretty much exactly what it's for. > > > > Gabe > > > > On 05/14/12 17:22, mingkai huang wrote: > >> Hi, > >> I tried to use gem5 to run SPEC2006 in x86 O3 mode. When I ran bzip2, > >> it failed with: > >> fatal: Over max stack size for one thread > >> My command line is: > >> build/X86/gem5.fast configs/example/se.py --cpu-type=detailed --caches > >> -c bzip2 -o "input.program 5" > >> The version of my gem5 is 8981. > >> Bzip2 can run correctly in atomic mode. > >> I binary searched where the problem happened first, and found version > >> 8842. I noticed this patch is about branch prediction, and I don't > >> understand why this can affect the correctness of an application. > >> Before 8842, Bzip2 can run correctly in both mode, but the outputed > >> numbers of "info: Increasing stack size by one page." are not equal. > >> Because of email size limitation, I can't attached the file I used. > >> > > > > _______________________________________________ > > 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 >
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
