public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: GDB Patches <gdb-patches@sourceware.org>
Subject: Re: Remove all "strace" calls from the testsuite.
Date: Thu, 12 Jan 2012 16:40:00 -0000	[thread overview]
Message-ID: <4F0F0965.6050600@redhat.com> (raw)
In-Reply-To: <20120112144002.GP31383@adacore.com>

On 01/12/2012 02:40 PM, Joel Brobecker wrote:
>> Anyone know of any reason not to apply this?
> 
> Not from me, but you already knew that...

:-)  I'll wait a little longer in case someone knows of a use we're
missing.

> 
>> gdb/testsuite/
>> 2012-01-12  Pedro Alves  <palves@redhat.com>
>>
>> 	Remove all calls to strace.
> 
> The reason why I am replying is because I was wondering if you could
> also put strace in the banned_variable list in gdb.exp? That way,
> we're certain that it won't come back unnoticed.

The below seems to work well.

> Thanks for doing this...

You're most welcome.

gdb/testsuite/
2012-01-12  Pedro Alves  <palves@redhat.com>

	* lib/gdb.exp (banned_procedures): New variable.
	(banned_variables_traced): Rename to ...
	(banned_traced): ... this.
	(gdb_init): Also trace banned procedures.
	(gdb_finish): Also untrace banned procedures.

---

 gdb/testsuite/lib/gdb.exp |   34 +++++++++++++++++++++++++---------
 1 files changed, 25 insertions(+), 9 deletions(-)

diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index 4a59944..00fe71c 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -2983,14 +2983,19 @@ if ![info exists gdb_test_timeout] {
 # an error when that happens.
 set banned_variables { bug_id prms_id }

+# A list of procedures that GDB testcases should not use.
+# We try to prevent their use by monitoring invocations and raising
+# an error when that happens.
+set banned_procedures { strace }
+
 # 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
+# if the banned variables and procedures are already traced.
+set banned_traced 0

 proc gdb_init { args } {
     # Reset the timeout value to the default.  This way, any testcase
@@ -3000,15 +3005,21 @@ proc gdb_init { args } {
     global timeout
     set timeout $gdb_test_timeout

-    # Block writes to all banned variables...
+    # Block writes to all banned variables, and invocation of all
+    # banned procedures...
     global banned_variables
-    global banned_variables_traced
-    if (!$banned_variables_traced) {
+    global banned_procedures
+    global banned_traced
+    if (!$banned_traced) {
     	foreach banned_var $banned_variables {
             global "$banned_var"
             trace add variable "$banned_var" write error
 	}
-	set banned_variables_traced 1
+	foreach banned_proc $banned_procedures {
+	    global "$banned_proc"
+	    trace add execution "$banned_proc" enter error
+	}
+	set banned_traced 1
     }

     # We set LC_ALL, LC_CTYPE, and LANG to C so that we get the same
@@ -3057,13 +3068,18 @@ proc gdb_finish { } {
     # Unblock write access to the banned variables.  Dejagnu typically
     # resets some of them between testcases.
     global banned_variables
-    global banned_variables_traced
-    if ($banned_variables_traced) {
+    global banned_procedures
+    global banned_traced
+    if ($banned_traced) {
     	foreach banned_var $banned_variables {
             global "$banned_var"
             trace remove variable "$banned_var" write error
 	}
-	set banned_variables_traced 0
+	foreach banned_proc $banned_procedures {
+	    global "$banned_proc"
+	    trace remove execution "$banned_proc" enter error
+	}
+	set banned_traced 0
     }
 }

  reply	other threads:[~2012-01-12 16:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-12 14:40 Pedro Alves
2012-01-12 15:25 ` Joel Brobecker
2012-01-12 16:40   ` Pedro Alves [this message]
2012-01-13  3:46     ` Joel Brobecker
2012-01-16 19:29       ` Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F0F0965.6050600@redhat.com \
    --to=palves@redhat.com \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).