From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20051 invoked by alias); 29 Nov 2001 15:43:41 -0000 Mailing-List: contact gdb-patches-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 20027 invoked from network); 29 Nov 2001 15:43:38 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by hostedprojects.ges.redhat.com with SMTP; 29 Nov 2001 15:43:38 -0000 Received: from rtl.cygnus.com (cse.cygnus.com [205.180.230.236]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id HAA21471; Thu, 29 Nov 2001 07:43:36 -0800 (PST) Received: (from ezannoni@localhost) by rtl.cygnus.com (8.11.2/8.11.0) id fATFnqS01198; Thu, 29 Nov 2001 10:49:52 -0500 X-Authentication-Warning: krustylu.cygnus.com: ezannoni set sender to ezannoni@cygnus.com using -f From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15366.22816.569221.989718@krustylu.cygnus.com> Date: Mon, 19 Nov 2001 12:17:00 -0000 To: Cristian Alonso Cc: gdb-patches@sourceware.cygnus.com Subject: Re: Debugging PowerPC 860 embedded target with Abatron BDI 2000: Remo te packet too long errors. In-Reply-To: <41FAD0CB3B6BD3118BE600C04F43DB20E88196@CORREO> References: <41FAD0CB3B6BD3118BE600C04F43DB20E88196@CORREO> X-Mailer: VM 6.97 under Emacs 20.7.1 X-SW-Source: 2001-11/txt/msg00343.txt.bz2 Hi, have you tried changing the default architecture that gdb thinks it is dealing with? If your current architecture (use 'show architecture') is powerpc:common, the register set is smaller. Try 'set architecture powerpc:860' Look in rs6000-tdep.c at the 'variants' array. Hope this helps a bit Elena Cristian Alonso writes: > Hi, > I am using an Abatron (Swiss company that makes BDM's which work whith gdb) > BDI2000 to debug an embedded target with a PowerPC 860 CPU using Insight-5.1 > (last prerelease snapshot available). > > After compiing last Insight-5.1 prerelease available and connecting to the > remote target i get lots of the following errors: > (gdb) target remote 172.24.78.42:2001 > Remote debugging using 172.24.78.42:2001 > Remote packet too long: > 000000ff0079800400080bc00000000000000000002be6d8009166100038eb38006f00000000 > 80000000000a00009032006f000000080bc00000000000000000000000000000000000000000 > 0000000000000000000000000000000000000000009171e40091686400000000000080000091 > 65e8009166100000000000798004000000000000000000000000000000000000000000000000 > 0000000000000000000000000000000000000000000000000000000000000000000000000000 > 0000000000000000000000000000000000000000000000000000000000000000000000000000 > 0000000000000000000000000000000000000000000000000000000000000000000000000000 > 0000000000000000000000000000000000000000000000000000000000000000000000000000 > 0000000000000000000000000000000000000000000000000000000000000000000000000000 > 0000000000000000000000000000000000000000000000000000000000000000000000000000 > 00000000002be8d40000903240000002002be8c00000000000000000deadbeefdeadbeefdead > beefdeadbeefdeadbee > Ignoring packet error, continuing... > > After taking a look at GDB's source files, i found function > build_remote_packet_sizes in remote.c, in which > the following lines are executed: > . > . > . > remote_packet_size = 400 - 1; > /* Should REGISTER_BYTES needs more space than the default, adjust > the size accordingly. Remember that each byte is encoded as two > characters. 32 is the overhead for the packet header / > footer. NOTE: cagney/1999-10-26: I suspect that 8 > (``$NN:G...#NN'') is a better guess, the below has been padded a > little. */ > if (REGISTER_BYTES > ((remote_packet_size - 32) / 2)) > remote_packet_size = (REGISTER_BYTES * 2 + 32); > . > . > > Changing the value of remote_packet_size to 5 Kbytes works fine with my > BDI2000. It makes my insight work fine and allows me to laugh at all the > Windriver Visionclick users who told me i would not be able to debug using > "that free software of yours" ;-). > > It seems that i should be able to find the definition of REGISTER_BYTES and > change it to a different value and submit the patch but i have the following > problems: > - I have not been able to find in which file exactly (ppc.h does not seem > to work...)do i have to change the definition of REGISTER_BYTES. > - I do not know which value is correct for this #define (it seems that it > has to be higher, and it has something to do with how many registers do i > have in my arch, but how do i find out?) > > Thanks in advance, > Cristian Alonso Aldama > Development Group Manager > R&D Department > e-mail: calonso@teldat.es > http://www.teldat.es From mboxrd@z Thu Jan 1 00:00:00 1970 From: Elena Zannoni To: Cristian Alonso Cc: gdb-patches@sourceware.cygnus.com Subject: Re: Debugging PowerPC 860 embedded target with Abatron BDI 2000: Remote packet too long errors. Date: Thu, 29 Nov 2001 07:43:00 -0000 Message-ID: <15366.22816.569221.989718@krustylu.cygnus.com> References: <41FAD0CB3B6BD3118BE600C04F43DB20E88196@CORREO> X-SW-Source: 2001-11/msg00558.html Message-ID: <20011129074300.1K0df8gJq6ebMppys0Uvh6-AvPKLVzAAZg55rRTO4Ts@z> Hi, have you tried changing the default architecture that gdb thinks it is dealing with? If your current architecture (use 'show architecture') is powerpc:common, the register set is smaller. Try 'set architecture powerpc:860' Look in rs6000-tdep.c at the 'variants' array. Hope this helps a bit Elena Cristian Alonso writes: > Hi, > I am using an Abatron (Swiss company that makes BDM's which work whith gdb) > BDI2000 to debug an embedded target with a PowerPC 860 CPU using Insight-5.1 > (last prerelease snapshot available). > > After compiing last Insight-5.1 prerelease available and connecting to the > remote target i get lots of the following errors: > (gdb) target remote 172.24.78.42:2001 > Remote debugging using 172.24.78.42:2001 > Remote packet too long: > 000000ff0079800400080bc00000000000000000002be6d8009166100038eb38006f00000000 > 80000000000a00009032006f000000080bc00000000000000000000000000000000000000000 > 0000000000000000000000000000000000000000009171e40091686400000000000080000091 > 65e8009166100000000000798004000000000000000000000000000000000000000000000000 > 0000000000000000000000000000000000000000000000000000000000000000000000000000 > 0000000000000000000000000000000000000000000000000000000000000000000000000000 > 0000000000000000000000000000000000000000000000000000000000000000000000000000 > 0000000000000000000000000000000000000000000000000000000000000000000000000000 > 0000000000000000000000000000000000000000000000000000000000000000000000000000 > 0000000000000000000000000000000000000000000000000000000000000000000000000000 > 00000000002be8d40000903240000002002be8c00000000000000000deadbeefdeadbeefdead > beefdeadbeefdeadbee > Ignoring packet error, continuing... > > After taking a look at GDB's source files, i found function > build_remote_packet_sizes in remote.c, in which > the following lines are executed: > . > . > . > remote_packet_size = 400 - 1; > /* Should REGISTER_BYTES needs more space than the default, adjust > the size accordingly. Remember that each byte is encoded as two > characters. 32 is the overhead for the packet header / > footer. NOTE: cagney/1999-10-26: I suspect that 8 > (``$NN:G...#NN'') is a better guess, the below has been padded a > little. */ > if (REGISTER_BYTES > ((remote_packet_size - 32) / 2)) > remote_packet_size = (REGISTER_BYTES * 2 + 32); > . > . > > Changing the value of remote_packet_size to 5 Kbytes works fine with my > BDI2000. It makes my insight work fine and allows me to laugh at all the > Windriver Visionclick users who told me i would not be able to debug using > "that free software of yours" ;-). > > It seems that i should be able to find the definition of REGISTER_BYTES and > change it to a different value and submit the patch but i have the following > problems: > - I have not been able to find in which file exactly (ppc.h does not seem > to work...)do i have to change the definition of REGISTER_BYTES. > - I do not know which value is correct for this #define (it seems that it > has to be higher, and it has something to do with how many registers do i > have in my arch, but how do i find out?) > > Thanks in advance, > Cristian Alonso Aldama > Development Group Manager > R&D Department > e-mail: calonso@teldat.es > http://www.teldat.es