Could you be more specific? There are a lot of register related
indexes and I'm not sure exactly which ones you're talking about.
Could you walk through what's happening from the illegal encoding,
through the decoder, through the CPU and up to the segfault? I don't
totally understand the mechanics of the failure at the moment, but my
gut reaction is that the decoder should have returned an
"Unknown(machInst)" when the index was out of bounds. I'm not
convinced that's what's happening, though.
Gabe
Quoting Min Kyu Jeong <[email protected]>:
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
