From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7610 invoked by alias); 3 Nov 2002 15:26:26 -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 7433 invoked from network); 3 Nov 2002 15:26:22 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.240.27) by sources.redhat.com with SMTP; 3 Nov 2002 15:26:22 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id A7C1F3D25; Sun, 3 Nov 2002 10:26:18 -0500 (EST) Message-ID: <3DC5401A.8070003@redhat.com> Date: Sun, 03 Nov 2002 07:26:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Kettenis Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH/RFC] Get rid of deprectated_read_register_gen in i387-tdep.c References: <200211031243.gA3ChoG7006472@elgar.kettenis.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-11/txt/msg00023.txt.bz2 > I checked in the attached patch. Unfortunately this introduces a Thanks for flushing these! > FAIL: gdb.base/default.exp: info float > > in the testsuite. The output now is: > > info float > No registers. > > Which makes sense to me since it's the truth. However, "info > registers" and "info vector" print a slightly different message: > > info registers > The program has no registers now. > > The reason is that the bit of code that prints this message: > > if (!target_has_registers) > error ("The program has no registers now."); > if (selected_frame == NULL) > error ("No selected frame."); > > isn't executed if a print_float_info method exists in the target > vector. Is there any reason not to move these statements up such that > they're executed even if a target provides the print_float_info > method? I can't think of a reason not to. -- PS: My things to do real soon includes add a function: get_selected_frame (thread_info *) if (!thread's target_has_registers) error ("..."); if (thread's selected_frame != NULL) return thread's selected_frame; // now for the fun // selected_frame = find_frame_by_id (thread's selected frame-id); // if (selected_frame != NULL) // return selected_frame; error ("No selected frame"); and then use that instead of the selected_frame global. The bit that is commented out is more interesting. It would mean differentiating between target_changed() and target_run() events. The former shouldn't change the selected frame but the latter should set it back to current frame. This will cause a behavioral change in GDB but I think it will really fix a bug. Andrew