qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/5] s390x/gdb: don't touch the cc if tcg is not


From: Christian Borntraeger
Subject: Re: [Qemu-devel] [PATCH 1/5] s390x/gdb: don't touch the cc if tcg is not enabled
Date: Fri, 05 Sep 2014 09:29:24 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0

On 03/09/14 11:27, Alexander Graf wrote:
> 
> 
> On 02.09.14 09:07, Christian Borntraeger wrote:
>> On 02/09/14 00:39, Alexander Graf wrote:
>>>
>>>
>>> On 29.08.14 15:52, Jens Freimann wrote:
>>>> From: David Hildenbrand <address@hidden>
>>>>
>>>> When reading/writing the psw mask, the condition code may only be touched 
>>>> if
>>>> running on tcg.
>>>
>>> Why? Shouldn't we be able to set CC from gdb as well?
>>>
>>
>> You can. What this patch does (and the patch description is a bit vague 
>> here) is to not modify the PSW it gets from KVM when passing it to gdb:
>> The qemu core gets the PSW from KVM. Without this patch, we use cc_op to 
>> calculate the current CC of the PSW (No idea of TCG, I guess its evaluated 
>> lazy - at least this is how valgrind works). This is wrong for the KVM case, 
>> as cc_op does not contain any useful data for the KVM case. With this patch 
>> we simply pass the psw from KVM to gdb and back.
>>
>> The symptom was that the cc was always shown as zero.
> 
> Ah, I see. I agree with the patch, but the patch description does not
> actually describe what the patch does. Please rework it.

The patch was already pulled...Well the description is misleaded but with some 
interpretion still correct ;-).
But your point is well taken. We will try to make sure that all patch 
description are descriptive and not ambiguous. Your question is a good 
indication that this was not the case in this patch.

Christian

 
> I also wouldn't mind if instead of hard coding this logic in the
> gdbstub, we'd extract it as helper functions to read and write the
> PSW.MASK in cpu.h.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]