From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30810 invoked by alias); 8 Oct 2003 14:05:46 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 30768 invoked from network); 8 Oct 2003 14:05:44 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 8 Oct 2003 14:05:44 -0000 Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian)) id 1A7Ewh-0007Gg-4E; Wed, 08 Oct 2003 10:05:43 -0400 Date: Wed, 08 Oct 2003 14:05:00 -0000 From: Daniel Jacobowitz To: Atsushi Nemoto Cc: gdb-patches@sources.redhat.com Subject: Re: "No registers" error on connecting to MIPS LSI PMON target Message-ID: <20031008140542.GA27876@nevyn.them.org> Mail-Followup-To: Atsushi Nemoto , gdb-patches@sources.redhat.com References: <20031008.194759.74756454.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031008.194759.74756454.nemoto@toshiba-tops.co.jp> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-10/txt/msg00207.txt.bz2 On Wed, Oct 08, 2003 at 07:47:59PM +0900, Atsushi Nemoto wrote: > I tried to use gdb-6.0 for remote-debugging with MIPS LSI PMON. > I got a message "No registers." on "target lsi /dev/ttyS0" command. > > I think this is because get_selected_frame() is called BEFORE the > correct target_ops is installed by push_target(). > > This is a temporary patch. It seems to work, but I can not tell the > situation mentioned in the "FIXME" comment is really solved or not. > > > --- gdb-6.0/gdb/remote-mips.c.org Wed Jun 11 22:16:28 2003 > +++ gdb-6.0/gdb/remote-mips.c Wed Oct 8 16:55:19 2003 > @@ -1494,10 +1494,12 @@ > the request itself succeeds or fails. */ > > mips_request ('r', 0, 0, &err, mips_receive_wait, NULL); > +#if 0 > /* FIXME: cagney/2002-11-29: Force the update of selected frame. > This shouldn't be necessary, only many many places still refer to > selected_frame directly (instead of using get_selected_frame(). */ > get_selected_frame (); /* Hack!!! */ > +#endif > } > > /* Open a connection to the remote board. */ Hmm, I've got one of these too and see the same error. This looks to predate the deprecation of selected_frame, so I think it can probably go away now. Andrew would have a better idea... -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer