From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4852 invoked by alias); 7 Aug 2002 15:17:53 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 4844 invoked from network); 7 Aug 2002 15:17:52 -0000 Received: from unknown (HELO saturn.billgatliff.com) (209.251.101.200) by sources.redhat.com with SMTP; 7 Aug 2002 15:17:52 -0000 Received: by saturn.billgatliff.com (Postfix, from userid 500) id D8D174E0004; Wed, 7 Aug 2002 10:17:51 -0500 (CDT) Date: Wed, 07 Aug 2002 08:17:00 -0000 From: "William A. Gatliff" To: Squal Cc: gdb@sources.redhat.com Subject: Re: remote debugging with m68k-stub Message-ID: <20020807101751.B5941@saturn.billgatliff.com> Reply-To: bgat@billgatliff.com References: <3D511895.F61D82A1@enssat.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D511895.F61D82A1@enssat.fr>; from pmarty@enssat.fr on Wed, Aug 07, 2002 at 02:54:45PM +0200 X-SW-Source: 2002-08/txt/msg00053.txt.bz2 Pascal: Here's a short list of things I usually screw up: * Is someone setting up the bus state controller and other critical peripherals properly before you download your program? * Does the stub put the stack pointer in a useful place for the application? Does the application need to move its stack pointer to a larger memory space durining initialization? * Is application code accidentally getting placed on the stub or application stack space? * Are you downloading the program properly? If you disassemble memory after typing 'load' at the gdb prompt, you should see your code. Immediate halts, in my case, usually signal a problem in the handoff between the stub and the application during the 'step' and 'continue' commands. Focus on those parts of your implementation. You don't need an "application" to test your stub. Just use a memory write command to write the opcode for TRAP #1 (or whatever your stub will use for the breakpoint opcode) to a known memory location, read it back to verify that it's there, set the PC to that address, and do a continue. You should get an immediate breakpoint exception. Throw in a few NOP opcodes, and you can test 'stepi' as well. Once 'continue' and 'stepi' are working, you're usually in pretty good shape. If you'd like a second stub implementation to use as a guide, see the gdbstubs project at http://sourceforge.net/projects/gdbstubs . It supports CPU32. HTH, b.g. On Wed, Aug 07, 2002 at 02:54:45PM +0200, Squal wrote: > Hello! > > I have done all the remote target gdb instructions: > - define all the low level routines > - insert set_debug_traps(); and breakpoints(); at > the beginning of the program > - compiling stub and program together > > After that, I downloaded my program and the m68k-stub in the target. > My problem is when I start the program in the remote target, the program > stop and never restart (the halt indicator is set). > Normally, the program will stop at the breakpoint (TRAP #1) and will > continue after gdb be connected to the stub but the program seems to > be stopped. > > Somebody can help me ? > > Thanks > > Pascal -- Bill Gatliff bgat@billgatliff.com