From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 102825 invoked by alias); 10 Apr 2015 18:08:51 -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 102766 invoked by uid 89); 10 Apr 2015 18:08:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-ob0-f174.google.com Received: from mail-ob0-f174.google.com (HELO mail-ob0-f174.google.com) (209.85.214.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 10 Apr 2015 18:08:48 +0000 Received: by obbeb7 with SMTP id eb7so26643377obb.3 for ; Fri, 10 Apr 2015 11:08:46 -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=b1a9hCq5XVuqAabHm/NHWZfQfocX1x4kCltrWnULFMw=; b=Nrln5e1J32XVqIccHJPcCC/elGoyvHHPMyFeviR5UlzpvChogWfSo1CkQbYfjAvGt8 NWAnHYNE5Vv+AhHH/J4GiYpaLSZT3L78uJX9oL2FqGoXemDtkmiiueSdPR69OUFzwjC+ rTse594igcW+4OeGWTqliaCn6TBm0On0ZNRQOMzdBXP6XSeStodd1uk4S4DClegFamch ZwAw+QZCwMRzhRLhcW05h2z7zi4VsJWj/J4e3HZ3bweoy9cvBBVmXQqkySvZXl7AofQv a2rbZ9joqdKkoOOFCDDQ3d1KpcGNPvB0UDhdpxFmIYCdT5Zzot/qctT+tHp0PDb2VUJp USwg== X-Gm-Message-State: ALoCoQkgJ0htxKJZZ/kfHdBWMKH5aY5wNwYrSp7Lg/4ZnX/cMU795EPcyTxSyIpTealIzXa4jd5a MIME-Version: 1.0 X-Received: by 10.182.105.66 with SMTP id gk2mr3536679obb.76.1428689326541; Fri, 10 Apr 2015 11:08:46 -0700 (PDT) Received: by 10.182.103.101 with HTTP; Fri, 10 Apr 2015 11:08:46 -0700 (PDT) In-Reply-To: <55280E9A.1020204@redhat.com> References: <1428666671-12926-1-git-send-email-qiyaoltc@gmail.com> <55280E9A.1020204@redhat.com> Date: Fri, 10 Apr 2015 18:08:00 -0000 Message-ID: Subject: Re: [RFC] Unset tcl variable addr to avoid clashing From: Doug Evans To: Keith Seitz Cc: Yao Qi , gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg00405.txt.bz2 On Fri, Apr 10, 2015 at 10:55 AM, Keith Seitz wrote: > On 04/10/2015 09:53 AM, Doug Evans wrote: >> >> Bleah. :-) >> The first thing that comes to mind is of course a convention that >> array globals must be prefixed with the name of the test. >> OTOH gdb_base_coredump_filter_addr is painful. > > > I've had to do this in several places, too, with my big locations patchset. > > In the end, I felt the path-of-least-resistance was to encapsulate the whole > test in its own namespace and then declare variables: > > namespace eval $testfile { > variable addr > variable linespec > variable location > > # do all test stuff > } > > namespace delete $testfile > > This is rather inconvenient, so I played for a short while with trying to > automate this in some way. The only solution that I could devise that didn't > involve modifying dejagnu was to track the global variable list in > standard_testfile or prepare_for_testing, unset'ing "new" globals every time > the procedure was called. Tucking the thing away in a namespace works too. [for a definition of "works" that recognizes we have to be pragmatic here :-)]