From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13298 invoked by alias); 5 Feb 2014 14:56:17 -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 13231 invoked by uid 89); 5 Feb 2014 14:56:17 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 05 Feb 2014 14:56:16 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s15EuCac030770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Feb 2014 09:56:13 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s15EuAC2012574; Wed, 5 Feb 2014 09:56:11 -0500 Message-ID: <52F2510A.3010500@redhat.com> Date: Wed, 05 Feb 2014 14:56:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: "alexandru.sardan@freescale.com" CC: "gdb@sourceware.org" , "catalin.udma@freescale.com" Subject: Re: 'g' packet reply is too long error when target changes number of registers References: <5651102df70243a088e7688170617c31@DM2PR03MB368.namprd03.prod.outlook.com> <52F1351F.8090608@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit X-SW-Source: 2014-02/txt/msg00012.txt.bz2 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. >>> >> >>> 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ãrdan] 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. That's just going against what "target remote" is designed to do. It's in Just Don't Do That, territory. 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. > Is there any other way to recompute the description without disconnect? > When using GDB with Eclipse DSF, issuing a disconnect terminates the DSF > session. Here's what I suggest you do: - 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. Absolutely no change to GDB is required then. (you can play with extended-remote with gdbserver to get a feel -- pass it the --multi switch) >> If we don't shrink it, then we'd send too much when writing >> registers, for example, I think? >> > > [Alex Sãrdan] Shouldn't this check be handled in the server, since I'm loading > up an XML with the (presumably) correct hardware description? 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. -- Pedro Alves