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
}
}
next prev parent 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).