From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14622 invoked by alias); 3 Feb 2014 14:12:15 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 14611 invoked by uid 89); 3 Feb 2014 14:12:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: na01-bl2-obe.outbound.protection.outlook.com Received: from mail-bl2lp0211.outbound.protection.outlook.com (HELO na01-bl2-obe.outbound.protection.outlook.com) (207.46.163.211) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 03 Feb 2014 14:12:12 +0000 Received: from DM2PR03MB368.namprd03.prod.outlook.com (10.141.55.22) by BN1PR03MB170.namprd03.prod.outlook.com (10.255.200.147) with Microsoft SMTP Server (TLS) id 15.0.868.8; Mon, 3 Feb 2014 14:11:57 +0000 Received: from DM2PR03MB368.namprd03.prod.outlook.com ([10.141.55.22]) by DM2PR03MB368.namprd03.prod.outlook.com ([10.141.55.22]) with mapi id 15.00.0868.013; Mon, 3 Feb 2014 14:11:56 +0000 From: "alexandru.sardan@freescale.com" To: "gdb@sourceware.org" CC: "catalin.udma@freescale.com" Subject: 'g' packet reply is too long error when target changes number of registers Date: Mon, 03 Feb 2014 14:12:00 -0000 Message-ID: <5651102df70243a088e7688170617c31@DM2PR03MB368.namprd03.prod.outlook.com> x-forefront-prvs: 01110342A5 x-forefront-antispam-report: SFV:NSPM;SFS:(10009001)(6009001)(71364002)(189002)(199002)(87936001)(81686001)(81816001)(85852003)(87266001)(85306002)(19580405001)(83072002)(92566001)(76796001)(46102001)(76576001)(51856001)(76786001)(2656002)(54356001)(76176001)(4396001)(53806001)(83322001)(19580395003)(80976001)(50986001)(47976001)(47736001)(76482001)(90146001)(56816005)(74366001)(66066001)(80022001)(65816001)(94316002)(74876001)(49866001)(47446002)(74662001)(86362001)(74502001)(93516002)(93136001)(81342001)(81542001)(31966008)(54316002)(56776001)(33646001)(79102001)(94946001)(59766001)(77982001)(74706001)(63696002)(69226001)(74316001)(24736002);DIR:OUT;SFP:1101;SCL:1;SRVR:BN1PR03MB170;H:DM2PR03MB368.namprd03.prod.outlook.com;CLIP:192.88.166.1;FPR:8EE0F97C.10B6BF18.B9E33FBF.46E7DABA.203DE;InfoNoRecordsMX:1;A:1;LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: freescale.com X-IsSubscribed: yes X-SW-Source: 2014-02/txt/msg00001.txt.bz2 Hello, I'm trying to debug an ARM Aarch64 target with gdb-cross and I get a 'g' packet reply is too long error in the following scenario: * I debug my ARM target through a probe that has a gdbserver running on it (gdbproxy). * First I load a custom target description in gdb that reflects the current= =20 hardware I am debugging * I connect to the probe with "target remote probe_ip" * Then I configure the probe to connect to the target (using the same target description as the one loaded in GDB) * When I ask for the register Info (info reg), I get the 'g' packet reply=20 error. Because the probe had no knowledge of the target that will be debugged=20 beforehand, the "target remote" command will force the probe to reply with= =20 info about a smaller number of registers (according to the default descript= ion) than gdb expects. This causes rsa->sizeof_g_packet to be reduced. After configuration, the probe will send all the register information of th= e=20 target. This causes the 'g'packet reply error because now, more registers=20 are being sent. Why is rsa->sizeof_g_packet shrunk when a smaller packet is received. Shouldn't this reflect the size in accordance with the target description? I've made a small patch to address this issue. Do you think it's a proper f= ix? Kind regards, Alex Patch follows: =46rom 8cae18e62d544094b160878459624605c0491534 Mon Sep 17 00:00:00 2001 From: Alexandru-Cezar Sardan Date: Tue, 21 Jan 2014 17:45:20 +0200 Subject: [PATCH] Fix remote 'g' packet reply is too long error Fix remote 'g' packet reply is too long error when target architecture is modified. As long as the target description is the same as the hardware, this error will no longer appeear Signed-off-by: Alexandru-Cezar Sardan --- gdb/remote.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/gdb/remote.c b/gdb/remote.c index 7761e00..c29d88a 100644 --- a/gdb/remote.c +++ b/gdb/remote.c @@ -6103,7 +6103,7 @@ process_g_packet (struct regcache *regcache) struct gdbarch *gdbarch =3D get_regcache_arch (regcache); struct remote_state *rs =3D get_remote_state (); struct remote_arch_state *rsa =3D get_remote_arch_state (); - int i, buf_len; + int i, buf_len, reg_pack_sz; char *p; char *regs; =20 @@ -6125,31 +6125,33 @@ process_g_packet (struct regcache *regcache) the 'p' packet must be used. */ if (buf_len < 2 * rsa->sizeof_g_packet) { - rsa->sizeof_g_packet =3D buf_len / 2; + reg_pack_sz =3D buf_len / 2; =20 for (i =3D 0; i < gdbarch_num_regs (gdbarch); i++) { if (rsa->regs[i].pnum =3D=3D -1) continue; =20 - if (rsa->regs[i].offset >=3D rsa->sizeof_g_packet) + if (rsa->regs[i].offset >=3D reg_pack_sz ) rsa->regs[i].in_g_packet =3D 0; else rsa->regs[i].in_g_packet =3D 1; } } + else + reg_pack_sz =3D rsa->sizeof_g_packet; =20 - regs =3D alloca (rsa->sizeof_g_packet); + regs =3D alloca (reg_pack_sz); =20 /* Unimplemented registers read as all bits zero. */ - memset (regs, 0, rsa->sizeof_g_packet); + memset (regs, 0, reg_pack_sz); =20 /* Reply describes registers byte by byte, each byte encoded as two hex characters. Suck them all up, then supply them to the register cacheing/storage mechanism. */ =20 p =3D rs->buf; - for (i =3D 0; i < rsa->sizeof_g_packet; i++) + for (i =3D 0; i < reg_pack_sz; i++) { if (p[0] =3D=3D 0 || p[1] =3D=3D 0) /* This shouldn't happen - we adjusted sizeof_g_packet above. */ --=20 1.7.9.5