This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] Fix Cygwin problem with banned variables
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Pierre Muller <pierre dot muller at ics-cnrs dot unistra dot fr>
- Cc: brobecke at sourceware dot org, gdb-patches at sourceware dot org, 'Pedro Alves' <pedro at codesourcery dot com>
- Date: Mon, 21 Jun 2010 10:07:43 -0700
- Subject: Re: [RFA] Fix Cygwin problem with banned variables
- References: <20100517171128.29087.qmail@sourceware.org> <001201cb0f8b$472f8b00$d58ea100$@muller@ics-cnrs.unistra.fr> <003c01cb1089$208e45f0$61aad1d0$@muller@ics-cnrs.unistra.fr>
> This generates multiple calls to 'trace variable ' and only one call
> to 'trace remove variable '.
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.
> 2010-06-19 Pierre Muller <muller@ics.u-strasbg.fr>
>
> * 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 '.
Just one detail, but otherwise OK.
> @@ -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
Please add a comment explaining what this global is used for and
why it is necessary.
Thanks,
--
Joel