From: "J. Johnston" <jjohnstn@redhat.com>
To: gdb-patches@sources.redhat.com
Subject: RFA: nptl threading support for schedlock.exp
Date: Wed, 23 Apr 2003 19:53:00 -0000 [thread overview]
Message-ID: <3EA6E7F2.7090301@redhat.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 707 bytes --]
The following changes schedlock.exp for running with nptl threads.
Under the nptl model, a very small time slice is not divided up equally
as it was in the past with linuxthreads.
The test case is also changed to ensure that one of the child threads
is used to test schedule locking instead of the main thread. In early
testing with nptl, a kernel problem was identified when the main thread
was locked and an interrupt signal was sent.
Ok to commit?
-- Jeff J.
2003-04-23 Jeff Johnston <jjohnstn@redhat.com>
* gdb.threads/schedlock.exp: Remove assumption that all threads will run in a
particular small time slice. Also ensure we break in one of the child threads
rather than the main thread.
[-- Attachment #2: schedlock.nptl.patch --]
[-- Type: text/plain, Size: 1499 bytes --]
Index: schedlock.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.threads/schedlock.exp,v
retrieving revision 1.3
diff -u -r1.3 schedlock.exp
--- schedlock.exp 4 Jan 2003 23:05:05 -0000 1.3
+++ schedlock.exp 23 Apr 2003 18:31:05 -0000
@@ -112,8 +112,8 @@
stop_process "stop all threads ($msg)"
- # Make sure we're in one of the looping threads.
- gdb_breakpoint [gdb_get_line_number "schedlock.exp: main loop"]
+ # Make sure we're in one of the non-main looping threads.
+ gdb_breakpoint [concat [gdb_get_line_number "schedlock.exp: main loop"] " if arg != 5"]
gdb_continue_to_breakpoint "return to loop ($msg)"
delete_breakpoints
}
@@ -230,12 +230,11 @@
set start_args $cont_args
set cont_args [get_args]
+set num_other_threads 0
for {set i 0} {[expr $i < 6]} {set i [expr $i + 1]} {
if {[lindex $start_args $i] == [lindex $cont_args $i]} {
if {$i == $curthread} {
fail "current thread stepped (didn't run)"
- } else {
- fail "other thread $i ran (didn't run) (1)"
}
} else {
if {$i == $curthread} {
@@ -245,9 +244,14 @@
fail "current thread stepped (wrong amount)"
}
} else {
- pass "other thread $i ran (1)"
+ set num_other_threads [expr $num_other_threads + 1]
}
}
+}
+if {$num_other_threads > 0} {
+ pass "other threads ran (1)"
+} else {
+ fail "other threads ran (no other threads ran) (1)"
}
# Test continue with scheduler locking
next reply other threads:[~2003-04-23 19:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-23 19:53 J. Johnston [this message]
2003-05-07 21:06 ` Elena Zannoni
2003-05-07 21:19 ` Daniel Jacobowitz
2003-05-08 19:23 ` J. Johnston
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=3EA6E7F2.7090301@redhat.com \
--to=jjohnstn@redhat.com \
--cc=gdb-patches@sources.redhat.com \
/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