It may be that it's the split request test that's broken... it would be
interesting to check whether wrapping around to address 0 is the correct
behavior or not. At least in some old segmented addressing modes on x86, I
believe that the system did support address wraparound (not so much
I think I've found the problem; it has less to do with split memory
requests and more to do with integer overflow (register a1's value of -1
should have tipped me off earlier). Basically, splitRequest() only checks
if the request crosses a cache boundary by testing if the address of the
last byte
If your ISA doesn't support unaligned accesses, the page table code should
return a fault (architectural or made up) and return that. If it does and
you're not expecting one that's a different story since it indicates some
other bit of code isn't doing it's job, for instance not splitting up an
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
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
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.
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
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
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
