On 06/03/2015 08:34 PM, Peter Maydell wrote:
> On 3 June 2015 at 13:30, Chen Gang <xili_gchen_5...@hotmail.com> wrote:
>> On 06/03/2015 01:40 AM, Peter Maydell wrote:
>>> On 30 May 2015 at 22:10, Chen Gang <xili_gchen_5...@hotmail.com> wrote:
>>>>
>>>> +#ifdef TARGET_TILEGX
>>>> +
>>>> +static uint64_t get_regval(CPUTLGState *env, uint8_t reg)
>>>> +{
>>>> + if (likely(reg < TILEGX_R_COUNT)) {
>>>> + return env->regs[reg];
>>>> + } else if (reg != TILEGX_R_ZERO) {
>>>> + fprintf(stderr, "invalid register r%d for reading.\n", reg);
>>>> + g_assert_not_reached();
>>>
>>> You don't appear to be guaranteeing that the register value
>>> is < TILEGX_R_COUNT anywhere: get_SrcA_X1() and friends
>>> mask with 0x3f, but that only means you're guaranteed the
>>> value is between 0 and 63, wherease TILEGX_R_COUNT is 56.
>>> What does real hardware do if the encoded register value
>>> is 56..63 ?
>>>
>>
>> At present, it will g_assert_not_reached() too.
>
> No, it is not possible for hardware to assert!
>
>> 56..62 are hidden to
>> outside. So I did not implement them, either. Need we still implement
>> them?
>
> You must do something. You can't allow guest code (even
> broken guest code) to make QEMU assert. You need to find
> out what the hardware does here, and do that.
>
OK, what you said sounds reasonable to me. I will check what to do next
for the 56..62 registers (at present, I guess, we need generate a
hardware exception, and its default handler will do nothing).
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
