From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13263 invoked by alias); 20 Mar 2007 00:39:12 -0000 Received: (qmail 13251 invoked by uid 22791); 20 Mar 2007 00:39:11 -0000 X-Spam-Check-By: sourceware.org Received: from elrond.portugalmail.pt (HELO elrond.portugalmail.pt) (195.245.179.181) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 20 Mar 2007 00:39:08 +0000 Received: from localhost (localhost [127.0.0.1]) by elrond.portugalmail.pt (Postfix) with ESMTP id CCF8C3CB51 for ; Tue, 20 Mar 2007 00:33:30 +0000 (WET) Received: from elrond.portugalmail.pt ([127.0.0.1]) by localhost (elrond.portugalmail.pt [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxtZV8OyEzVd for ; Tue, 20 Mar 2007 00:33:30 +0000 (WET) Received: from [127.0.0.1] (88.210.72.155.rev.optimus.pt [88.210.72.155]) (Authenticated sender: pedro_alves@portugalmail.pt) by elrond.portugalmail.pt (Postfix) with ESMTP id E16023C948 for ; Tue, 20 Mar 2007 00:33:25 +0000 (WET) Message-ID: <45FF2D16.6030501@portugalmail.pt> Date: Tue, 20 Mar 2007 00:39:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.8.0.10) Gecko/20070221 Thunderbird/1.5.0.10 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: Re: TUI + gdbserver broken? References: <45FDECB3.5000002@portugalmail.pt> <20070319021145.GA25872@caradoc.them.org> <45FEF7B0.9070209@portugalmail.pt> <20070319221430.GA24326@caradoc.them.org> <45FF1571.2080401@portugalmail.pt> <20070319234141.GA29137@caradoc.them.org> In-Reply-To: <20070319234141.GA29137@caradoc.them.org> Content-Type: multipart/mixed; boundary="------------030205050102030302040608" X-Antivirus: avast! (VPS 000725-1, 19-03-2007), Outbound message X-Antivirus-Status: Clean X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-03/txt/msg00176.txt.bz2 This is a multi-part message in MIME format. --------------030205050102030302040608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1382 Daniel Jacobowitz escreveu: > On Mon, Mar 19, 2007 at 10:57:53PM +0000, Pedro Alves wrote: > >> That has exactly the same effect as it was before the your select frame >> changes. >> That is, only try to get the selected frame when there is one. Maybe there >> should >> still be a function like this in frame.c ? >> > > >> struct frame_info * >> deprecated_get_selected_frame () >> { >> return selected_frame; >> } >> > > Neither this, or your (level >= 0), worked - they both make tui enter some kind of loop, that I can't get a trace. Perhaps in some other host it would be easier (I'm on Cygwin). Bummer. >> (or perhaps call it get_selected_frame_if_any) >> > > The problem is that when we reinitialize the frame cache, the selected > frame is indeterminate - the selected_frame global may randomly be > initialized or NULL depending on what else has been called since we > last did reinit_frame_cache. > Maybe that has something to do with the hangs I see. How about the attached? Move the selected_frame creation logic to select_frame. It fixes both the remote debugging problem, and the repainting problems - probably caused by the get_selected_frame calling select_frame generating extra spurious events. It would need a testsuite run and a bit of cleanup, since the get_selected_frame would lose the parameter. Cheers, Pedro Alves --------------030205050102030302040608 Content-Type: text/plain; name="tui_frame3.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="tui_frame3.diff" Content-length: 1911 gdb/ChangeLog * frame.c (get_selected_frame): Move selected frame to current frame mapping to ... (select_frame): ... here. --- gdb/frame.c | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) Index: src/gdb/frame.c =================================================================== --- src.orig/gdb/frame.c 2007-03-18 23:22:10.000000000 +0000 +++ src/gdb/frame.c 2007-03-20 00:29:42.000000000 +0000 @@ -953,19 +953,6 @@ static struct frame_info *selected_frame struct frame_info * get_selected_frame (const char *message) { - if (selected_frame == NULL) - { - if (message != NULL && (!target_has_registers - || !target_has_stack - || !target_has_memory)) - error (("%s"), message); - /* Hey! Don't trust this. It should really be re-finding the - last selected frame of the currently selected thread. This, - though, is better than nothing. */ - select_frame (get_current_frame ()); - } - /* There is always a frame. */ - gdb_assert (selected_frame != NULL); return selected_frame; } @@ -994,6 +981,21 @@ select_frame (struct frame_info *fi) if (deprecated_selected_frame_level_changed_hook) deprecated_selected_frame_level_changed_hook (frame_relative_level (fi)); + if (fi == NULL) + { + if (!target_has_registers + || !target_has_stack + || !target_has_memory) + return; + + /* Hey! Don't trust this. It should really be re-finding the + last selected frame of the currently selected thread. This, + though, is better than nothing. */ + selected_frame = get_current_frame (); + } + /* There is always a frame. */ + gdb_assert (selected_frame != NULL); + /* FIXME: kseitz/2002-08-28: It would be nice to call selected_frame_level_changed_event() right here, but due to limitations in the current interfaces, we would end up flooding UIs with events --------------030205050102030302040608--