I just found a case somewhat related to this. Not exactly an assertion, but a segfault from the mispredicated path (non)instructions.
When the operand register index is out of the range, the call to timeBuffer.advance() right after the renaming of such registers causes segfault . I bypassed this problem by making that out-of-bound register index to ZERO registers during the renaming (more particularly, during index flattening). I think raising a fault would be a better solution, but holding off from actually doing it. Any suggestion would be appreciated. ps. is the [m5-dev] tag in the title added by the mailing list, or should I add it myself? Thanks, Min On Mon, Jun 14, 2010 at 3:52 PM, Gabriel Michael Black < [email protected]> wrote: > It's important to distinguish between M5 making sense, and the code it's > executing making sense. We shouldn't (and I hope don't) have any asserts > that check conditions controllable from the simulated code since those > should generally just cause a fault and may, as you point out, be > mispeculated. It's fine to check that M5 is internally consistent, though. > This is supposed to work in all the CPU models and as far as I know > generally does. M5's CPU models should, to the first order, correctly do > whatever whacky, nonsensical things the instruction memory tells it to do > without complaining. If you've found a case where it doesn't (which has > happened before) please let us know so we can fix it. > > Gabe > > > Quoting Min Kyu Jeong <[email protected]>: > > Is it possible that the speculatively fetched instructions can cause >> programming assertions to fail? Until a branch is resolved, whatever (even >> non-instructions) in the predicted path could be fetched and decoded. >> Can't >> assertions on instruction sanity fail for those? >> >> I am trying to make O3 CPU model for ARM working. In many cases the first >> instruction is a branch followed by a interrupt vector table. I was >> wondering if such cases exist for other CPU models and if it is, handled >> how. >> >> Thanks, >> >> Min >> >> > > _______________________________________________ > 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
