From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1780 invoked by alias); 7 Dec 2008 19:16:16 -0000 Received: (qmail 1770 invoked by uid 22791); 7 Dec 2008 19:16:16 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 07 Dec 2008 19:15:41 +0000 Received: (qmail 12226 invoked from network); 7 Dec 2008 19:15:38 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 7 Dec 2008 19:15:38 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [rfc] [0/7] infrun cleanup Date: Sun, 07 Dec 2008 19:16:00 -0000 User-Agent: KMail/1.9.10 Cc: "Ulrich Weigand" , drow@false.org References: <200812071819.mB7IJnUh004717@d12av02.megacenter.de.ibm.com> In-Reply-To: <200812071819.mB7IJnUh004717@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812071915.46858.pedro@codesourcery.com> 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: 2008-12/txt/msg00136.txt.bz2 On Sunday 07 December 2008 18:19:49, Ulrich Weigand wrote: > In the context of some further cleanup and splitting handle_inferior_event > into multiple more independent parts, I had been wondering whether it > might be a good idea to use a enum (like enum inferior_stop_reason) > instead of the boolean: handle_inferior_event (and its hypothetical > subroutines) would return enum values to indicate *why* the inferior > stopped, including a new STILL_RUNNING value to indicate that it > in fact hasn't yet stopped. > > In this set-up you'd have statements like > > return STILL_RUNNING; 'return WAIT_SOME_MORE;' would be historically more appropriate. :-) > > or > > return END_STEPPING_RANGE; > > or (another potential new value) > > return HIT_BREAKPOINT; > > within handle_inferior_event; and its caller would be rewritten like > > do > { > ptid = target_wait (...); > stop_reason = handle_inferior_event (ptid, ...); > } > while (stop_reason == STILL_RUNNING); > > It might be feasible to use the stop_reason in the future to merge > some of the print_stop_reason stuff into normal_stop and reduce the > amount of duplicate checks; or even to replace some of the "global" > output variables like stopped_by_random_signal or tp->stop_step. Sounds good to me. > I thought I had updated that one? Oh, you did. I missed it, sorry. > > > /* Refresh prev_pc value just prior to resuming. This used to be > > done in stop_stepping, however, setting prev_pc there did not handle > > scenarios such as inferior function calls or returning from > > a function via the return command. In those cases, the prev_pc > > ... > > I left that because it specifically refers to how things were done > in the past, when we still had that function ... Maybe it could be > marked as "the former stop_stepping" or so. Well, that whole comment becomes mostly useless after these cleanups. It refers to stop_stepping, ecs, init_execution_control_state, all things that are gone, which seems to leave more confusion than clarify things. I wonder if we should just remove most of it, and just comment why we set prev_pc there... -- Pedro Alves