From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30508 invoked by alias); 12 Aug 2008 14:51:08 -0000 Received: (qmail 30498 invoked by uid 22791); 12 Aug 2008 14:51:06 -0000 X-Spam-Check-By: sourceware.org Received: from mail.oarcorp.com (HELO OARmail.OARCORP.com) (216.186.189.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 12 Aug 2008 14:50:29 +0000 Received: from [192.168.1.3] (192.168.1.3) by OARmail.OARCORP.com (192.168.2.2) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 12 Aug 2008 09:49:02 -0500 Message-ID: <48A0F96E.7000701@oarcorp.com> Date: Tue, 12 Aug 2008 19:23:00 -0000 From: Joel Sherrill User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: , kang shuo Subject: m68k gdb issue with skyeye Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2008-08/txt/msg00163.txt.bz2 Hi, Michael Kang and I have run into something with m68k gdb and don't know how to fix it. The executable is for a coldfire mc5272. With m68k-rtems* (basically m68k-elf) on gdb 6.8, connecting to the Skyeye gdbserver gives this. (gdb) tar remote :12345 Remote debugging using :12345 Remote 'g' packet reply is too long: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 Michael tried gdb 6.8 targeting m68k-linux and it connects OK. I tried gdb 6.6 m68k-rtems and it connects and appears to work OK. It looks like the way the maximum packet size is calculated has changed since 6.6 and is dependent on number of registers. Does anyone see what the subtle difference is that is breaking it for m68k-rtems? -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherrill@OARcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985