From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20337 invoked by alias); 4 Feb 2014 18:44:53 -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 20323 invoked by uid 89); 4 Feb 2014 18:44:52 -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; Tue, 04 Feb 2014 18:44:51 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s14IinfV021989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Feb 2014 13:44:49 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s14IimkN006743; Tue, 4 Feb 2014 13:44:48 -0500 Message-ID: <52F1351F.8090608@redhat.com> Date: Tue, 04 Feb 2014 18:44: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> In-Reply-To: <5651102df70243a088e7688170617c31@DM2PR03MB368.namprd03.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-02/txt/msg00005.txt.bz2 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. > 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. > > Why is rsa->sizeof_g_packet shrunk when a smaller packet is received. /* 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) { If we don't shrink it, then we'd send too much when writing registers, for example, I think? -- Pedro Alves