From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39379) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V8w6N-0000by-1q for qemu-devel@nongnu.org; Mon, 12 Aug 2013 13:40:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V8w6I-0003SA-7G for qemu-devel@nongnu.org; Mon, 12 Aug 2013 13:40:18 -0400 Received: from cantor2.suse.de ([195.135.220.15]:45330 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V8w6H-0003Rx-UD for qemu-devel@nongnu.org; Mon, 12 Aug 2013 13:40:14 -0400 Message-ID: <52091DF9.1080703@suse.de> Date: Mon, 12 Aug 2013 19:40:09 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1376244860-19714-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com> <5208A169.4010109@suse.de> <87bo53b73y.fsf@linux.vnet.ibm.com> In-Reply-To: <87bo53b73y.fsf@linux.vnet.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] gdb: Fix gdb error List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Aneesh Kumar K.V" Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org Am 12.08.2013 11:17, schrieb Aneesh Kumar K.V: > Andreas F=C3=A4rber writes: >> Am 11.08.2013 20:14, schrieb Aneesh Kumar K.V: >>> From: "Aneesh Kumar K.V" >>> >>> 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 a0e372f0c49ac01faeaeb73a6e8f50e8ac6= 15f34 >>> >>> Signed-off-by: Aneesh Kumar K.V >> >> 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? >=20 > 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 =3D=3D 0. The older code didn't upda= te > num_g_regs in that case. Not sure why we do like that >=20 >> I understand it is a revert to using the >> static variable, updated to using the CPUClass field rather than the >> previous preprocessor constant. >> >=20 > 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 --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg