There used to be a problem that looked similar to this one where an ld instruction would cross a cache line, and to fix that I was advised to look at the splitRequest() function for help. In doing so, I found that initiateMemRead() in BaseDynInst already calls it if the ISA supports unaligned memory accesses, so I set RISC-V to do that and that problem was fixed. I haven't looked at x86's implementation of anything yet due to its complexity; does x86 have additional code beyond this to handle unaligned accesses?
On Fri, Mar 10, 2017 at 5:14 PM, Steve Reinhardt <[email protected]> wrote: > Have you looked at how x86 supports unaligned accesses? The gem5 memory > system does not support them natively; you have to check if your access is > unaligned, and issue two requests to the cache for the two halves to > guarantee there are no cache line or page crossings within a single > request. > > Steve > > > On Fri, Mar 10, 2017 at 2:06 PM, Alec Roelke <[email protected]> wrote: > > > I get an assertion failure: > > > > build/RISCV/mem/page_table.cc:190: Fault > > PageTableBase::translate(RequestPtr): Assertion > `pageAlign(req->getVaddr() > > + req->getSize() - 1) == pageAlign(req->getVaddr())' failed. > > > > I can't tell from my debug trace (with Exec and Commit flags on) if this > is > > happening during exec or commit. I can see that there's an ld > instruction > > preceding the ret instruction that is supposed to load the correct > address > > into the return-address register, but for some reason is unable to > commit. > > A more complete trace looks like this: > > > > ... > > ret <------------ this ret appears to execute properly > > ld ra,24(sp) <--- this never commits > > li a0,0 > > ld s0,16(sp) > > ld s1,8(sp) > > addi sp,sp,32 > > ret > > ld s1,0(a1) <---- this is executed speculatively, but a1 isn't a valid > > address > > ... > > > > Register a1 contains -1 at this point. > > > > The commit log doesn't show me any information about that last > instruction > > except for when it is inserted into the ROB, which is why I originally > > thought the error was happening during speculation. > > > > On Fri, Mar 10, 2017 at 4:45 PM, Steve Reinhardt <[email protected]> > wrote: > > > > > The instruction should be marked as causing a fault, but the fault > action > > > should not be invoked until the instruction is committed. Because it's > a > > > mis-speculated instruction, it will never be committed, so the fault > > should > > > never be observed. I'm not sure what you mean by "crashes", so I'm not > > sure > > > what part of this process is not operating properly for you. > > > > > > Steve > > > > > > > > > On Fri, Mar 10, 2017 at 1:40 PM, Alec Roelke <[email protected]> > wrote: > > > > > > > Hello Everyone, > > > > > > > > I'm trying to debug RISC-V running on the O3 model, and I've > > encountered > > > a > > > > problem where the CPU tries to speculatively execute a load > instruction > > > > (which is actually along a branch that ends up not being taken) in > > which > > > > the data crosses a page boundary and causes a fault. > > > > > > > > The specific section of code looks like this: > > > > > > > > ... > > > > ret > > > > ld s1,0(a1) > > > > ... > > > > > > > > If you're not familiar with RISC-V, ret is a pseudo-instruction that > > just > > > > jumps to whatever address is stored in the return-address register, > and > > > ld > > > > loads a 64-bit value from memory. > > > > > > > > The problem I'm encountering is that the value stored in register a1 > is > > > not > > > > a valid address as that instruction is not supposed to be executed, > and > > > it > > > > just so happens that the word it points to crosses a page boundary. > > When > > > > gem5 speculatively executes this, it crashes. > > > > > > > > How can I prevent gem5 from doing this? I know I could flag load and > > > store > > > > instructions as being nonspeculative, but that will slow down > execution > > > and > > > > affect output stats. I'm working on top of these four patches: > > > > > > > > - https://gem5-review.googlesource.com/c/2304/ > > > > - https://gem5-review.googlesource.com/c/2305/5 > > > > - https://gem5-review.googlesource.com/c/2340/2 > > > > - https://gem5-review.googlesource.com/c/2341/2 > > > > > > > > Thanks, > > > > Alec Roelke > > > > _______________________________________________ > > > > gem5-dev mailing list > > > > [email protected] > > > > http://m5sim.org/mailman/listinfo/gem5-dev > > > _______________________________________________ > > > gem5-dev mailing list > > > [email protected] > > > http://m5sim.org/mailman/listinfo/gem5-dev > > _______________________________________________ > > gem5-dev mailing list > > [email protected] > > http://m5sim.org/mailman/listinfo/gem5-dev > > > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
