From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21345 invoked by alias); 29 Sep 2014 23:16:02 -0000 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 Received: (qmail 21329 invoked by uid 89); 29 Sep 2014 23:16:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-vc0-f172.google.com Received: from mail-vc0-f172.google.com (HELO mail-vc0-f172.google.com) (209.85.220.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 29 Sep 2014 23:16:00 +0000 Received: by mail-vc0-f172.google.com with SMTP id lf12so2278396vcb.17 for ; Mon, 29 Sep 2014 16:15:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=me7jpXbTU//FeoZy8tkbs9uxA4bkCWJ5gL90ocL360U=; b=lF/+x5GsraWwBdPdWJtx9nFm7r7nrG/1PgaaIU2R4zSGPL6mIzJa8JfGttdXo8uXx3 uhM7mRXmE/wy7YZFaGw6fLWiaRS4R18410Pgm8U4GvPTYbhDyrUFcvc0TcUIG55hTjTM j+OSQ8DevN0J2g1ov3ROJztfySWhtmjXzYjmk9sPqEkVzxx61+XqjoMVXIMYh6ltyvSd 6w3haxtxtWEZXnQA8zS7XwmHDn2HHD/v7eBKzMCzOkUqiOCSL144r3qVLnZfquRf906N 9XYfjd5zXjhkvZusC5d7PvoI84UAHbE52WnH14LN0eBQeNEdUwPfx5vcuJ3n6W7UgaHC tJNg== X-Gm-Message-State: ALoCoQl2zjv8dMionGAYOEBijf2sqbjaI+Wa+wt8Hpab5PURprgznsVCSMAtbgmietWm/FB0NCEQ MIME-Version: 1.0 X-Received: by 10.221.26.70 with SMTP id rl6mr31362823vcb.0.1412032557748; Mon, 29 Sep 2014 16:15:57 -0700 (PDT) Received: by 10.52.181.65 with HTTP; Mon, 29 Sep 2014 16:15:57 -0700 (PDT) In-Reply-To: <54299B61.7030107@ericsson.com> References: <1411593539-6507-1-git-send-email-simon.marchi@ericsson.com> <54242FBD.7030408@ericsson.com> <54299B61.7030107@ericsson.com> Date: Mon, 29 Sep 2014 23:16:00 -0000 Message-ID: Subject: Re: [PATCH] Add call to prune_program_spaces in mi_cmd_remove_inferior From: Doug Evans To: Simon Marchi Cc: gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00861.txt.bz2 On Mon, Sep 29, 2014 at 10:48 AM, Simon Marchi wrote: > [...] > If we tie the creation/deletion of program spaces with the creation/deletion of > inferiors, could we go further and tie the concept of current program space and > current inferior? I see very often a set_current_inferior (inf) followed by a > set_current_program_space (inf->pspace). I don't really know when we would want > a current program space that is not the program space of our current inferior. This would be nice alright. There are special cases, which we can handle in whatever way works, but IWBN if this was the normal way of maintaining such state - anytime we can remove unnecessary global state "works for me". > From what I can see, the only times set_current_program_space is called alone > is in constructs like this: > > old_chain = save_current_program_space (); > ALL_PSPACES (ss) > { > set_current_program_space (ss); > clear_section_table (current_target_sections); > exec_close (); > } > do_cleanups (old_chain); > > where exec_close accesses the global "current_program_space". So in reality, > it is passing a parameter indirectly using a global variable. I suppose we should > rather see: > > ALL_PSPACES (ss) > { > clear_section_table (current_target_sections); current_target_sections is actually a member of the current_program_space, so this could be improved even more (gotta love macros ...). > exec_close (ss); > } > > I realize that there is a lot of such indirect parameter passing in gdb. It > wouldn't be easy do to such a change, but I think it would help in many regards. Agreed! I think it's a longterm todo on everyone's list.