From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10149 invoked by alias); 6 Sep 2010 09:48:36 -0000 Received: (qmail 10006 invoked by uid 22791); 6 Sep 2010 09:48:34 -0000 X-SWARE-Spam-Status: No, hits=-6.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 06 Sep 2010 09:48:26 +0000 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o869mOW1009948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 6 Sep 2010 05:48:24 -0400 Received: from host1.dyn.jankratochvil.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o869mMBk004895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Sep 2010 05:48:23 -0400 Received: from host1.dyn.jankratochvil.net (localhost [127.0.0.1]) by host1.dyn.jankratochvil.net (8.14.4/8.14.4) with ESMTP id o869mLfd022270; Mon, 6 Sep 2010 11:48:21 +0200 Received: (from jkratoch@localhost) by host1.dyn.jankratochvil.net (8.14.4/8.14.4/Submit) id o869mLik022259; Mon, 6 Sep 2010 11:48:21 +0200 Date: Mon, 06 Sep 2010 11:29:00 -0000 From: Jan Kratochvil To: Doug Evans Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [patch] Fix DW_OP_call2 and DW_OP_call4 for max-cache-age 0 Message-ID: <20100906094821.GA20484@host1.dyn.jankratochvil.net> References: <20100823185008.GA2926@host1.dyn.jankratochvil.net> <20100902160216.GA10848@host1.dyn.jankratochvil.net> <20100903153955.GA3236@host1.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-12-10) 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: 2010-09/txt/msg00150.txt.bz2 On Fri, 03 Sep 2010 17:59:16 +0200, Doug Evans wrote: > Unless code that needs a CU reads it in as necessary, and the API into > the dwarf reader only ages the cache at well defined points that no > longer need CUs (e.g. when we're done psymtab->symtab expansion). > (right?) This means only one CU is guaranteed to be read in at one time. And when you hold that CU you must not call any GDB function as this function can (upon a change in the future) request its own CU and thus invalidate CU at the caller. I find it as a too fragile policy. Still I find it even ineffective. Regular aging means CUs get flushed even if only a few of them is now read-in. > > Therefore I find prepare_execute_command as the only safe place to flush any > > CU. > > OOC, If we did move cache aging to a higher level, is there a reason > it can't be done at cleanup time? > [For reference sake, it's actually done today for free_stack_comp_unit.] The aging currently affects all CUs read-in. There can be several nested calls each requesting its own CU and doing aging at the (inner) cleanup time. That means a cleanup in the inner call may age-out CU in the outer call still before the outer cleanup. Without any CU locking in place I still do not see a safe point other than at the top level idle time (that is prepare_execute_command). Thanks, Jan