Claudio Imbrenda writes:
> On 27/01/17 18:07, Alex Bennée wrote:
>>
>> Claudio Imbrenda writes:
>>
>>> When GDB issues a "vCont", QEMU was not handling it correctly when
>>> multiple VCPUs are active.
>>> For vCont, for each thread (VCPU), it can be specified whether to
>>> single step, continu
On 27/01/17 18:07, Alex Bennée wrote:
>
> Claudio Imbrenda writes:
>
>> When GDB issues a "vCont", QEMU was not handling it correctly when
>> multiple VCPUs are active.
>> For vCont, for each thread (VCPU), it can be specified whether to
>> single step, continue or stop that thread. The default
Claudio Imbrenda writes:
> When GDB issues a "vCont", QEMU was not handling it correctly when
> multiple VCPUs are active.
> For vCont, for each thread (VCPU), it can be specified whether to
> single step, continue or stop that thread. The default is to stop a
> thread.
> However, when (for exam
Claudio Imbrenda writes:
> When GDB issues a "vCont", QEMU was not handling it correctly when
> multiple VCPUs are active.
> For vCont, for each thread (VCPU), it can be specified whether to
> single step, continue or stop that thread. The default is to stop a
> thread.
> However, when (for exam
Closing the loop here:
On 10/28/2016 03:25 PM, Claudio Imbrenda wrote:
>> Maybe I should just remove all mentions of a "default" from the text?
...
>> Would that help ?
>
> that makes it even more clear (and simple).
> On the other hand, now expressing more than one default is not
> considered
On 28/10/16 16:01, Pedro Alves wrote:
>> From the new specifications I seem to understand that if I specify a
>> default as first action, then no further actions will be considered,
>> since it matches all threads?
>
> Right.
ok, that's the way I understand the new specs, which is not how I had
u
On 10/28/2016 02:35 PM, Claudio Imbrenda wrote:
> On 27/10/16 13:40, Pedro Alves wrote:
>> I'm not a qemu gdbstub expert, but FYI, seeing this reminded me to push
>> to gdb's master a (getting old) gdb patch that clarifies how vCont actions
>> should be interpreted:
>>
>> https://sourceware.org/ml
On 27/10/16 13:40, Pedro Alves wrote:
> I'm not a qemu gdbstub expert, but FYI, seeing this reminded me to push
> to gdb's master a (getting old) gdb patch that clarifies how vCont actions
> should be interpreted:
>
> https://sourceware.org/ml/gdb-patches/2016-02/msg00493.html
>
> It's already l
On 10/26/2016 08:56 AM, Christian Borntraeger wrote:
> On 10/14/2016 01:53 PM, Claudio Imbrenda wrote:
>> When GDB issues a "vCont", QEMU was not handling it correctly when
>> multiple VCPUs are active.
>> For vCont, for each thread (VCPU), it can be specified whether to
>> single step, continue or
On 10/14/2016 01:53 PM, Claudio Imbrenda wrote:
> When GDB issues a "vCont", QEMU was not handling it correctly when
> multiple VCPUs are active.
> For vCont, for each thread (VCPU), it can be specified whether to
> single step, continue or stop that thread. The default is to stop a
> thread.
> How
When GDB issues a "vCont", QEMU was not handling it correctly when
multiple VCPUs are active.
For vCont, for each thread (VCPU), it can be specified whether to
single step, continue or stop that thread. The default is to stop a
thread.
However, when (for example) "vCont;s:2" is issued, all VCPUs co
11 matches
Mail list logo
