2007-12-17 13:32:23 +01:00
|
|
|
# This testcase is part of GDB, the GNU debugger.
|
|
|
|
|
2016-01-01 05:33:14 +01:00
|
|
|
# Copyright 2007-2016 Free Software Foundation, Inc.
|
2007-12-17 13:32:23 +01:00
|
|
|
|
|
|
|
# This program is free software; you can redistribute it and/or modify
|
|
|
|
# it under the terms of the GNU General Public License as published by
|
|
|
|
# the Free Software Foundation; either version 3 of the License, or
|
|
|
|
# (at your option) any later version.
|
|
|
|
#
|
|
|
|
# This program is distributed in the hope that it will be useful,
|
|
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
# GNU General Public License for more details.
|
|
|
|
#
|
|
|
|
# You should have received a copy of the GNU General Public License
|
|
|
|
# along with this program. If not, see <http://www.gnu.org/licenses/>. */
|
|
|
|
|
|
|
|
# watch-thread_num.exp Test thread <thread_num> parameter for
|
|
|
|
# watch commands.
|
|
|
|
#
|
|
|
|
|
2010-10-19 23:29:23 +02:00
|
|
|
# This test verifies that a watchpoint is detected in the proper thread
|
|
|
|
# so the test is only meaningful on a system with hardware watchpoints.
|
2015-05-08 12:50:47 +02:00
|
|
|
# More specifically, the implementation of this test uses access
|
|
|
|
# watchpoints, so skip it when those are not available.
|
|
|
|
if {[skip_hw_watchpoint_access_tests]} {
|
2011-02-21 15:57:38 +01:00
|
|
|
return 0
|
2010-10-19 23:29:23 +02:00
|
|
|
}
|
|
|
|
|
test suite update - gdb.base/[t-z]
Convert files gdb.base/[t-z]*.exp to use standard_output_file et al.
* gdb.base/testenv.exp, gdb.base/tui-layout.exp,
gdb.base/twice.exp, gdb.base/type-opaque.exp, gdb.base/unload.exp,
gdb.base/unwindonsignal.exp, gdb.base/valgrind-db-attach.exp,
gdb.base/valgrind-infcall.exp, gdb.base/value-double-free.exp,
gdb.base/varargs.exp, gdb.base/watch-cond-infcall.exp,
gdb.base/watch-cond.exp, gdb.base/watch-non-mem.exp,
gdb.base/watch-read.exp, gdb.base/watch-vfork.exp,
gdb.base/watch_thread_num.exp, gdb.base/watchpoint-cond-gone.exp,
gdb.base/watchpoint-delete.exp, gdb.base/watchpoint-hw.exp,
gdb.base/watchpoint-solib.exp, gdb.base/watchpoint.exp,
gdb.base/watchpoints.exp, gdb.base/wchar.exp, gdb.base/whatis.exp:
Use standard_testfile, standard_output_file, prepare_for_testing,
clean_restart.
2013-06-27 21:00:47 +02:00
|
|
|
standard_testfile .c
|
2007-12-17 13:32:23 +01:00
|
|
|
|
|
|
|
# What compiler are we using?
|
|
|
|
#
|
2012-06-21 22:46:25 +02:00
|
|
|
if [get_compiler_info] {
|
2007-12-17 13:32:23 +01:00
|
|
|
return -1
|
|
|
|
}
|
|
|
|
|
2008-04-05 00:59:28 +02:00
|
|
|
if {[gdb_compile_pthreads "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug}] != "" } {
|
|
|
|
return -1
|
2007-12-17 13:32:23 +01:00
|
|
|
}
|
|
|
|
|
test suite update - gdb.base/[t-z]
Convert files gdb.base/[t-z]*.exp to use standard_output_file et al.
* gdb.base/testenv.exp, gdb.base/tui-layout.exp,
gdb.base/twice.exp, gdb.base/type-opaque.exp, gdb.base/unload.exp,
gdb.base/unwindonsignal.exp, gdb.base/valgrind-db-attach.exp,
gdb.base/valgrind-infcall.exp, gdb.base/value-double-free.exp,
gdb.base/varargs.exp, gdb.base/watch-cond-infcall.exp,
gdb.base/watch-cond.exp, gdb.base/watch-non-mem.exp,
gdb.base/watch-read.exp, gdb.base/watch-vfork.exp,
gdb.base/watch_thread_num.exp, gdb.base/watchpoint-cond-gone.exp,
gdb.base/watchpoint-delete.exp, gdb.base/watchpoint-hw.exp,
gdb.base/watchpoint-solib.exp, gdb.base/watchpoint.exp,
gdb.base/watchpoints.exp, gdb.base/wchar.exp, gdb.base/whatis.exp:
Use standard_testfile, standard_output_file, prepare_for_testing,
clean_restart.
2013-06-27 21:00:47 +02:00
|
|
|
clean_restart ${binfile}
|
2007-12-17 13:32:23 +01:00
|
|
|
|
|
|
|
if { ![runto main] } then {
|
|
|
|
fail "run to main"
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
Per-inferior/Inferior-qualified thread IDs
This commit changes GDB to track thread numbers per-inferior. Then,
if you're debugging multiple inferiors, GDB displays
"inferior-num.thread-num" instead of just "thread-num" whenever it
needs to display a thread:
(gdb) info inferiors
Num Description Executable
1 process 6022 /home/pedro/gdb/tests/threads
* 2 process 6037 /home/pedro/gdb/tests/threads
(gdb) info threads
Id Target Id Frame
1.1 Thread 0x7ffff7fc2740 (LWP 6022) "threads" (running)
1.2 Thread 0x7ffff77c0700 (LWP 6028) "threads" (running)
1.3 Thread 0x7ffff7fc2740 (LWP 6032) "threads" (running)
2.1 Thread 0x7ffff7fc1700 (LWP 6037) "threads" (running)
2.2 Thread 0x7ffff77c0700 (LWP 6038) "threads" (running)
* 2.3 Thread 0x7ffff7fc2740 (LWP 6039) "threads" (running)
(gdb)
...
(gdb) thread 1.1
[Switching to thread 1.1 (Thread 0x7ffff7fc2740 (LWP 8155))]
(gdb)
...
etc.
You can still use "thread NUM", in which case GDB infers you're
referring to thread NUM of the current inferior.
The $_thread convenience var and Python's InferiorThread.num attribute
are remapped to the new per-inferior thread number. It's a backward
compatibility break, but since it only matters when debugging multiple
inferiors, I think it's worth doing.
Because MI thread IDs need to be a single integer, we keep giving
threads a global identifier, _in addition_ to the per-inferior number,
and make MI always refer to the global thread IDs. IOW, nothing
changes from a MI frontend's perspective.
Similarly, since Python's Breakpoint.thread and Guile's
breakpoint-thread/set-breakpoint-thread breakpoint methods need to
work with integers, those are adjusted to work with global thread IDs
too. Follow up patches will provide convenient means to access
threads' global IDs.
To avoid potencially confusing users (which also avoids updating much
of the testsuite), if there's only one inferior and its ID is "1",
IOW, the user hasn't done anything multi-process/inferior related,
then the "INF." part of thread IDs is not shown. E.g,.:
(gdb) info inferiors
Num Description Executable
* 1 process 15275 /home/pedro/gdb/tests/threads
(gdb) info threads
Id Target Id Frame
* 1 Thread 0x7ffff7fc1740 (LWP 15275) "threads" main () at threads.c:40
(gdb) add-inferior
Added inferior 2
(gdb) info threads
Id Target Id Frame
* 1.1 Thread 0x7ffff7fc1740 (LWP 15275) "threads" main () at threads.c:40
(gdb)
No regressions on x86_64 Fedora 20.
gdb/ChangeLog:
2016-01-13 Pedro Alves <palves@redhat.com>
* NEWS: Mention that thread IDs are now per inferior and global
thread IDs.
* Makefile.in (SFILES): Add tid-parse.c.
(COMMON_OBS): Add tid-parse.o.
(HFILES_NO_SRCDIR): Add tid-parse.h.
* ada-tasks.c: Adjust to use ptid_to_global_thread_id.
* breakpoint.c (insert_breakpoint_locations)
(remove_threaded_breakpoints, bpstat_check_breakpoint_conditions)
(print_one_breakpoint_location, set_longjmp_breakpoint)
(check_longjmp_breakpoint_for_call_dummy)
(set_momentary_breakpoint): Adjust to use global IDs.
(find_condition_and_thread, watch_command_1): Use parse_thread_id.
(until_break_command, longjmp_bkpt_dtor)
(breakpoint_re_set_thread, insert_single_step_breakpoint): Adjust
to use global IDs.
* dummy-frame.c (pop_dummy_frame_bpt): Adjust to use
ptid_to_global_thread_id.
* elfread.c (elf_gnu_ifunc_resolver_stop): Likewise.
* gdbthread.h (struct thread_info): Rename field 'num' to
'global_num. Add new fields 'per_inf_num' and 'inf'.
(thread_id_to_pid): Rename thread_id_to_pid to
global_thread_id_to_ptid.
(pid_to_thread_id): Rename to ...
(ptid_to_global_thread_id): ... this.
(valid_thread_id): Rename to ...
(valid_global_thread_id): ... this.
(find_thread_id): Rename to ...
(find_thread_global_id): ... this.
(ALL_THREADS, ALL_THREADS_BY_INFERIOR): Declare.
(print_thread_info): Add comment.
* tid-parse.h: New file.
* tid-parse.c: New file.
* infcmd.c (step_command_fsm_prepare)
(step_command_fsm_should_stop): Adjust to use the global thread
ID.
(until_next_command, until_next_command)
(finish_command_fsm_should_stop): Adjust to use the global thread
ID.
(attach_post_wait): Adjust to check the inferior number too.
* inferior.h (struct inferior) <highest_thread_num>: New field.
* infrun.c (handle_signal_stop)
(insert_exception_resume_breakpoint)
(insert_exception_resume_from_probe): Adjust to use the global
thread ID.
* record-btrace.c (record_btrace_open): Use global thread IDs.
* remote.c (process_initial_stop_replies): Also consider the
inferior number.
* target.c (target_pre_inferior): Clear the inferior's highest
thread num.
* thread.c (clear_thread_inferior_resources): Adjust to use the
global thread ID.
(new_thread): New inferior parameter. Adjust to use it. Set both
the thread's global ID and the thread's per-inferior ID.
(add_thread_silent): Adjust.
(find_thread_global_id): New.
(find_thread_id): Make static. Adjust to rename.
(valid_thread_id): Rename to ...
(valid_global_thread_id): ... this.
(pid_to_thread_id): Rename to ...
(ptid_to_global_thread_id): ... this.
(thread_id_to_pid): Rename to ...
(global_thread_id_to_ptid): ... this. Adjust.
(first_thread_of_process): Adjust.
(do_captured_list_thread_ids): Adjust to use global thread IDs.
(should_print_thread): New function.
(print_thread_info): Rename to ...
(print_thread_info_1): ... this, and add new show_global_ids
parameter. Handle it. Iterate over inferiors.
(print_thread_info): Reimplement as wrapper around
print_thread_info_1.
(show_inferior_qualified_tids): New function.
(print_thread_id): Use it.
(tp_array_compar): Compare inferior numbers too.
(thread_apply_command): Use tid_range_parser.
(do_captured_thread_select): Use parse_thread_id.
(thread_id_make_value): Adjust.
(_initialize_thread): Adjust "info threads" help string.
* varobj.c (struct varobj_root): Update comment.
(varobj_create): Adjust to use global thread IDs.
(value_of_root_1): Adjust to use global_thread_id_to_ptid.
* windows-tdep.c (display_tib): No longer accept an argument.
* cli/cli-utils.c (get_number_trailer): Make extern.
* cli/cli-utils.h (get_number_trailer): Declare.
(get_number_const): Adjust documentation.
* mi/mi-cmd-var.c (mi_cmd_var_update_iter): Adjust to use global
thread IDs.
* mi/mi-interp.c (mi_new_thread, mi_thread_exit)
(mi_on_normal_stop, mi_output_running_pid, mi_on_resume):
* mi/mi-main.c (mi_execute_command, mi_cmd_execute): Likewise.
* guile/scm-breakpoint.c (gdbscm_set_breakpoint_thread_x):
Likewise.
* python/py-breakpoint.c (bppy_set_thread): Likewise.
* python/py-finishbreakpoint.c (bpfinishpy_init): Likewise.
* python/py-infthread.c (thpy_get_num): Add comment and return the
per-inferior thread ID.
(thread_object_getset): Update comment of "num".
gdb/testsuite/ChangeLog:
2016-01-07 Pedro Alves <palves@redhat.com>
* gdb.base/break.exp: Adjust to output changes.
* gdb.base/hbreak2.exp: Likewise.
* gdb.base/sepdebug.exp: Likewise.
* gdb.base/watch_thread_num.exp: Likewise.
* gdb.linespec/keywords.exp: Likewise.
* gdb.multi/info-threads.exp: Likewise.
* gdb.threads/thread-find.exp: Likewise.
* gdb.multi/tids.c: New file.
* gdb.multi/tids.exp: New file.
gdb/doc/ChangeLog:
2016-01-07 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Threads): Document per-inferior thread IDs,
qualified thread IDs, global thread IDs and thread ID lists.
(Set Watchpoints, Thread-Specific Breakpoints): Adjust to refer to
thread IDs.
(Convenience Vars): Document the $_thread convenience variable.
(Ada Tasks): Adjust to refer to thread IDs.
(GDB/MI Async Records, GDB/MI Thread Commands, GDB/MI Ada Tasking
Commands, GDB/MI Variable Objects): Update to mention global
thread IDs.
* guile.texi (Breakpoints In Guile)
<breakpoint-thread/set-breakpoint-thread breakpoint>: Mention
global thread IDs instead of thread IDs.
* python.texi (Threads In Python): Adjust documentation of
InferiorThread.num.
(Breakpoint.thread): Mention global thread IDs instead of thread
IDs.
2016-01-13 11:56:07 +01:00
|
|
|
gdb_test "watch shared_var thread 0" "Invalid thread ID: 0" "Watchpoint on invalid thread"
|
2007-12-17 13:32:23 +01:00
|
|
|
gdb_test "watch shared_var thread" "A syntax error in expression, near `thread'\." "Invalid watch syntax"
|
|
|
|
|
watch_thread_num.exp and targets with fairer event reporting
This patch fixes the watch_thread_num.exp test to work when the target
is better at making event handling be fair among threads.
I wrote patches that make GDB native and GDBserver event handling
fairer between threads. That is, if threads A and B both
simultaneously trigger some debug event, GDB will pick either A or B
at random, rather than always handling the event of A first. There's
code for that in the Linux backends (gdb and gdbserver) already, but
it can be improved, and only works in all-stop mode.
With those fixes in place, I found that the watch_thread_num.exp would
often time out. The problem is that the test only works _because_
event handling isn't as fair as intended. With the fairness fixes,
the test falls victim of PR10116 (gdb drops watchpoints on
multi-threaded apps) quite often.
To expand on the PR10116 reference, consider that stop events are
serialized to GDB core, through target_wait. Say a thread-specific
watchpoint as set on thread A. When the "right" thread and some other
"wrong" thread both trigger a watchpoint simultaneously, the target
may report the "wrong" thread's hit to GDB first (thread B). When
handling that event, GDB notices the watchpoint is for another thread,
and so shouldn't cause a user-visible stop. On resume, GDB saves the
now current value of the watched expression. Afterwards, the "right"
thread (thread A) reports its watchpoint trigger. But the watched
value hasn't changed since GDB last saved it, and so GDB doesn't
report the watchpoint hit to the user.
The way the test is written, the watchpoint is associated with the
first thread that happens to report an event. It happens that GDB is
processing events much more often for one of the threads, which
usually will be that same first thread.
Hacking the test with "set debug infrun 1", we see exactly that:
$ grep "infrun.*\[Thread.*," testsuite/gdb.log | sort | uniq -c | sort -nr
70 infrun: 8798 [Thread 8798],
37 infrun: 8798 [Thread 8802],
36 infrun: 8798 [Thread 8804],
36 infrun: 8798 [Thread 8803],
35 infrun: 8798 [Thread 8805],
34 infrun: 8798 [Thread 8806],
The first column shows the number of times the target reported an
event for that thread, from:
infrun: target_wait (-1, status) =
infrun: 8798 [Thread 8798],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
This masks out the PR10116 issue.
However, if the target is better at giving equal priority to all
threads, the PR10116 issue happens often, so it may take quite a while
for the right thread to be the first to report its watchpoint event
just after the memory being watched really changed, resulting in test
time outs.
Here's the number of events handled for each thread on a gdbserver run
with the event fairness patches:
$ grep "infrun.*\[Thread.*," gdb.log | sort | uniq -c
2961 infrun: 13591 [Thread 13591],
2956 infrun: 13591 [Thread 13595],
2941 infrun: 13591 [Thread 13596],
2932 infrun: 13591 [Thread 13597],
2905 infrun: 13591 [Thread 13598],
2891 infrun: 13591 [Thread 13599],
Note how the number of events is much higher. The test routinely
takes over 10 seconds to finish on my machine rather than under a
second as with unpatched gdbserver, when it succeeds, but often it'll
fail with timeouts too.
So to make the test robust, this patch switches the tests to using
"awatch" instead of "watch", as access watchpoints don't care about
the watchpoint's "old value". With this, the test always finishes
quickly, and we can even bump the number of threads concurrently
writting to the shared variable, to have better assurance we're really
testing the case of the "wrong" thread triggering a watchpoint.
Here's the number of events I see for each thread on a run on my
machine, with a gdbserver patched with the event fairness series:
$ grep "infrun.*\[Thread.*," testsuite/gdb.log | sort | uniq -c
5 infrun: 5298 [Thread 5302],
4 infrun: 5298 [Thread 5303],
4 infrun: 5298 [Thread 5304],
4 infrun: 5298 [Thread 5305],
4 infrun: 5298 [Thread 5306],
4 infrun: 5298 [Thread 5307],
4 infrun: 5298 [Thread 5308],
4 infrun: 5298 [Thread 5309],
4 infrun: 5298 [Thread 5310],
4 infrun: 5298 [Thread 5311],
4 infrun: 5298 [Thread 5312],
4 infrun: 5298 [Thread 5313],
4 infrun: 5298 [Thread 5314],
4 infrun: 5298 [Thread 5315],
4 infrun: 5298 [Thread 5316],
gdb/testsuite/
2015-01-09 Pedro Alves <palves@redhat.com>
* gdb.base/annota1.exp (thread_test): Use srcfile and binfile from
the global scope. Set a breakpoint after all threads are started
rather than stepping over two source lines. Expect the prompt.
* gdb.base/watch_thread_num.c (threads_started_barrier): New
global.
(NUM): Now 15.
(main): Use threads_started_barrier to wait for all threads to
start. Main thread no longer calls thread_function. Exit after
180 seconds.
(loop): New function.
(thread_function): Wait on threads_started_barrier barrier. Call
'loop' at each iteration.
* gdb.base/watch_thread_num.exp: Continue to breakpoint after all
threads have started, instead of hardcoding number of "next"
steps. Use an access watchpoint instead of a write watchpoint.
2014-12-29 20:41:05 +01:00
|
|
|
set bpexitline [gdb_get_line_number "all threads started"]
|
|
|
|
gdb_breakpoint "$bpexitline"
|
|
|
|
gdb_continue_to_breakpoint "all threads started"
|
2007-12-17 13:32:23 +01:00
|
|
|
|
watch_thread_num.exp and targets with fairer event reporting
This patch fixes the watch_thread_num.exp test to work when the target
is better at making event handling be fair among threads.
I wrote patches that make GDB native and GDBserver event handling
fairer between threads. That is, if threads A and B both
simultaneously trigger some debug event, GDB will pick either A or B
at random, rather than always handling the event of A first. There's
code for that in the Linux backends (gdb and gdbserver) already, but
it can be improved, and only works in all-stop mode.
With those fixes in place, I found that the watch_thread_num.exp would
often time out. The problem is that the test only works _because_
event handling isn't as fair as intended. With the fairness fixes,
the test falls victim of PR10116 (gdb drops watchpoints on
multi-threaded apps) quite often.
To expand on the PR10116 reference, consider that stop events are
serialized to GDB core, through target_wait. Say a thread-specific
watchpoint as set on thread A. When the "right" thread and some other
"wrong" thread both trigger a watchpoint simultaneously, the target
may report the "wrong" thread's hit to GDB first (thread B). When
handling that event, GDB notices the watchpoint is for another thread,
and so shouldn't cause a user-visible stop. On resume, GDB saves the
now current value of the watched expression. Afterwards, the "right"
thread (thread A) reports its watchpoint trigger. But the watched
value hasn't changed since GDB last saved it, and so GDB doesn't
report the watchpoint hit to the user.
The way the test is written, the watchpoint is associated with the
first thread that happens to report an event. It happens that GDB is
processing events much more often for one of the threads, which
usually will be that same first thread.
Hacking the test with "set debug infrun 1", we see exactly that:
$ grep "infrun.*\[Thread.*," testsuite/gdb.log | sort | uniq -c | sort -nr
70 infrun: 8798 [Thread 8798],
37 infrun: 8798 [Thread 8802],
36 infrun: 8798 [Thread 8804],
36 infrun: 8798 [Thread 8803],
35 infrun: 8798 [Thread 8805],
34 infrun: 8798 [Thread 8806],
The first column shows the number of times the target reported an
event for that thread, from:
infrun: target_wait (-1, status) =
infrun: 8798 [Thread 8798],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
This masks out the PR10116 issue.
However, if the target is better at giving equal priority to all
threads, the PR10116 issue happens often, so it may take quite a while
for the right thread to be the first to report its watchpoint event
just after the memory being watched really changed, resulting in test
time outs.
Here's the number of events handled for each thread on a gdbserver run
with the event fairness patches:
$ grep "infrun.*\[Thread.*," gdb.log | sort | uniq -c
2961 infrun: 13591 [Thread 13591],
2956 infrun: 13591 [Thread 13595],
2941 infrun: 13591 [Thread 13596],
2932 infrun: 13591 [Thread 13597],
2905 infrun: 13591 [Thread 13598],
2891 infrun: 13591 [Thread 13599],
Note how the number of events is much higher. The test routinely
takes over 10 seconds to finish on my machine rather than under a
second as with unpatched gdbserver, when it succeeds, but often it'll
fail with timeouts too.
So to make the test robust, this patch switches the tests to using
"awatch" instead of "watch", as access watchpoints don't care about
the watchpoint's "old value". With this, the test always finishes
quickly, and we can even bump the number of threads concurrently
writting to the shared variable, to have better assurance we're really
testing the case of the "wrong" thread triggering a watchpoint.
Here's the number of events I see for each thread on a run on my
machine, with a gdbserver patched with the event fairness series:
$ grep "infrun.*\[Thread.*," testsuite/gdb.log | sort | uniq -c
5 infrun: 5298 [Thread 5302],
4 infrun: 5298 [Thread 5303],
4 infrun: 5298 [Thread 5304],
4 infrun: 5298 [Thread 5305],
4 infrun: 5298 [Thread 5306],
4 infrun: 5298 [Thread 5307],
4 infrun: 5298 [Thread 5308],
4 infrun: 5298 [Thread 5309],
4 infrun: 5298 [Thread 5310],
4 infrun: 5298 [Thread 5311],
4 infrun: 5298 [Thread 5312],
4 infrun: 5298 [Thread 5313],
4 infrun: 5298 [Thread 5314],
4 infrun: 5298 [Thread 5315],
4 infrun: 5298 [Thread 5316],
gdb/testsuite/
2015-01-09 Pedro Alves <palves@redhat.com>
* gdb.base/annota1.exp (thread_test): Use srcfile and binfile from
the global scope. Set a breakpoint after all threads are started
rather than stepping over two source lines. Expect the prompt.
* gdb.base/watch_thread_num.c (threads_started_barrier): New
global.
(NUM): Now 15.
(main): Use threads_started_barrier to wait for all threads to
start. Main thread no longer calls thread_function. Exit after
180 seconds.
(loop): New function.
(thread_function): Wait on threads_started_barrier barrier. Call
'loop' at each iteration.
* gdb.base/watch_thread_num.exp: Continue to breakpoint after all
threads have started, instead of hardcoding number of "next"
steps. Use an access watchpoint instead of a write watchpoint.
2014-12-29 20:41:05 +01:00
|
|
|
gdb_test "break loop" "Breakpoint \[0-9\].*" \
|
|
|
|
"Set breakpoint at loop"
|
2007-12-17 13:32:23 +01:00
|
|
|
|
watch_thread_num.exp and targets with fairer event reporting
This patch fixes the watch_thread_num.exp test to work when the target
is better at making event handling be fair among threads.
I wrote patches that make GDB native and GDBserver event handling
fairer between threads. That is, if threads A and B both
simultaneously trigger some debug event, GDB will pick either A or B
at random, rather than always handling the event of A first. There's
code for that in the Linux backends (gdb and gdbserver) already, but
it can be improved, and only works in all-stop mode.
With those fixes in place, I found that the watch_thread_num.exp would
often time out. The problem is that the test only works _because_
event handling isn't as fair as intended. With the fairness fixes,
the test falls victim of PR10116 (gdb drops watchpoints on
multi-threaded apps) quite often.
To expand on the PR10116 reference, consider that stop events are
serialized to GDB core, through target_wait. Say a thread-specific
watchpoint as set on thread A. When the "right" thread and some other
"wrong" thread both trigger a watchpoint simultaneously, the target
may report the "wrong" thread's hit to GDB first (thread B). When
handling that event, GDB notices the watchpoint is for another thread,
and so shouldn't cause a user-visible stop. On resume, GDB saves the
now current value of the watched expression. Afterwards, the "right"
thread (thread A) reports its watchpoint trigger. But the watched
value hasn't changed since GDB last saved it, and so GDB doesn't
report the watchpoint hit to the user.
The way the test is written, the watchpoint is associated with the
first thread that happens to report an event. It happens that GDB is
processing events much more often for one of the threads, which
usually will be that same first thread.
Hacking the test with "set debug infrun 1", we see exactly that:
$ grep "infrun.*\[Thread.*," testsuite/gdb.log | sort | uniq -c | sort -nr
70 infrun: 8798 [Thread 8798],
37 infrun: 8798 [Thread 8802],
36 infrun: 8798 [Thread 8804],
36 infrun: 8798 [Thread 8803],
35 infrun: 8798 [Thread 8805],
34 infrun: 8798 [Thread 8806],
The first column shows the number of times the target reported an
event for that thread, from:
infrun: target_wait (-1, status) =
infrun: 8798 [Thread 8798],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
This masks out the PR10116 issue.
However, if the target is better at giving equal priority to all
threads, the PR10116 issue happens often, so it may take quite a while
for the right thread to be the first to report its watchpoint event
just after the memory being watched really changed, resulting in test
time outs.
Here's the number of events handled for each thread on a gdbserver run
with the event fairness patches:
$ grep "infrun.*\[Thread.*," gdb.log | sort | uniq -c
2961 infrun: 13591 [Thread 13591],
2956 infrun: 13591 [Thread 13595],
2941 infrun: 13591 [Thread 13596],
2932 infrun: 13591 [Thread 13597],
2905 infrun: 13591 [Thread 13598],
2891 infrun: 13591 [Thread 13599],
Note how the number of events is much higher. The test routinely
takes over 10 seconds to finish on my machine rather than under a
second as with unpatched gdbserver, when it succeeds, but often it'll
fail with timeouts too.
So to make the test robust, this patch switches the tests to using
"awatch" instead of "watch", as access watchpoints don't care about
the watchpoint's "old value". With this, the test always finishes
quickly, and we can even bump the number of threads concurrently
writting to the shared variable, to have better assurance we're really
testing the case of the "wrong" thread triggering a watchpoint.
Here's the number of events I see for each thread on a run on my
machine, with a gdbserver patched with the event fairness series:
$ grep "infrun.*\[Thread.*," testsuite/gdb.log | sort | uniq -c
5 infrun: 5298 [Thread 5302],
4 infrun: 5298 [Thread 5303],
4 infrun: 5298 [Thread 5304],
4 infrun: 5298 [Thread 5305],
4 infrun: 5298 [Thread 5306],
4 infrun: 5298 [Thread 5307],
4 infrun: 5298 [Thread 5308],
4 infrun: 5298 [Thread 5309],
4 infrun: 5298 [Thread 5310],
4 infrun: 5298 [Thread 5311],
4 infrun: 5298 [Thread 5312],
4 infrun: 5298 [Thread 5313],
4 infrun: 5298 [Thread 5314],
4 infrun: 5298 [Thread 5315],
4 infrun: 5298 [Thread 5316],
gdb/testsuite/
2015-01-09 Pedro Alves <palves@redhat.com>
* gdb.base/annota1.exp (thread_test): Use srcfile and binfile from
the global scope. Set a breakpoint after all threads are started
rather than stepping over two source lines. Expect the prompt.
* gdb.base/watch_thread_num.c (threads_started_barrier): New
global.
(NUM): Now 15.
(main): Use threads_started_barrier to wait for all threads to
start. Main thread no longer calls thread_function. Exit after
180 seconds.
(loop): New function.
(thread_function): Wait on threads_started_barrier barrier. Call
'loop' at each iteration.
* gdb.base/watch_thread_num.exp: Continue to breakpoint after all
threads have started, instead of hardcoding number of "next"
steps. Use an access watchpoint instead of a write watchpoint.
2014-12-29 20:41:05 +01:00
|
|
|
gdb_test "continue" ".*Breakpoint .*loop.*" "Stopped in loop"
|
2007-12-19 15:40:37 +01:00
|
|
|
|
2010-05-28 01:44:51 +02:00
|
|
|
gdb_test_multiple "thread" "Thread command" {
|
|
|
|
-re ".*Current thread is (\[0-9\]*).*$gdb_prompt $" {
|
2016-12-01 21:40:05 +01:00
|
|
|
pass "thread command"
|
2010-05-28 01:44:51 +02:00
|
|
|
}
|
2007-12-19 15:40:37 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
set thread_num "$expect_out(1,string)"
|
|
|
|
|
watch_thread_num.exp and targets with fairer event reporting
This patch fixes the watch_thread_num.exp test to work when the target
is better at making event handling be fair among threads.
I wrote patches that make GDB native and GDBserver event handling
fairer between threads. That is, if threads A and B both
simultaneously trigger some debug event, GDB will pick either A or B
at random, rather than always handling the event of A first. There's
code for that in the Linux backends (gdb and gdbserver) already, but
it can be improved, and only works in all-stop mode.
With those fixes in place, I found that the watch_thread_num.exp would
often time out. The problem is that the test only works _because_
event handling isn't as fair as intended. With the fairness fixes,
the test falls victim of PR10116 (gdb drops watchpoints on
multi-threaded apps) quite often.
To expand on the PR10116 reference, consider that stop events are
serialized to GDB core, through target_wait. Say a thread-specific
watchpoint as set on thread A. When the "right" thread and some other
"wrong" thread both trigger a watchpoint simultaneously, the target
may report the "wrong" thread's hit to GDB first (thread B). When
handling that event, GDB notices the watchpoint is for another thread,
and so shouldn't cause a user-visible stop. On resume, GDB saves the
now current value of the watched expression. Afterwards, the "right"
thread (thread A) reports its watchpoint trigger. But the watched
value hasn't changed since GDB last saved it, and so GDB doesn't
report the watchpoint hit to the user.
The way the test is written, the watchpoint is associated with the
first thread that happens to report an event. It happens that GDB is
processing events much more often for one of the threads, which
usually will be that same first thread.
Hacking the test with "set debug infrun 1", we see exactly that:
$ grep "infrun.*\[Thread.*," testsuite/gdb.log | sort | uniq -c | sort -nr
70 infrun: 8798 [Thread 8798],
37 infrun: 8798 [Thread 8802],
36 infrun: 8798 [Thread 8804],
36 infrun: 8798 [Thread 8803],
35 infrun: 8798 [Thread 8805],
34 infrun: 8798 [Thread 8806],
The first column shows the number of times the target reported an
event for that thread, from:
infrun: target_wait (-1, status) =
infrun: 8798 [Thread 8798],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
This masks out the PR10116 issue.
However, if the target is better at giving equal priority to all
threads, the PR10116 issue happens often, so it may take quite a while
for the right thread to be the first to report its watchpoint event
just after the memory being watched really changed, resulting in test
time outs.
Here's the number of events handled for each thread on a gdbserver run
with the event fairness patches:
$ grep "infrun.*\[Thread.*," gdb.log | sort | uniq -c
2961 infrun: 13591 [Thread 13591],
2956 infrun: 13591 [Thread 13595],
2941 infrun: 13591 [Thread 13596],
2932 infrun: 13591 [Thread 13597],
2905 infrun: 13591 [Thread 13598],
2891 infrun: 13591 [Thread 13599],
Note how the number of events is much higher. The test routinely
takes over 10 seconds to finish on my machine rather than under a
second as with unpatched gdbserver, when it succeeds, but often it'll
fail with timeouts too.
So to make the test robust, this patch switches the tests to using
"awatch" instead of "watch", as access watchpoints don't care about
the watchpoint's "old value". With this, the test always finishes
quickly, and we can even bump the number of threads concurrently
writting to the shared variable, to have better assurance we're really
testing the case of the "wrong" thread triggering a watchpoint.
Here's the number of events I see for each thread on a run on my
machine, with a gdbserver patched with the event fairness series:
$ grep "infrun.*\[Thread.*," testsuite/gdb.log | sort | uniq -c
5 infrun: 5298 [Thread 5302],
4 infrun: 5298 [Thread 5303],
4 infrun: 5298 [Thread 5304],
4 infrun: 5298 [Thread 5305],
4 infrun: 5298 [Thread 5306],
4 infrun: 5298 [Thread 5307],
4 infrun: 5298 [Thread 5308],
4 infrun: 5298 [Thread 5309],
4 infrun: 5298 [Thread 5310],
4 infrun: 5298 [Thread 5311],
4 infrun: 5298 [Thread 5312],
4 infrun: 5298 [Thread 5313],
4 infrun: 5298 [Thread 5314],
4 infrun: 5298 [Thread 5315],
4 infrun: 5298 [Thread 5316],
gdb/testsuite/
2015-01-09 Pedro Alves <palves@redhat.com>
* gdb.base/annota1.exp (thread_test): Use srcfile and binfile from
the global scope. Set a breakpoint after all threads are started
rather than stepping over two source lines. Expect the prompt.
* gdb.base/watch_thread_num.c (threads_started_barrier): New
global.
(NUM): Now 15.
(main): Use threads_started_barrier to wait for all threads to
start. Main thread no longer calls thread_function. Exit after
180 seconds.
(loop): New function.
(thread_function): Wait on threads_started_barrier barrier. Call
'loop' at each iteration.
* gdb.base/watch_thread_num.exp: Continue to breakpoint after all
threads have started, instead of hardcoding number of "next"
steps. Use an access watchpoint instead of a write watchpoint.
2014-12-29 20:41:05 +01:00
|
|
|
delete_breakpoints
|
2007-12-19 15:40:37 +01:00
|
|
|
|
watch_thread_num.exp and targets with fairer event reporting
This patch fixes the watch_thread_num.exp test to work when the target
is better at making event handling be fair among threads.
I wrote patches that make GDB native and GDBserver event handling
fairer between threads. That is, if threads A and B both
simultaneously trigger some debug event, GDB will pick either A or B
at random, rather than always handling the event of A first. There's
code for that in the Linux backends (gdb and gdbserver) already, but
it can be improved, and only works in all-stop mode.
With those fixes in place, I found that the watch_thread_num.exp would
often time out. The problem is that the test only works _because_
event handling isn't as fair as intended. With the fairness fixes,
the test falls victim of PR10116 (gdb drops watchpoints on
multi-threaded apps) quite often.
To expand on the PR10116 reference, consider that stop events are
serialized to GDB core, through target_wait. Say a thread-specific
watchpoint as set on thread A. When the "right" thread and some other
"wrong" thread both trigger a watchpoint simultaneously, the target
may report the "wrong" thread's hit to GDB first (thread B). When
handling that event, GDB notices the watchpoint is for another thread,
and so shouldn't cause a user-visible stop. On resume, GDB saves the
now current value of the watched expression. Afterwards, the "right"
thread (thread A) reports its watchpoint trigger. But the watched
value hasn't changed since GDB last saved it, and so GDB doesn't
report the watchpoint hit to the user.
The way the test is written, the watchpoint is associated with the
first thread that happens to report an event. It happens that GDB is
processing events much more often for one of the threads, which
usually will be that same first thread.
Hacking the test with "set debug infrun 1", we see exactly that:
$ grep "infrun.*\[Thread.*," testsuite/gdb.log | sort | uniq -c | sort -nr
70 infrun: 8798 [Thread 8798],
37 infrun: 8798 [Thread 8802],
36 infrun: 8798 [Thread 8804],
36 infrun: 8798 [Thread 8803],
35 infrun: 8798 [Thread 8805],
34 infrun: 8798 [Thread 8806],
The first column shows the number of times the target reported an
event for that thread, from:
infrun: target_wait (-1, status) =
infrun: 8798 [Thread 8798],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
This masks out the PR10116 issue.
However, if the target is better at giving equal priority to all
threads, the PR10116 issue happens often, so it may take quite a while
for the right thread to be the first to report its watchpoint event
just after the memory being watched really changed, resulting in test
time outs.
Here's the number of events handled for each thread on a gdbserver run
with the event fairness patches:
$ grep "infrun.*\[Thread.*," gdb.log | sort | uniq -c
2961 infrun: 13591 [Thread 13591],
2956 infrun: 13591 [Thread 13595],
2941 infrun: 13591 [Thread 13596],
2932 infrun: 13591 [Thread 13597],
2905 infrun: 13591 [Thread 13598],
2891 infrun: 13591 [Thread 13599],
Note how the number of events is much higher. The test routinely
takes over 10 seconds to finish on my machine rather than under a
second as with unpatched gdbserver, when it succeeds, but often it'll
fail with timeouts too.
So to make the test robust, this patch switches the tests to using
"awatch" instead of "watch", as access watchpoints don't care about
the watchpoint's "old value". With this, the test always finishes
quickly, and we can even bump the number of threads concurrently
writting to the shared variable, to have better assurance we're really
testing the case of the "wrong" thread triggering a watchpoint.
Here's the number of events I see for each thread on a run on my
machine, with a gdbserver patched with the event fairness series:
$ grep "infrun.*\[Thread.*," testsuite/gdb.log | sort | uniq -c
5 infrun: 5298 [Thread 5302],
4 infrun: 5298 [Thread 5303],
4 infrun: 5298 [Thread 5304],
4 infrun: 5298 [Thread 5305],
4 infrun: 5298 [Thread 5306],
4 infrun: 5298 [Thread 5307],
4 infrun: 5298 [Thread 5308],
4 infrun: 5298 [Thread 5309],
4 infrun: 5298 [Thread 5310],
4 infrun: 5298 [Thread 5311],
4 infrun: 5298 [Thread 5312],
4 infrun: 5298 [Thread 5313],
4 infrun: 5298 [Thread 5314],
4 infrun: 5298 [Thread 5315],
4 infrun: 5298 [Thread 5316],
gdb/testsuite/
2015-01-09 Pedro Alves <palves@redhat.com>
* gdb.base/annota1.exp (thread_test): Use srcfile and binfile from
the global scope. Set a breakpoint after all threads are started
rather than stepping over two source lines. Expect the prompt.
* gdb.base/watch_thread_num.c (threads_started_barrier): New
global.
(NUM): Now 15.
(main): Use threads_started_barrier to wait for all threads to
start. Main thread no longer calls thread_function. Exit after
180 seconds.
(loop): New function.
(thread_function): Wait on threads_started_barrier barrier. Call
'loop' at each iteration.
* gdb.base/watch_thread_num.exp: Continue to breakpoint after all
threads have started, instead of hardcoding number of "next"
steps. Use an access watchpoint instead of a write watchpoint.
2014-12-29 20:41:05 +01:00
|
|
|
# We use an access watchpoint rather than a write watchpoint, because
|
|
|
|
# GDB can drop the latter when multiple threads trigger events
|
|
|
|
# simultaneously, on targets with continuable watchpoints, such as
|
|
|
|
# x86. See PR breakpoints/10116.
|
|
|
|
|
|
|
|
gdb_test "awatch shared_var thread $thread_num" \
|
|
|
|
"Hardware access \\(read/write\\) watchpoint .*: shared_var.*" \
|
|
|
|
"Watchpoint on shared variable"
|
|
|
|
|
|
|
|
gdb_test "info breakpoint \$bpnum" \
|
|
|
|
"stop only in thread $thread_num" \
|
|
|
|
"info breakpoint shows watchpoint is thread-specific"
|
|
|
|
|
|
|
|
for {set i 1} {$i <= 5} {incr i} {
|
2008-05-13 23:17:18 +02:00
|
|
|
set watchpoint "Watchpoint triggered iteration $i"
|
|
|
|
set check "Check thread that triggered iteration $i"
|
|
|
|
|
watch_thread_num.exp and targets with fairer event reporting
This patch fixes the watch_thread_num.exp test to work when the target
is better at making event handling be fair among threads.
I wrote patches that make GDB native and GDBserver event handling
fairer between threads. That is, if threads A and B both
simultaneously trigger some debug event, GDB will pick either A or B
at random, rather than always handling the event of A first. There's
code for that in the Linux backends (gdb and gdbserver) already, but
it can be improved, and only works in all-stop mode.
With those fixes in place, I found that the watch_thread_num.exp would
often time out. The problem is that the test only works _because_
event handling isn't as fair as intended. With the fairness fixes,
the test falls victim of PR10116 (gdb drops watchpoints on
multi-threaded apps) quite often.
To expand on the PR10116 reference, consider that stop events are
serialized to GDB core, through target_wait. Say a thread-specific
watchpoint as set on thread A. When the "right" thread and some other
"wrong" thread both trigger a watchpoint simultaneously, the target
may report the "wrong" thread's hit to GDB first (thread B). When
handling that event, GDB notices the watchpoint is for another thread,
and so shouldn't cause a user-visible stop. On resume, GDB saves the
now current value of the watched expression. Afterwards, the "right"
thread (thread A) reports its watchpoint trigger. But the watched
value hasn't changed since GDB last saved it, and so GDB doesn't
report the watchpoint hit to the user.
The way the test is written, the watchpoint is associated with the
first thread that happens to report an event. It happens that GDB is
processing events much more often for one of the threads, which
usually will be that same first thread.
Hacking the test with "set debug infrun 1", we see exactly that:
$ grep "infrun.*\[Thread.*," testsuite/gdb.log | sort | uniq -c | sort -nr
70 infrun: 8798 [Thread 8798],
37 infrun: 8798 [Thread 8802],
36 infrun: 8798 [Thread 8804],
36 infrun: 8798 [Thread 8803],
35 infrun: 8798 [Thread 8805],
34 infrun: 8798 [Thread 8806],
The first column shows the number of times the target reported an
event for that thread, from:
infrun: target_wait (-1, status) =
infrun: 8798 [Thread 8798],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
This masks out the PR10116 issue.
However, if the target is better at giving equal priority to all
threads, the PR10116 issue happens often, so it may take quite a while
for the right thread to be the first to report its watchpoint event
just after the memory being watched really changed, resulting in test
time outs.
Here's the number of events handled for each thread on a gdbserver run
with the event fairness patches:
$ grep "infrun.*\[Thread.*," gdb.log | sort | uniq -c
2961 infrun: 13591 [Thread 13591],
2956 infrun: 13591 [Thread 13595],
2941 infrun: 13591 [Thread 13596],
2932 infrun: 13591 [Thread 13597],
2905 infrun: 13591 [Thread 13598],
2891 infrun: 13591 [Thread 13599],
Note how the number of events is much higher. The test routinely
takes over 10 seconds to finish on my machine rather than under a
second as with unpatched gdbserver, when it succeeds, but often it'll
fail with timeouts too.
So to make the test robust, this patch switches the tests to using
"awatch" instead of "watch", as access watchpoints don't care about
the watchpoint's "old value". With this, the test always finishes
quickly, and we can even bump the number of threads concurrently
writting to the shared variable, to have better assurance we're really
testing the case of the "wrong" thread triggering a watchpoint.
Here's the number of events I see for each thread on a run on my
machine, with a gdbserver patched with the event fairness series:
$ grep "infrun.*\[Thread.*," testsuite/gdb.log | sort | uniq -c
5 infrun: 5298 [Thread 5302],
4 infrun: 5298 [Thread 5303],
4 infrun: 5298 [Thread 5304],
4 infrun: 5298 [Thread 5305],
4 infrun: 5298 [Thread 5306],
4 infrun: 5298 [Thread 5307],
4 infrun: 5298 [Thread 5308],
4 infrun: 5298 [Thread 5309],
4 infrun: 5298 [Thread 5310],
4 infrun: 5298 [Thread 5311],
4 infrun: 5298 [Thread 5312],
4 infrun: 5298 [Thread 5313],
4 infrun: 5298 [Thread 5314],
4 infrun: 5298 [Thread 5315],
4 infrun: 5298 [Thread 5316],
gdb/testsuite/
2015-01-09 Pedro Alves <palves@redhat.com>
* gdb.base/annota1.exp (thread_test): Use srcfile and binfile from
the global scope. Set a breakpoint after all threads are started
rather than stepping over two source lines. Expect the prompt.
* gdb.base/watch_thread_num.c (threads_started_barrier): New
global.
(NUM): Now 15.
(main): Use threads_started_barrier to wait for all threads to
start. Main thread no longer calls thread_function. Exit after
180 seconds.
(loop): New function.
(thread_function): Wait on threads_started_barrier barrier. Call
'loop' at each iteration.
* gdb.base/watch_thread_num.exp: Continue to breakpoint after all
threads have started, instead of hardcoding number of "next"
steps. Use an access watchpoint instead of a write watchpoint.
2014-12-29 20:41:05 +01:00
|
|
|
set test $watchpoint
|
|
|
|
gdb_test_multiple "continue" $test {
|
|
|
|
-re "infrun:" {
|
|
|
|
# Avoid timeouts when debugging GDB.
|
|
|
|
exp_continue
|
|
|
|
}
|
|
|
|
-re "Hardware access \\(read/write\\) watchpoint .*: shared_var.*$gdb_prompt $" {
|
|
|
|
pass $test
|
|
|
|
}
|
|
|
|
}
|
2008-09-04 02:51:04 +02:00
|
|
|
gdb_test "thread" ".*Current thread is $thread_num .*" $check
|
2007-12-17 13:32:23 +01:00
|
|
|
}
|
|
|
|
|