Thanks for the extra info which should be very helpful. Can you please
tell us what the actual bytes are for the junk instruction?
Gabe
Quoting Min Kyu Jeong <[email protected]>:
I looked into this thing, but still don't fully understand how the
out-of-bound reg index causes segfault. Instead, I will just describe what
is happening hoping someone would catch a clue from it.
The register index that goes out of bound is the architectural register
index, stored in StaticInst class _destRegIdx[0]. The particular StaticInst
I am getting this from is MicroLdrUop. In the constructor of the MacroMemOp
(This invalid garbage instruction from mispredicted path is decoded as
LdmStm), MicroLdrUop instances are generated. The destination register
indices for uops are generated from the bit vector, and there is this bit of
code
if (force_user) {
regIdx = instRegInMode(MODE_USER, regIdx);
}
that changes regIdx from 1 to 577. This is stored in _destRegIdx[0] variable
of the MicroLdrUop StaticInst. During renaming, 577 is renamed to 984 = 577
- numLogicalRegs + numPhysicalRegs
This instRegInMode() is what I found suspicous, since the reg window is
handled by ArmISA::flattenIntIndex() call.
Anyways, the the simulation segfaults during advance() function call of the
timebuffer at the end of the NEXT tick. The following is the call stack.
#0 0x000000000040a2fa in RefCounted::decref (this=0x8d4810708d48c84d) at
build/ARM_FS/base/refcnt.hh:51
#1 0x0000000000761daa in RefCountingPtr<BaseO3DynInst<O3CPUImpl> >::del
(this=0x9cd200) at build/ARM_FS/base/refcnt.hh:69
#2 0x0000000000761dc1 in ~RefCountingPtr (this=0x9cd200) at
build/ARM_FS/base/refcnt.hh:85
#3 0x000000000077ebf9 in ~commitComm (this=0x9cd1a8) at
build/ARM_FS/cpu/o3/comm.hh:153
#4 0x000000000077ec49 in ~TimeBufStruct (this=0x9ccec8) at
build/ARM_FS/cpu/o3/comm.hh:110
#5 0x00000000007884c4 in TimeBuffer<TimeBufStruct<O3CPUImpl> >::advance
(this=0x1991038) at build/ARM_FS/base/timebuf.hh:187
#6 0x0000000000798c31 in FullO3CPU<O3CPUImpl>::tick (this=0x198d310) at
build/ARM_FS/cpu/o3/cpu.cc:523
I made this segfault goes away by overriding the idx 577 to 0.
Thanks,
On Wed, Jun 30, 2010 at 2:17 PM, Gabriel Michael Black <
[email protected]> wrote:
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
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
