From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6165 invoked by alias); 22 Jun 2010 07:22:30 -0000 Received: (qmail 6138 invoked by uid 22791); 22 Jun 2010 07:22:27 -0000 X-SWARE-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,BAYES_05,MSGID_MULTIPLE_AT,RCVD_IN_JMF_BL X-Spam-Check-By: sourceware.org Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.200.152) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 22 Jun 2010 07:22:22 +0000 Received: from baal.u-strasbg.fr (baal.u-strasbg.fr [IPv6:2001:660:2402::41]) by mailhost.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id o5M7LsF8004420 ; Tue, 22 Jun 2010 09:21:54 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from mailserver.u-strasbg.fr (ms7.u-strasbg.fr [IPv6:2001:660:2402:d::16]) by baal.u-strasbg.fr (8.14.0/jtpda-5.5pre1) with ESMTP id o5M7LrDG037578 ; Tue, 22 Jun 2010 09:21:53 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from d620muller (gw-ics.u-strasbg.fr [130.79.210.225]) (user=mullerp mech=LOGIN) by mailserver.u-strasbg.fr (8.14.4/jtpda-5.5pre1) with ESMTP id o5M7LqNF084007 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Tue, 22 Jun 2010 09:21:53 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) From: "Pierre Muller" To: "'Joel Brobecker'" Cc: , "'Pedro Alves'" References: <20100517171128.29087.qmail@sourceware.org> <001201cb0f8b$472f8b00$d58ea100$@muller@ics-cnrs.unistra.fr> <003c01cb1089$208e45f0$61aad1d0$@muller@ics-cnrs.unistra.fr> <20100621170743.GD2595@adacore.com> In-Reply-To: <20100621170743.GD2595@adacore.com> Subject: RE: [RFA] Fix Cygwin problem with banned variables Date: Tue, 22 Jun 2010 07:22:00 -0000 Message-ID: <001801cb11db$9d553c30$d7ffb490$@muller@ics-cnrs.unistra.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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-06/txt/msg00471.txt.bz2 > -----Message d'origine----- > De=A0: gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Joel Brobecker > Envoy=E9=A0: Monday, June 21, 2010 7:08 PM > =C0=A0: Pierre Muller > Cc=A0: brobecke@sourceware.org; gdb-patches@sourceware.org; 'Pedro Alves' > Objet=A0: Re: [RFA] Fix Cygwin problem with banned variables >=20 > > This generates multiple calls to 'trace variable ' and only one > call > > to 'trace remove variable '. >=20 > The TCL documentation is not directly explicit about that, but > some experimentation shows that this is indeed a problem. And > rereading the docuemntation with that in mind, the duplicate traces > are probably treated as distinct traces. Thus, when doing only one > remove for the trace, we're still left with at least one trace. >=20 > > 2010-06-19 Pierre Muller > > > > * lib/gdb.exp (banned_variables_traced): New global variable. > > (gdb_init, gdb_finish): Use new variable to avoid multiple > > tracing. > > (gdb_init): Use `trace add variable ' instead of obsolete > > `trace variable '. >=20 > Just one detail, but otherwise OK. Thanks for the approval =20 > > @@ -2519,6 +2519,7 @@ if ![info exists gdb_test_timeout] { > > # We try to prevent their use by monitoring write accesses and > raising > > # an error when that happens. > > set banned_variables { bug_id prms_id } > > +set banned_variables_traced 0 >=20 > Please add a comment explaining what this global is used for and > why it is necessary. Here is what I checked in, with an explanation added for the new variable `banned_variables_traced'. Please feel free to improve the comment, Pierre Muller testsuite/ChangLog entry: 2010-06-22 Pierre Muller * lib/gdb.exp (banned_variables_traced): New global variable. (gdb_init, gdb_finish): Use new variable to avoid multiple tracing. (gdb_init): Use `trace add variable' instead of obsolete `trace variable'. Index: lib/gdb.exp =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/src/src/gdb/testsuite/lib/gdb.exp,v retrieving revision 1.150 diff -u -p -r1.150 gdb.exp --- lib/gdb.exp 11 Jun 2010 21:58:20 -0000 1.150 +++ lib/gdb.exp 22 Jun 2010 07:16:58 -0000 @@ -2520,6 +2520,15 @@ if ![info exists gdb_test_timeout] { # an error when that happens. set banned_variables { bug_id prms_id } +# gdb_init is called by runtest at start, but also by several +# tests directly; gdb_finish is only called from within runtest after +# each test source execution. +# Placing several traces by repetitive calls to gdb_init leads +# to problems, as only one trace is removed in gdb_finish. +# To overcome this possible problem, we add a variable that records +# if the banned variables are traced. +set banned_variables_traced 0 + proc gdb_init { args } { # Reset the timeout value to the default. This way, any testcase # that changes the timeout value without resetting it cannot affect @@ -2530,9 +2539,13 @@ proc gdb_init { args } { # Block writes to all banned variables... global banned_variables - foreach banned_var $banned_variables { - global "$banned_var" - trace variable "$banned_var" w error + global banned_variables_traced + if (!$banned_variables_traced) { + foreach banned_var $banned_variables { + global "$banned_var" + trace add variable "$banned_var" write error + } + set banned_variables_traced 1 } return [eval default_gdb_init $args]; @@ -2552,9 +2565,13 @@ proc gdb_finish { } { # Unblock write access to the banned variables. Dejagnu typically # resets some of them between testcases. global banned_variables - foreach banned_var $banned_variables { - global "$banned_var" - trace remove variable "$banned_var" write error + global banned_variables_traced + if ($banned_variables_traced) { + foreach banned_var $banned_variables { + global "$banned_var" + trace remove variable "$banned_var" write error + } + set banned_variables_traced 0 } }