I haven't looked at the source directly to see how much of the unaligned access code is in x86-specific code vs. generic code, and I don't remember off the top of my head. I'm glad to hear that the splitRequest() call is in the generic part of the code.
The symptom that you're getting implies that the TLB is being accessed with a non-split unaligned request though, so there must be some code path where this is not handled automatically by setting HasUnalignedMemAcc. I'd suggest getting a stack trace from where you hit this assertion to see where this call is coming from, and why it's not using the split version of the requests. Steve On Fri, Mar 10, 2017 at 3:06 PM, Alec Roelke <[email protected]> wrote: > 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 > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
