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
