From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4920 invoked by alias); 3 Jun 2009 16:26:18 -0000 Received: (qmail 4858 invoked by uid 22791); 3 Jun 2009 16:26:14 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS 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; Wed, 03 Jun 2009 16:26:05 +0000 Received: (qmail 18602 invoked from network); 3 Jun 2009 16:26:00 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 3 Jun 2009 16:26:00 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [RFC,v2] Yank out target_ops->to_sections Date: Wed, 03 Jun 2009 16:26:00 -0000 User-Agent: KMail/1.9.10 Cc: "Ulrich Weigand" References: <200906021105.n52B5hvH002367@d12av02.megacenter.de.ibm.com> In-Reply-To: <200906021105.n52B5hvH002367@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200906031726.38327.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: 2009-06/txt/msg00039.txt.bz2 On Tuesday 02 June 2009 12:05:43, Ulrich Weigand wrote: > > There still needs to be a global somewhere, there's no way around it, > > but, it will be the "current_symbol_space", not the target sections. > > This global is then switched whenever we need to switch context > > --- switch thread, insert breakpoints, or by user command, to e.g., > > prepare to start a new inferior --- in a sense, this structure holds > > the globals that currently form a "prototype" for an inferior. >=20 > This is the one part I'm not sure I agree with. =A0I would have hoped > we could actually get *rid* of all those globals, at least as far > as the GDB core is concerned. =A0(There may be globals in the UI code > where it makes sense, to represent conceptually global settings at > the the UI level like the notion of the "selected frame". =A0But all > of GDB's core should IMO be fully parameterized and not rely on > globals. =A0 > I'd expect this could be achieved by passing "inferior"=20 > or "thread" arguments to some of the central functions ...) I don't think anyone disagrees with that. With my proposal, there will be ways to get from a frame/thread/inferior/whatever to the corresponding address/symbol space, and where possible we'll use those. However, consider the case where you have more than one program loaded (say, /bin/cat and /bin/echo), and haven't started execution in either of those yet. There is no "inferior" or "thread" object yet for any of them, and you can't distinguish with inferior_ptid=20 either (it's null_ptid in both cases). Currently, all this state is spread around in globals all over (e.g., even exec_bfd can be accessed in the most twisted code paths). But, it's the "prepare to start a new inferior" part that ends up requiring the global. I'm proposing to aggregate them somewhere, but we still need to have a global storing a pointer to the "current context" somewhere. I agree that ideally then this global should only be accessed at high layers, close to the UI, and that we should only need to pass to each major component what it really needs and handles, as arguments. But, that really *has* to be a long term goal. Just getting rid of a single one of those globals (by passing them in arguments) is a *lot* of hair for practically 0 gain at this point. Since we do have to aggregate and store these globals somewhere, I think that I'm taking a good first step. IMO, it's much better to just switch a pointer than to come up with the old "infrun.c|thread.c:context_switch" mess. We can then *incrementally* clean up interfaces, as we'll then have a clearly visible goal to achieve. Anyway, things will surely get clearer a bit further down the line when I post the main juicy bits for discussion. --=20 Pedro Alves