Re: [Qemu-devel] [Consult] About SPRs information

[Chen Gang]

Hello all:

At present, I met an issue (I guess, it should be my code bug), I am
analyzing it which may spend quite a few time resources (checking and
reconstructing the code is helpful for analyzing this issue):

 - It is about invalid memory access for ld operation. The related
   tilegx code is "ld r48, r12", the related x86_64 code is
   "mov (%rbx),%rbx".

 - The related invalid address is 0x128020 which is near (but a little
   upper) tilegx rsp.

 - I have ways for analyzing it: we have the related libc source code,
   and the working flow is not quite complex. But it really needs to
   spend me quite a few time resources on it.

At present, for me, I plan to send the reconstructed code to upstream
within 2 days, and continue analyzing (so that other members can also
have a check), but I am not quite sure whether it is suitable.

Welcome any ideas, suggestions and completions.

Thanks.

On 5/2/15 10:42, Chen Gang wrote:
> 
> 
> On 4/29/15 21:32, Chen Gang wrote:
>> On 4/29/15 05:43, Peter Maydell wrote:
>>> On 28 April 2015 at 22:32, Chen Gang <address@hidden> wrote:
>>>> The related information for cmpexch instruction:
>>>>
>>>>   Description
>>>>
>>>>     Compare the 8-byte contents of the CmpValue SPR with the 8-byte
>>>>     value in memory at the address held in the first source register. If
>>>>     the values are not equal, then no memory operation is performed. If
>>>>     the values are equal, the 8-byte quantity from the second source
>>>>     register is written into memory at the address held in the first
>>>>     source register. In either case, the result of the instruc- tion is
>>>>     the value read from memory. The compare and write to memory are
>>>>     atomic and thus can be used for synchronization purposes. This
>>>>     instruction only operates for addresses aligned to a 8-byte boundary.
>>>>     Unaligned memory access causes an Unaligned Data Reference interrupt.
>>>
>>> I suggest you look at how existing CPUs handle this kind of
>>> atomic operation.
>>>
> 
> I finished cmpexch(), referenced to store_exclusive() in arm and alpha.
> Hope what I have done is correct (I guess, it should be).
> 
>  - Save information about cmpexch (add additional variable in CPUState).
> 
>  - Generate an exception for it.
> 
>  - Process the related exception in main.c with start/end_exclusive()
>    just like what alpha or arm has done.
> 
> 
> Thanks.
> 
>> OK, thanks.
>>
> 
> 
>>> I also suggest you stop adding implementations of *new* instructions
>>> and concentrate on getting a basic set into shape for inclusion.
>>> The more stuff you keep adding the bigger your patchset is going
>>> to get and the harder it is going to get to review.
>>>
> 
> Reconstruction the code is really very useful, cmp*, shl?add*, V?int_?.
> That will not only simplify reading, but also speed up coding.
> 
> Thank you for your valuable suggestions again.
> 
>>
>> For me, current code is not quite much, and really easy enough. At
>> present I am still going smoothly (the issues are mainly about
>> understanding new instructions which I shall meet).
>>
>> I still want to reach "display hello world" successfully (it does not
>> seem quite difficult to me), then reconstruct current code, and send
>> patch to upstream.
>>
>> But sorry, it seems I can not finish it within this month (and I shall
>> try to finish within next month).
>>
>>
>> Thanks.
>>
> 

-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed