* [Qemu-devel] [PATCH] gdb: Fix gdb error
@ 2013-08-11 18:14 Aneesh Kumar K.V
2013-08-12 8:48 ` Andreas Färber
0 siblings, 1 reply; 4+ messages in thread
From: Aneesh Kumar K.V @ 2013-08-11 18:14 UTC (permalink / raw)
To: qemu-devel, Andreas Färber; +Cc: aliguori, Aneesh Kumar K.V
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Don't update the global register count if not requested.
Without this patch a remote gdb session gives
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
Remote 'g' packet reply is too long:
0000000028000084c000000000ccba50c000000000c ...
....
...
(gdb)
This is a regression introduce by a0e372f0c49ac01faeaeb73a6e8f50e8ac615f34
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
gdbstub.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/gdbstub.c b/gdbstub.c
index 1af25a6..4b58a1e 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -598,6 +598,12 @@ void gdb_register_coprocessor(CPUState *cpu,
{
GDBRegisterState *s;
GDBRegisterState **p;
+ static int last_reg;
+ CPUClass *cc = CPU_GET_CLASS(cpu);
+
+ if (!last_reg) {
+ last_reg = cc->gdb_num_core_regs;
+ }
p = &cpu->gdb_regs;
while (*p) {
@@ -608,19 +614,21 @@ void gdb_register_coprocessor(CPUState *cpu,
}
s = g_new0(GDBRegisterState, 1);
- s->base_reg = cpu->gdb_num_regs;
+ s->base_reg = last_reg;
s->num_regs = num_regs;
s->get_reg = get_reg;
s->set_reg = set_reg;
s->xml = xml;
/* Add to end of list. */
- cpu->gdb_num_regs += num_regs;
+ last_reg += num_regs;
*p = s;
if (g_pos) {
if (g_pos != s->base_reg) {
fprintf(stderr, "Error: Bad gdb register numbering for '%s'\n"
"Expected %d got %d\n", xml, g_pos, s->base_reg);
+ } else {
+ cpu->gdb_num_regs = last_reg;
}
}
}
--
1.8.1.2
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] [PATCH] gdb: Fix gdb error
2013-08-11 18:14 [Qemu-devel] [PATCH] gdb: Fix gdb error Aneesh Kumar K.V
@ 2013-08-12 8:48 ` Andreas Färber
2013-08-12 9:17 ` Aneesh Kumar K.V
0 siblings, 1 reply; 4+ messages in thread
From: Andreas Färber @ 2013-08-12 8:48 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: aliguori, qemu-devel
Hi Aneesh,
Am 11.08.2013 20:14, schrieb Aneesh Kumar K.V:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>
> Don't update the global register count if not requested.
> Without this patch a remote gdb session gives
>
> (gdb) target remote localhost:1234
> Remote debugging using localhost:1234
> Remote 'g' packet reply is too long:
> 0000000028000084c000000000ccba50c000000000c ...
> ....
> ...
> (gdb)
>
> This is a regression introduce by a0e372f0c49ac01faeaeb73a6e8f50e8ac615f34
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Thanks for tracking this down. I'm willing to include a variation in
today's pull to fix 1.6.0-rc3. However, did you find an explanation
*why* it needs to be like this? I understand it is a revert to using the
static variable, updated to using the CPUClass field rather than the
previous preprocessor constant.
> ---
> gdbstub.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/gdbstub.c b/gdbstub.c
> index 1af25a6..4b58a1e 100644
> --- a/gdbstub.c
> +++ b/gdbstub.c
> @@ -598,6 +598,12 @@ void gdb_register_coprocessor(CPUState *cpu,
> {
> GDBRegisterState *s;
> GDBRegisterState **p;
> + static int last_reg;
> + CPUClass *cc = CPU_GET_CLASS(cpu);
> +
> + if (!last_reg) {
> + last_reg = cc->gdb_num_core_regs;
> + }
>
> p = &cpu->gdb_regs;
> while (*p) {
> @@ -608,19 +614,21 @@ void gdb_register_coprocessor(CPUState *cpu,
> }
>
> s = g_new0(GDBRegisterState, 1);
> - s->base_reg = cpu->gdb_num_regs;
> + s->base_reg = last_reg;
> s->num_regs = num_regs;
> s->get_reg = get_reg;
> s->set_reg = set_reg;
> s->xml = xml;
>
> /* Add to end of list. */
> - cpu->gdb_num_regs += num_regs;
> + last_reg += num_regs;
> *p = s;
> if (g_pos) {
> if (g_pos != s->base_reg) {
> fprintf(stderr, "Error: Bad gdb register numbering for '%s'\n"
> "Expected %d got %d\n", xml, g_pos, s->base_reg);
> + } else {
> + cpu->gdb_num_regs = last_reg;
This bit looks wrong to me - it is updating the per-CPU count with the
global value. Could you retest without this please?
Regards,
Andreas
> }
> }
> }
>
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] [PATCH] gdb: Fix gdb error
2013-08-12 8:48 ` Andreas Färber
@ 2013-08-12 9:17 ` Aneesh Kumar K.V
2013-08-12 17:40 ` Andreas Färber
0 siblings, 1 reply; 4+ messages in thread
From: Aneesh Kumar K.V @ 2013-08-12 9:17 UTC (permalink / raw)
To: Andreas Färber; +Cc: aliguori, qemu-devel
Andreas Färber <afaerber@suse.de> writes:
> Hi Aneesh,
>
> Am 11.08.2013 20:14, schrieb Aneesh Kumar K.V:
>> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>>
>> Don't update the global register count if not requested.
>> Without this patch a remote gdb session gives
>>
>> (gdb) target remote localhost:1234
>> Remote debugging using localhost:1234
>> Remote 'g' packet reply is too long:
>> 0000000028000084c000000000ccba50c000000000c ...
>> ....
>> ...
>> (gdb)
>>
>> This is a regression introduce by a0e372f0c49ac01faeaeb73a6e8f50e8ac615f34
>>
>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>
> Thanks for tracking this down. I'm willing to include a variation in
> today's pull to fix 1.6.0-rc3. However, did you find an explanation
> *why* it needs to be like this?
IIUC our reply packet for 'g' contain more data becaue we ended up with
larger cpu->gdb_num_regs. This only happens for archs that do a
gdb_register_coprocessor with gpos == 0. The older code didn't update
num_g_regs in that case. Not sure why we do like that
> I understand it is a revert to using the
> static variable, updated to using the CPUClass field rather than the
> previous preprocessor constant.
>
I don't really like the patch. But I also don't know enough to fix this
without using the static variable. If you want me to try another
version please send it across. I can easily reproduce this on PowerPC.
>> ---
>> gdbstub.c | 12 ++++++++++--
>> 1 file changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/gdbstub.c b/gdbstub.c
>> index 1af25a6..4b58a1e 100644
>> --- a/gdbstub.c
>> +++ b/gdbstub.c
>> @@ -598,6 +598,12 @@ void gdb_register_coprocessor(CPUState *cpu,
>> {
>> GDBRegisterState *s;
>> GDBRegisterState **p;
>> + static int last_reg;
>> + CPUClass *cc = CPU_GET_CLASS(cpu);
>> +
>> + if (!last_reg) {
>> + last_reg = cc->gdb_num_core_regs;
>> + }
>>
>> p = &cpu->gdb_regs;
>> while (*p) {
>> @@ -608,19 +614,21 @@ void gdb_register_coprocessor(CPUState *cpu,
>> }
>>
>> s = g_new0(GDBRegisterState, 1);
>> - s->base_reg = cpu->gdb_num_regs;
>> + s->base_reg = last_reg;
>> s->num_regs = num_regs;
>> s->get_reg = get_reg;
>> s->set_reg = set_reg;
>> s->xml = xml;
>>
>> /* Add to end of list. */
>> - cpu->gdb_num_regs += num_regs;
>> + last_reg += num_regs;
>> *p = s;
>> if (g_pos) {
>> if (g_pos != s->base_reg) {
>> fprintf(stderr, "Error: Bad gdb register numbering for '%s'\n"
>> "Expected %d got %d\n", xml, g_pos, s->base_reg);
>
>> + } else {
>> + cpu->gdb_num_regs = last_reg;
>
> This bit looks wrong to me - it is updating the per-CPU count with the
> global value. Could you retest without this please?
>
We loop with cpu->gdb_num_regs as below in gdb_handle_packet.
- for (addr = 0; addr < num_g_regs && len > 0; addr++) {
+ for (addr = 0; addr < s->g_cpu->gdb_num_regs && len > 0; addr++) {
We updated num_g_regs if g_pos is not set before
a0e372f0c49ac01faeaeb73a6e8f50e8ac615f34
@@ -2036,25 +2003,22 @@ void gdb_register_coprocessor(CPUState *cpu,
}
s = g_new0(GDBRegisterState, 1);
- s->base_reg = last_reg;
+ s->base_reg = cpu->gdb_num_regs;
s->num_regs = num_regs;
s->get_reg = get_reg;
s->set_reg = set_reg;
s->xml = xml;
/* Add to end of list. */
- last_reg += num_regs;
+ cpu->gdb_num_regs += num_regs;
*p = s;
if (g_pos) {
if (g_pos != s->base_reg) {
fprintf(stderr, "Error: Bad gdb register numbering for '%s'\n"
"Expected %d got %d\n", xml, g_pos, s->base_reg);
- } else {
- num_g_regs = last_reg;
}
}
}
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] [PATCH] gdb: Fix gdb error
2013-08-12 9:17 ` Aneesh Kumar K.V
@ 2013-08-12 17:40 ` Andreas Färber
0 siblings, 0 replies; 4+ messages in thread
From: Andreas Färber @ 2013-08-12 17:40 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: aliguori, qemu-devel
Am 12.08.2013 11:17, schrieb Aneesh Kumar K.V:
> Andreas Färber <afaerber@suse.de> writes:
>> Am 11.08.2013 20:14, schrieb Aneesh Kumar K.V:
>>> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>>>
>>> Don't update the global register count if not requested.
>>> Without this patch a remote gdb session gives
>>>
>>> (gdb) target remote localhost:1234
>>> Remote debugging using localhost:1234
>>> Remote 'g' packet reply is too long:
>>> 0000000028000084c000000000ccba50c000000000c ...
>>> ....
>>> ...
>>> (gdb)
>>>
>>> This is a regression introduce by a0e372f0c49ac01faeaeb73a6e8f50e8ac615f34
>>>
>>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>>
>> Thanks for tracking this down. I'm willing to include a variation in
>> today's pull to fix 1.6.0-rc3. However, did you find an explanation
>> *why* it needs to be like this?
>
> IIUC our reply packet for 'g' contain more data becaue we ended up with
> larger cpu->gdb_num_regs. This only happens for archs that do a
> gdb_register_coprocessor with gpos == 0. The older code didn't update
> num_g_regs in that case. Not sure why we do like that
>
>> I understand it is a revert to using the
>> static variable, updated to using the CPUClass field rather than the
>> previous preprocessor constant.
>>
>
> I don't really like the patch. But I also don't know enough to fix this
> without using the static variable. If you want me to try another
> version please send it across. I can easily reproduce this on PowerPC.
While it's always unfortunate to have a known breakage, we decided it's
too late/risky to address this for -rc3 today.
I put together a different patch that hopefully fixes the breakage while
avoiding to revert to static variables:
http://patchwork.ozlabs.org/patch/266594/
If this fixes things for you and doesn't break other things, we can get
it into qemu.git after Thursday [1] and backport it into 1.6.1.
Regards,
Andreas
[1] http://wiki.qemu.org/Planning/1.6
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-08-12 17:40 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-08-11 18:14 [Qemu-devel] [PATCH] gdb: Fix gdb error Aneesh Kumar K.V
2013-08-12 8:48 ` Andreas Färber
2013-08-12 9:17 ` Aneesh Kumar K.V
2013-08-12 17:40 ` Andreas Färber
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).