From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25503 invoked by alias); 5 Feb 2014 14:07:50 -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 25487 invoked by uid 89); 5 Feb 2014 14:07:49 -0000 Authentication-Results: sourceware.org; auth=none 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-bl2lp0203.outbound.protection.outlook.com (HELO na01-bl2-obe.outbound.protection.outlook.com) (207.46.163.203) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 05 Feb 2014 14:07:47 +0000 Received: from DM2PR03MB368.namprd03.prod.outlook.com (10.141.55.22) by BL2PR03MB164.namprd03.prod.outlook.com (10.255.230.148) with Microsoft SMTP Server (TLS) id 15.0.868.8; Wed, 5 Feb 2014 14:07:31 +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; Wed, 5 Feb 2014 14:07:31 +0000 From: "alexandru.sardan@freescale.com" To: Pedro Alves CC: "gdb@sourceware.org" , "catalin.udma@freescale.com" Subject: RE: 'g' packet reply is too long error when target changes number of registers Date: Wed, 05 Feb 2014 14:07:00 -0000 Message-ID: References: <5651102df70243a088e7688170617c31@DM2PR03MB368.namprd03.prod.outlook.com> <52F1351F.8090608@redhat.com> In-Reply-To: <52F1351F.8090608@redhat.com> x-forefront-prvs: 01136D2D90 x-forefront-antispam-report: SFV:NSPM;SFS:(10009001)(6009001)(24454002)(164054003)(51444003)(199002)(189002)(13464003)(51704005)(479174003)(377454003)(63696002)(80976001)(81342001)(93136001)(65816001)(69226001)(85852003)(77982001)(59766001)(81542001)(76796001)(90146001)(83072002)(93516002)(2656002)(76576001)(31966008)(94316002)(94946001)(33646001)(4396001)(87266001)(54316002)(74876001)(66066001)(47736001)(47446002)(74502001)(81816001)(86362001)(74316001)(83322001)(50986001)(47976001)(49866001)(46102001)(74662001)(51856001)(19580405001)(76786001)(87936001)(80022001)(56816005)(79102001)(74706001)(54356001)(76482001)(81686001)(56776001)(74366001)(92566001)(85306002)(19580395003)(53806001)(24736002);DIR:OUT;SFP:1101;SCL:1;SRVR:BL2PR03MB164;H:DM2PR03MB368.namprd03.prod.outlook.com;CLIP:192.88.166.1;FPR:86DCC4F4.9C1E9712.B2E337BB.52F5DEBD.203DE;InfoNoRecordsA:1;MX:1;LANG:en; Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: freescale.com X-IsSubscribed: yes X-SW-Source: 2014-02/txt/msg00011.txt.bz2 Hi, See my comments inline. Thanks, Alex > -----Original Message----- > From: Pedro Alves [mailto:palves@redhat.com] > Sent: Tuesday, February 04, 2014 8:45 PM > To: Sardan Alexandru Cezar-B41700 > Cc: gdb@sourceware.org; Udma Catalin-Dan-B32721 > Subject: Re: 'g' packet reply is too long error when target changes > number of registers >=20 > On 02/03/2014 02:11 PM, alexandru.sardan@freescale.com wrote: > > 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 > > 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 > > error. > > >=20 > > Because the probe had no knowledge of the target that will be debugged > > beforehand, the "target remote" command will force the probe to reply > with > > info about a smaller number of registers (according to the default > description) > > than gdb expects. >=20 > This sounds odd. Why not? Simply configure it before connecting > with GDB? It sounds quite wrong to be changing the target behind > GDB's back when GDB is _already_ debugging it. Not just the size > of the g/G packets may change inadvertently, but the layout as well. > If the target description changes with your re-configuration, it > sounds to me like GDB should fetch/recompute the whole target > description. Today, I think that can only be done with a > disconnect/reconnect. > =20 [Alex S=E3rdan] In our case "target remote" doesn't start the debug session, it only connects to the probe. To start debugging we issue some monitor commands in order to configure the probe. Is there any other way to recompute the description without disconnect? When using GDB with Eclipse DSF, issuing a disconnect terminates the DSF session. > > This causes rsa->sizeof_g_packet to be reduced. > > > > After configuration, the probe will send all the register information > of the > > target. This causes the 'g'packet reply error because now, more > registers > > are being sent. >=20 > > > > Why is rsa->sizeof_g_packet shrunk when a smaller packet is received. >=20 > /* If this is smaller than we guessed the 'g' packet would be, > update our records. A 'g' reply that doesn't include a register's > value implies either that the register is not available, or that > the 'p' packet must be used. */ > if (buf_len < 2 * rsa->sizeof_g_packet) > { >=20 > If we don't shrink it, then we'd send too much when writing > registers, for example, I think? >=20 [Alex S=E3rdan] Shouldn't this check be handled in the server, since I'm lo= ading up an XML with the (presumably) correct hardware description? > -- > Pedro Alves >=20 >=20