From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15423 invoked by alias); 7 Dec 2008 00:16:08 -0000 Received: (qmail 15415 invoked by uid 22791); 7 Dec 2008 00:16:07 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate3.de.ibm.com (HELO mtagate3.de.ibm.com) (195.212.29.152) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 07 Dec 2008 00:15:24 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.8/8.13.8) with ESMTP id mB70FMlN116228 for ; Sun, 7 Dec 2008 00:15:22 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mB70FLIZ3797086 for ; Sun, 7 Dec 2008 01:15:21 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mB70FLE5017786 for ; Sun, 7 Dec 2008 01:15:21 +0100 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id mB70FKfE017783; Sun, 7 Dec 2008 01:15:20 +0100 Message-Id: <200812070015.mB70FKfE017783@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Sun, 7 Dec 2008 01:15:20 +0100 Subject: [rfc] [0/7] infrun cleanup To: pedro@codesourcery.com (Pedro Alves) Date: Sun, 07 Dec 2008 00:16:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, drow@false.org In-Reply-To: <200811172102.56650.pedro@codesourcery.com> from "Pedro Alves" at Nov 17, 2008 09:02:56 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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/msg00118.txt.bz2 Pedro Alves wote: > On Monday 17 November 2008 20:30:05, Ulrich Weigand wrote: > > In fact other members of the ecs struct should probably be > > local variables, maybe some of them passed explicitly to > > subroutines. I think this would help simplify understanding > > the data-flow along handle_inferior_event and its subroutines ... > > Agreed, probably, maybe. I few months ago I started doing something like > that and got rid of ecs completely, but then I looked at the result and > noticed that cutting handle_inferior_event into smaller pieces first > (or at the same time) would probably have had better immediate clarity > gains, but I didn't try it. That colides a bit (and possibly goes in the > opposite direction) with just plain getting rid of ecs, as by doing the > latter, you find yourself adjusting callers of callers to pass new flags > around (as opposed to having everything related to an event handy in a > single struct). That's a > similar argument to the recent struct > value_print_options or replacing > current_language with passing a > struct around or similars. > > Anyway, I don't have that much strong feelings in either direction, just > telling the world my (possibly bogus) war story. Patches do speak > much louder than words. :-) OK, here's a couple of patches :-) These will completely eliminate struct execution_control_state, while at the same time making the overall flow of control though handle_inferior_event clearer, IMO. I'd appreciate any feedback on this approach (in particular if you've done things differently in your attempt) ... Overall patch set tested on amd64-linux with no regressions. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com