From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1079 invoked by alias); 5 Feb 2014 15:14:24 -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 909 invoked by uid 89); 5 Feb 2014 15:14:22 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: na01-bn1-obe.outbound.protection.outlook.com Received: from mail-bn1blp0183.outbound.protection.outlook.com (HELO na01-bn1-obe.outbound.protection.outlook.com) (207.46.163.183) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 05 Feb 2014 15:14:20 +0000 Received: from DM2PR03MB368.namprd03.prod.outlook.com (10.141.55.22) by BY2PR03MB175.namprd03.prod.outlook.com (10.242.36.148) with Microsoft SMTP Server (TLS) id 15.0.868.8; Wed, 5 Feb 2014 15:14:15 +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 15:14:14 +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 15:14:00 -0000 Message-ID: <44348468ed874843813d95b7753d64b2@DM2PR03MB368.namprd03.prod.outlook.com> References: <5651102df70243a088e7688170617c31@DM2PR03MB368.namprd03.prod.outlook.com> <52F1351F.8090608@redhat.com> <52F2510A.3010500@redhat.com> In-Reply-To: <52F2510A.3010500@redhat.com> x-forefront-prvs: 01136D2D90 x-forefront-antispam-report: SFV:NSPM;SFS:(10009001)(6009001)(164054003)(51444003)(51704005)(13464003)(24454002)(479174003)(377454003)(199002)(189002)(83072002)(83322001)(94316002)(76786001)(86362001)(94946001)(19580405001)(85852003)(93136001)(74876001)(47736001)(46102001)(87936001)(74662001)(65816001)(90146001)(93516002)(56816005)(81686001)(49866001)(33646001)(47976001)(76796001)(74502001)(50986001)(4396001)(66066001)(54356001)(53806001)(54316002)(56776001)(77982001)(92566001)(69226001)(87266001)(74316001)(80022001)(2656002)(59766001)(31966008)(76576001)(63696002)(74706001)(47446002)(85306002)(19580395003)(81816001)(74366001)(81542001)(51856001)(79102001)(80976001)(76482001)(81342001)(24736002);DIR:OUT;SFP:1101;SCL:1;SRVR:BY2PR03MB175;H:DM2PR03MB368.namprd03.prod.outlook.com;CLIP:192.88.166.1;FPR:C6CFC017.AC1E9719.B2E337B8.52F4D2BD.204E0;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/msg00013.txt.bz2 Hi, Thanks for your advice and clarifications. Your proposed solution seems the right way to go, I will try it out. Regards, Alex > -----Original Message----- > From: Pedro Alves [mailto:palves@redhat.com] > Sent: Wednesday, February 05, 2014 4:56 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/05/2014 02:07 PM, alexandru.sardan@freescale.com wrote: > > 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 > >> > >> 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. > >> > >> 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. > >> > > > > [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. >=20 > That's just going against what "target remote" is designed to do. > It's in Just Don't Do That, territory. >=20 > By design, "target remote" assumes a debugging session is already > ongoing. > It sounds to me extended-remote is a better map to what you want to > do. >=20 > > Is there any other way to recompute the description without disconnect? > > When using GDB with Eclipse DSF, issuing a disconnect terminates the > DSF > > session. >=20 > Here's what I suggest you do: >=20 > - connect with "target extended-remote" instead of "target remote". The > main difference here is that extended-remote allows connecting to a > target > that is not running yet. > - if not configured yet, have the probe reply W00 to the status ("?") > packet. > (With that, GDB knows that nothing is running yet, but remains > connected.) > - Teach the probe about the vAttach packet (support for "attach") > - after connecting and finding no program is running (probe is not > configured), issue the necessary monitor commands for setup, and end > with an > attach -- e.g., "attach 1" ("1" being just a dummy pid so that GDB > doesn't > complain, but you can give it any meaning you want, if you want. > - GDB issues the vAttach packet. > - the probe reacts to vAttach the same way it's reacting to whatever > monitor command you've implemented that starts the debug session. > - GDB fetches the target description, etc. at this point, and fetches > the current registers, etc. > - debug session is active. >=20 > Absolutely no change to GDB is required then. >=20 > (you can play with extended-remote with gdbserver to get a feel -- pass > it the --multi switch) >=20 > >> If we don't shrink it, then we'd send too much when writing > >> registers, for example, I think? > >> > > > > [Alex S=E3rdan] Shouldn't this check be handled in the server, since I'm > loading > > up an XML with the (presumably) correct hardware description? >=20 > What sort of check are you thinking? All it could possibly do is > either error out, or ignore the extra registers. The former > isn't a good indication to GDB that it should write with 'P', > and the latter is just, well, nasty. >=20 > -- > Pedro Alves >=20 >=20