2018-01-01 05:43:02 +01:00
# Copyright 1999-2018 Free Software Foundation, Inc.
1999-05-05 23:45:13 +02: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
2007-08-23 20:14:19 +02:00
# the Free Software Foundation; either version 3 of the License, or
1999-05-05 23:45:13 +02:00
# (at your option) any later version.
2007-08-23 20:14:19 +02:00
#
1999-05-05 23:45:13 +02:00
# 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.
2007-08-23 20:14:19 +02:00
#
1999-05-05 23:45:13 +02:00
# You should have received a copy of the GNU General Public License
2007-08-23 20:14:19 +02:00
# along with this program. If not, see <http://www.gnu.org/licenses/>.
1999-05-05 23:45:13 +02:00
# This file was written by Elena Zannoni (ezannoni@cygnus.com)
2017-10-12 19:20:25 +02:00
# This testcase cannot use runto_main because of the different prompt
# we get when using annotation level 2.
2001-03-08 22:09:23 +01:00
#
2017-10-12 19:20:25 +02:00
if ![target_can_use_run_cmd] {
2001-03-08 22:09:23 +01:00
return 0
}
All annotate_breakpoints_changed calls are along-side
observer_notify_breakpoints_changed calls. All, except the
init_raw_breakpoint one. But that one is actually wrong. The
breakpoint is being constructed at that point, and hasn't been placed
on the breakpoint chain yet. It would be better placed in
install_breakpoint, and I actually started out that way. But once the
annotate_breakpoints_changed are parallel to the observer calls, we
can fully move annotations to observers too.
One issue is that this changes the order of annotations a bit.
Before, we'd emit the annotation, and after call "mention()" on the
breakpoint (which prints the breakpoint number, etc.). But, we call
the observers _after_ mention is called, so the annotation output will
change a little:
void
install_breakpoint (int internal, struct breakpoint *b, int update_gll)
{
add_to_breakpoint_chain (b);
set_breakpoint_number (internal, b);
if (is_tracepoint (b))
set_tracepoint_count (breakpoint_count);
if (!internal)
mention (b);
observer_notify_breakpoint_created (b);
if (update_gll)
update_global_location_list (1);
}
I believe this order doesn't really matter (the frontend needs to wait
for the prompt anyway), so I just adjust the expected output in the
tests. Emacs in annotations mode doesn't seem to complain. Couple
that with the previous patch that suppressed duplicated annotations,
and, the fact that some annotations calls were actually missing (were
we do have observer calls), more changes to the tests are needed
anyway.
Tested on x86_64 Fedora 17.
gdb/
2013-01-22 Pedro Alves <palves@redhat.com>
* annotate.c (annotate_breakpoints_changed): Rename to ...
(annotate_breakpoints_invalid): ... this. Make static.
(breakpoint_changed): Adjust.
(_initialize_annotate): Always install the observers. Install a
"breakpoint_created" observer.
* annotate.h (annotate_breakpoints_changed): Delete declaration.
* breakpoint.c (set_breakpoint_condition)
(breakpoint_set_commands, do_map_commands_command)
(init_raw_breakpoint, clear_command, set_ignore_count)
(enable_breakpoint_disp): No longer call
annotate_breakpoints_changed.
gdb/testsuite/
2013-01-22 Pedro Alves <palves@redhat.com>
* gdb.base/annota1.exp (breakpoints_invalid): New variable.
Adjust tests to breakpoints-invalid changes.
* gdb.cp/annota2.exp (breakpoints_invalid, frames_invalid): New
variables.
Adjust tests to breakpoints-invalid changes.
2013-01-22 21:19:40 +01:00
set breakpoints_invalid "\r\n\032\032breakpoints-invalid\r\n"
2001-03-08 22:09:23 +01:00
1999-05-05 23:45:13 +02:00
#
# test running programs
#
test suite update - gdb.base/[ab]
Convert files gdb.base/[ab]*.exp to use standard_output_file et al.
* a2-run.exp, all-bin.exp, annota1.exp, annota3.exp, anon.exp,
args.exp, arithmet.exp, arrayidx.exp, assign.exp, async-shell.exp,
async.exp, attach-pie-misread.exp, attach-pie-noexec.exp,
attach-twice.exp, attach.exp, auxv.exp, bang.exp, bfp-test.exp,
bigcore.exp, bitfields.exp, bitfields2.exp, break-entry.exp,
break-interp.exp, break-on-linker-gcd-function.exp,
breakpoint-shadow.exp: Use standard_testfile,
standard_output_file, prepare_for_testing, clean_restart.
2013-06-27 20:47:53 +02:00
standard_testfile .c
1999-05-05 23:45:13 +02:00
2006-03-07 16:23:33 +01:00
if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug nowarnings}] != "" } {
2016-12-01 21:47:50 +01:00
untested "failed to compile"
2006-08-10 07:27:22 +02:00
return -1
1999-05-05 23:45:13 +02:00
}
test suite update - gdb.base/[ab]
Convert files gdb.base/[ab]*.exp to use standard_output_file et al.
* a2-run.exp, all-bin.exp, annota1.exp, annota3.exp, anon.exp,
args.exp, arithmet.exp, arrayidx.exp, assign.exp, async-shell.exp,
async.exp, attach-pie-misread.exp, attach-pie-noexec.exp,
attach-twice.exp, attach.exp, auxv.exp, bang.exp, bfp-test.exp,
bigcore.exp, bitfields.exp, bitfields2.exp, break-entry.exp,
break-interp.exp, break-on-linker-gcd-function.exp,
breakpoint-shadow.exp: Use standard_testfile,
standard_output_file, prepare_for_testing, clean_restart.
2013-06-27 20:47:53 +02:00
clean_restart ${binfile}
1999-05-05 23:45:13 +02:00
# The commands we test here produce many lines of output; disable "press
# <return> to continue" prompts.
2010-05-26 20:05:25 +02:00
gdb_test_no_output "set height 0"
1999-05-05 23:45:13 +02:00
#
Fix fail in gdb.base/annota1.exp and gdb.base/annota3.exp
Hi,
I am seeing the fail below on aarch64-linux with gcc 4.9.2,
break main
Breakpoint 1 at 0x4006e8: file binutils-gdb/gdb/testsuite/gdb.base/annota1.c, line 14.^M
(gdb) FAIL: gdb.base/annota1.exp: breakpoint main
the test expects the breakpoint is set on line 15. Let us look at
the main function,
12 int
13 main (void)
14 {
15 int my_array[3] = { 1, 2, 3 }; /* break main */
16
17 value = 7;
18
19 #ifdef SIGUSR1
20 signal (SIGUSR1, handle_USR1);
21 #endif
(gdb) disassemble main
Dump of assembler code for function main:
0x00000000004006e0 <+0>: stp x29, x30, [sp,#-48]!
0x00000000004006e4 <+4>: mov x29, sp
0x00000000004006e8 <+8>: adrp x0, 0x411000 <signal@got.plt>
0x00000000004006ec <+12>: add x0, x0, #0x40
the breakpoint is set on the right address after skipping prologue, but
0x00000000004006e8 is mapped to the line 14, as shown below,
(gdb) maintenance info line-table
objfile: /home/yao.qi/source/build-aarch64/gdb/testsuite/outputs/gdb.base/annota1/annota1 ((struct objfile *) 0x2b0e1850)
compunit_symtab: ((struct compunit_symtab *) 0x2b0ded50)
symtab: /home/yao.qi/source/binutils-gdb/gdb/testsuite/gdb.base/annota1.c ((struct symtab *) 0x2b0dedd0)
linetable: ((struct linetable *) 0x2b12c8b0):
INDEX LINE ADDRESS
0 7 0x00000000004006d0
1 8 0x00000000004006d8
2 14 0x00000000004006e0
3 14 0x00000000004006e8
4 15 0x00000000004006fc
so GDB does nothing wrong. Program hits breakpoint on either line 14
or line 15 is right to me. With anther gcc (4.9.3), the line-table looks
correct, and no test fail. Instead of setting breakpoint on main and
assuming the line is what we get from the source, we can set breakpoint
on that line. On the other hand, the test prints the values of the
array and check, so we need to set breakpoint on the line setting the
values of array and "next", rather than setting the breakpoint on main.
gdb/testsuite:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* gdb.base/annota1.exp: Set breakpoint on line $main_line.
* gdb.base/annota3.exp: Likewise.
2016-04-22 16:35:07 +02:00
# break in main
1999-05-05 23:45:13 +02:00
#
2012-02-28 23:40:48 +01:00
set main_line [gdb_get_line_number "break main"]
Fix fail in gdb.base/annota1.exp and gdb.base/annota3.exp
Hi,
I am seeing the fail below on aarch64-linux with gcc 4.9.2,
break main
Breakpoint 1 at 0x4006e8: file binutils-gdb/gdb/testsuite/gdb.base/annota1.c, line 14.^M
(gdb) FAIL: gdb.base/annota1.exp: breakpoint main
the test expects the breakpoint is set on line 15. Let us look at
the main function,
12 int
13 main (void)
14 {
15 int my_array[3] = { 1, 2, 3 }; /* break main */
16
17 value = 7;
18
19 #ifdef SIGUSR1
20 signal (SIGUSR1, handle_USR1);
21 #endif
(gdb) disassemble main
Dump of assembler code for function main:
0x00000000004006e0 <+0>: stp x29, x30, [sp,#-48]!
0x00000000004006e4 <+4>: mov x29, sp
0x00000000004006e8 <+8>: adrp x0, 0x411000 <signal@got.plt>
0x00000000004006ec <+12>: add x0, x0, #0x40
the breakpoint is set on the right address after skipping prologue, but
0x00000000004006e8 is mapped to the line 14, as shown below,
(gdb) maintenance info line-table
objfile: /home/yao.qi/source/build-aarch64/gdb/testsuite/outputs/gdb.base/annota1/annota1 ((struct objfile *) 0x2b0e1850)
compunit_symtab: ((struct compunit_symtab *) 0x2b0ded50)
symtab: /home/yao.qi/source/binutils-gdb/gdb/testsuite/gdb.base/annota1.c ((struct symtab *) 0x2b0dedd0)
linetable: ((struct linetable *) 0x2b12c8b0):
INDEX LINE ADDRESS
0 7 0x00000000004006d0
1 8 0x00000000004006d8
2 14 0x00000000004006e0
3 14 0x00000000004006e8
4 15 0x00000000004006fc
so GDB does nothing wrong. Program hits breakpoint on either line 14
or line 15 is right to me. With anther gcc (4.9.3), the line-table looks
correct, and no test fail. Instead of setting breakpoint on main and
assuming the line is what we get from the source, we can set breakpoint
on that line. On the other hand, the test prints the values of the
array and check, so we need to set breakpoint on the line setting the
values of array and "next", rather than setting the breakpoint on main.
gdb/testsuite:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* gdb.base/annota1.exp: Set breakpoint on line $main_line.
* gdb.base/annota3.exp: Likewise.
2016-04-22 16:35:07 +02:00
gdb_test "break ${srcfile}:${main_line}" \
2012-02-28 23:40:48 +01:00
"Breakpoint.*at.* file .*$srcfile, line $main_line\\." \
1999-05-05 23:45:13 +02:00
"breakpoint main"
#
# NOTE: this prompt is OK only when the annotation level is > 1
# NOTE: When this prompt is in use the gdb_test procedure cannot be used because
# it assumes that the last char after the gdb_prompt is a white space. This is not
# true with this annotated prompt. So we must use send_gdb and gdb_expect.
#
set old_gdb_prompt $gdb_prompt
set gdb_prompt "\r\n\032\032pre-prompt\r\n$gdb_prompt \r\n\032\032prompt\r\n"
2003-07-09 15:19:08 +02:00
#
# Escape all the characters in the path that need it. For instance
# the directory name could contain '+'.
#
set escapedsrcfile [string_to_regexp ${srcdir}/${subdir}/${srcfile}]
1999-05-05 23:45:13 +02:00
#
# set the annotation level to 2
#
# of course, this will test:
# annotate-pre-prompt
# annotate-prompt
# annotate-post-prompt (in the next block)
#
send_gdb "set annotate 2\n"
gdb_expect {
-re "set annotate 2\r\n$gdb_prompt$" { pass "annotation set at level 2" }
-re ".*$gdb_prompt$" { fail "annotation set at level 2" }
timeout { fail "annotation set at level 2 (timeout)" }
}
#
# info break will test:
# annotate-breakpoints-headers
# annotate-field
# annotate-breakpoints-table
# annotate-record
# annotate-breakpoints-table-end
#
2010-05-26 20:05:25 +02:00
gdb_test_multiple "info break" "breakpoint info" {
-re "\r\n\032\032post-prompt\r\n\r\n\032\032breakpoints-headers\r\n\r\n\032\032field 0\r\nNum \r\n\032\032field 1\r\nType \r\n\032\032field 2\r\nDisp \r\n\032\032field 3\r\nEnb \r\n\032\032field 4\r\nAddress +\r\n\032\032field 5\r\nWhat\r\n\r\n\032\032breakpoints-table\r\n\r\n\032\032record\r\n\r\n\032\032field 0\r\n1 \r\n\032\032field 1\r\nbreakpoint \r\n\032\032field 2\r\nkeep \r\n\032\032field 3\r\ny \r\n\032\032field 4\r\n$hex +\r\n\032\032field 5\r\nin main at ${escapedsrcfile}:$main_line\r\n\r\n\032\032breakpoints-table-end\r\n$gdb_prompt$" {
pass "breakpoint info"
}
-re "\r\n\032\032post-prompt\r\n\r\n\032\032breakpoints-headers\r\n\r\n\032\032field 0\r\nNum \r\n\032\032field 1\r\nType \r\n\032\032field 2\r\nDisp \r\n\032\032field 3\r\nEnb \r\n\032\032field 4\r\nAddress +\r\n\032\032field 5\r\nWhat\r\n\r\n\032\032breakpoints-table\r\n\r\n\032\032record\r\n\r\n\032\032field 0\r\n1 \r\n\032\032field 1\r\nbreakpoint \r\n\032\032field 2\r\nkeep \r\n\032\032field 3\r\ny \r\n\032\032field 4\r\n$hex +\r\n\032\032field 5\r\nin main at .*${srcfile}:$main_line\r\n\r\n\032\032breakpoints-table-end\r\n$gdb_prompt$" {
setup_xfail "*-*-*" 1270
fail "breakpoint info"
}
1999-05-05 23:45:13 +02:00
}
#
# run to a break point will test:
# annotate-frames-invalid
# annotate-breakpoints-invalid (a.k.a. breakpoints-changed)
# annotate-starting
# annotate-breakpoint
# annotate-frame-begin
# annotate-frame-function-name
# annotate-frame-args
# annotate-frame-source-begin
# annotate-frame-source-file
# annotate-frame-source-file-end
# annotate-frame-source-line
# annotate-frame-source-end
# annotate-source
# annotate-frame-end
# annotate-stopped
#
1999-05-25 20:09:09 +02:00
#exp_internal 1
2006-10-12 21:03:22 +02:00
set binexp [string_to_regexp $binfile]
2010-05-26 20:05:25 +02:00
gdb_test_multiple "run" "run until main breakpoint" {
2012-08-02 17:59:59 +02:00
-re "\r\n\032\032post-prompt\r\nStarting program: $binexp \(\r\nwarning: Skipping \[^\r\n\]+ .gdb_index section in \[^\r\n\]+\r\nDo \"set use-deprecated-index-sections on\" before the file is read\r\nto use the section anyway\\.\)?\(\(\r\n\r\n\032\032frames-invalid\)|\(\r\n\r\n\032\032breakpoints-invalid\)\)*\r\n\r\n\032\032starting\(\(\r\n\r\n\032\032frames-invalid\)|\(\r\n\r\n\032\032breakpoints-invalid\)\)*\r\n\r\n\032\032breakpoint 1\r\n\r\nBreakpoint 1, \r\n\032\032frame-begin 0 $hex\r\n\r\n\032\032frame-function-name\r\nmain\r\n\032\032frame-args\r\n \\(\\)\r\n\032\032frame-source-begin\r\n at \r\n\032\032frame-source-file\r\n.*annota1.c\r\n\032\032frame-source-file-end\r\n:\r\n\032\032frame-source-line\r\n$main_line\r\n\032\032frame-source-end\r\n\r\n\r\n\032\032source.*$srcfile:$main_line:.*:beg:$hex\r\n\r\n\032\032frame-end\r\n\r\n\032\032stopped.*$gdb_prompt$" {
2000-06-12 22:34:00 +02:00
pass "run until main breakpoint"
}
2010-05-26 20:05:25 +02:00
}
1999-05-25 20:09:09 +02:00
#exp_internal 0
#exit 0
1999-05-05 23:45:13 +02:00
#
# Let's do a next, to get to a point where the array is initialized
# We don't care about the annotated output for this operation, it is the same as
# the one produced by run above
#
2010-05-26 20:05:25 +02:00
gdb_test_multiple "next" "go after array init line" {
-re "source .*annota1.c.*$gdb_prompt$" {
pass "go after array init line"
}
1999-05-05 23:45:13 +02:00
}
#
# printing the array will test:
# annotate-value-history-begin
# annotate-value-history-value
# annotate-array-section-begin
# annotate-elt
# FIXME: annotate-elt-rep and annotate-elt-rep-end not tested
# annotate-array-section-end
# annotate-value-history-end
# FIXME: annotate-value-begin and annotate-value-end not tested (the gdb output
# command would cause them to be used)
#
2010-05-26 20:05:25 +02:00
gdb_test_multiple "print my_array" "print array" {
-re "\r\n\032\032post-prompt\r\n\r\n\032\032value-history-begin 1 -\r\n.*= \r\n\032\032value-history-value\r\n.\r\n\032\032array-section-begin 0 -\r\n1\r\n\032\032elt\r\n, 2\r\n\032\032elt\r\n, 3\r\n\032\032elt\r\n\r\n\032\032array-section-end\r\n.\r\n\r\n\032\032value-history-end\r\n$gdb_prompt$" {
pass "print array"
}
1999-05-05 23:45:13 +02:00
}
#
# this should generate an error message, so to test:
# annotate-error-begin
# FIXME: annotate-error not tested
#
#exp_internal 1
2010-05-26 20:05:25 +02:00
gdb_test_multiple "print non_existent_value" "print non_existent_value" {
-re "\r\n\032\032post-prompt\r\n\r\n\032\032error-begin\r\nNo symbol \"non_existent_value\" in current context.\r\n\r\n\032\032error\r\n$gdb_prompt$" {
pass "print non_existent_value"
}
1999-05-05 23:45:13 +02:00
}
#
# break at signal handler. So that, once we are in the sig handler, if we do a bt
# we can test annotate-signal-handler-caller
#
2010-05-26 20:05:25 +02:00
gdb_test_multiple "break handle_USR1" "break handle_USR1" {
All annotate_breakpoints_changed calls are along-side
observer_notify_breakpoints_changed calls. All, except the
init_raw_breakpoint one. But that one is actually wrong. The
breakpoint is being constructed at that point, and hasn't been placed
on the breakpoint chain yet. It would be better placed in
install_breakpoint, and I actually started out that way. But once the
annotate_breakpoints_changed are parallel to the observer calls, we
can fully move annotations to observers too.
One issue is that this changes the order of annotations a bit.
Before, we'd emit the annotation, and after call "mention()" on the
breakpoint (which prints the breakpoint number, etc.). But, we call
the observers _after_ mention is called, so the annotation output will
change a little:
void
install_breakpoint (int internal, struct breakpoint *b, int update_gll)
{
add_to_breakpoint_chain (b);
set_breakpoint_number (internal, b);
if (is_tracepoint (b))
set_tracepoint_count (breakpoint_count);
if (!internal)
mention (b);
observer_notify_breakpoint_created (b);
if (update_gll)
update_global_location_list (1);
}
I believe this order doesn't really matter (the frontend needs to wait
for the prompt anyway), so I just adjust the expected output in the
tests. Emacs in annotations mode doesn't seem to complain. Couple
that with the previous patch that suppressed duplicated annotations,
and, the fact that some annotations calls were actually missing (were
we do have observer calls), more changes to the tests are needed
anyway.
Tested on x86_64 Fedora 17.
gdb/
2013-01-22 Pedro Alves <palves@redhat.com>
* annotate.c (annotate_breakpoints_changed): Rename to ...
(annotate_breakpoints_invalid): ... this. Make static.
(breakpoint_changed): Adjust.
(_initialize_annotate): Always install the observers. Install a
"breakpoint_created" observer.
* annotate.h (annotate_breakpoints_changed): Delete declaration.
* breakpoint.c (set_breakpoint_condition)
(breakpoint_set_commands, do_map_commands_command)
(init_raw_breakpoint, clear_command, set_ignore_count)
(enable_breakpoint_disp): No longer call
annotate_breakpoints_changed.
gdb/testsuite/
2013-01-22 Pedro Alves <palves@redhat.com>
* gdb.base/annota1.exp (breakpoints_invalid): New variable.
Adjust tests to breakpoints-invalid changes.
* gdb.cp/annota2.exp (breakpoints_invalid, frames_invalid): New
variables.
Adjust tests to breakpoints-invalid changes.
2013-01-22 21:19:40 +01:00
-re "\r\n\032\032post-prompt\r\nBreakpoint.*at $hex: file.*$srcfile, line.*\r\n\032\032breakpoints-invalid\r\n.*$gdb_prompt$" {
2010-05-26 20:05:25 +02:00
pass "break handle_USR1"
}
1999-05-05 23:45:13 +02:00
}
#
# break at printf. When we are stopped at printf, we can test
#
2010-05-26 20:05:25 +02:00
gdb_test_multiple "break printf" "break printf" {
All annotate_breakpoints_changed calls are along-side
observer_notify_breakpoints_changed calls. All, except the
init_raw_breakpoint one. But that one is actually wrong. The
breakpoint is being constructed at that point, and hasn't been placed
on the breakpoint chain yet. It would be better placed in
install_breakpoint, and I actually started out that way. But once the
annotate_breakpoints_changed are parallel to the observer calls, we
can fully move annotations to observers too.
One issue is that this changes the order of annotations a bit.
Before, we'd emit the annotation, and after call "mention()" on the
breakpoint (which prints the breakpoint number, etc.). But, we call
the observers _after_ mention is called, so the annotation output will
change a little:
void
install_breakpoint (int internal, struct breakpoint *b, int update_gll)
{
add_to_breakpoint_chain (b);
set_breakpoint_number (internal, b);
if (is_tracepoint (b))
set_tracepoint_count (breakpoint_count);
if (!internal)
mention (b);
observer_notify_breakpoint_created (b);
if (update_gll)
update_global_location_list (1);
}
I believe this order doesn't really matter (the frontend needs to wait
for the prompt anyway), so I just adjust the expected output in the
tests. Emacs in annotations mode doesn't seem to complain. Couple
that with the previous patch that suppressed duplicated annotations,
and, the fact that some annotations calls were actually missing (were
we do have observer calls), more changes to the tests are needed
anyway.
Tested on x86_64 Fedora 17.
gdb/
2013-01-22 Pedro Alves <palves@redhat.com>
* annotate.c (annotate_breakpoints_changed): Rename to ...
(annotate_breakpoints_invalid): ... this. Make static.
(breakpoint_changed): Adjust.
(_initialize_annotate): Always install the observers. Install a
"breakpoint_created" observer.
* annotate.h (annotate_breakpoints_changed): Delete declaration.
* breakpoint.c (set_breakpoint_condition)
(breakpoint_set_commands, do_map_commands_command)
(init_raw_breakpoint, clear_command, set_ignore_count)
(enable_breakpoint_disp): No longer call
annotate_breakpoints_changed.
gdb/testsuite/
2013-01-22 Pedro Alves <palves@redhat.com>
* gdb.base/annota1.exp (breakpoints_invalid): New variable.
Adjust tests to breakpoints-invalid changes.
* gdb.cp/annota2.exp (breakpoints_invalid, frames_invalid): New
variables.
Adjust tests to breakpoints-invalid changes.
2013-01-22 21:19:40 +01:00
-re "\r\n\032\032post-prompt\r\nBreakpoint.*at $hex.*\032\032breakpoints-invalid\r\n.*$gdb_prompt$" {
2010-05-26 20:05:25 +02:00
pass "break printf"
}
-re "\r\n\032\032post-prompt\r\nwarning: Breakpoint address adjusted from $hex to $hex.\r\n\r\n\032\032breakpoints-invalid\r\nBreakpoint.*at $hex.*$gdb_prompt$" {
pass "break printf"
}
1999-05-05 23:45:13 +02:00
}
#
# get to printf
#
All annotate_breakpoints_changed calls are along-side
observer_notify_breakpoints_changed calls. All, except the
init_raw_breakpoint one. But that one is actually wrong. The
breakpoint is being constructed at that point, and hasn't been placed
on the breakpoint chain yet. It would be better placed in
install_breakpoint, and I actually started out that way. But once the
annotate_breakpoints_changed are parallel to the observer calls, we
can fully move annotations to observers too.
One issue is that this changes the order of annotations a bit.
Before, we'd emit the annotation, and after call "mention()" on the
breakpoint (which prints the breakpoint number, etc.). But, we call
the observers _after_ mention is called, so the annotation output will
change a little:
void
install_breakpoint (int internal, struct breakpoint *b, int update_gll)
{
add_to_breakpoint_chain (b);
set_breakpoint_number (internal, b);
if (is_tracepoint (b))
set_tracepoint_count (breakpoint_count);
if (!internal)
mention (b);
observer_notify_breakpoint_created (b);
if (update_gll)
update_global_location_list (1);
}
I believe this order doesn't really matter (the frontend needs to wait
for the prompt anyway), so I just adjust the expected output in the
tests. Emacs in annotations mode doesn't seem to complain. Couple
that with the previous patch that suppressed duplicated annotations,
and, the fact that some annotations calls were actually missing (were
we do have observer calls), more changes to the tests are needed
anyway.
Tested on x86_64 Fedora 17.
gdb/
2013-01-22 Pedro Alves <palves@redhat.com>
* annotate.c (annotate_breakpoints_changed): Rename to ...
(annotate_breakpoints_invalid): ... this. Make static.
(breakpoint_changed): Adjust.
(_initialize_annotate): Always install the observers. Install a
"breakpoint_created" observer.
* annotate.h (annotate_breakpoints_changed): Delete declaration.
* breakpoint.c (set_breakpoint_condition)
(breakpoint_set_commands, do_map_commands_command)
(init_raw_breakpoint, clear_command, set_ignore_count)
(enable_breakpoint_disp): No longer call
annotate_breakpoints_changed.
gdb/testsuite/
2013-01-22 Pedro Alves <palves@redhat.com>
* gdb.base/annota1.exp (breakpoints_invalid): New variable.
Adjust tests to breakpoints-invalid changes.
* gdb.cp/annota2.exp (breakpoints_invalid, frames_invalid): New
variables.
Adjust tests to breakpoints-invalid changes.
2013-01-22 21:19:40 +01:00
set pat_begin "\r\n\032\032post-prompt\r\nContinuing.\r\n\r\n\032\032starting\r\n\r\n\032\032frames-invalid\r\n${breakpoints_invalid}"
2006-12-31 21:01:25 +01:00
set pat_adjust "warning: Breakpoint 3 address previously adjusted from $hex to $hex.\r\n"
2008-05-16 14:48:08 +02:00
set pat_end "\r\n\032\032breakpoint 3\r\n\r\nBreakpoint 3, \r\n\032\032frame-begin 0 $hex\r\n\r\n(\032\032frame-address\r\n$hex\r\n\032\032frame-address-end\r\n in \r\n)*.*\032\032frame-function-name\r\n.*printf(@.*)?\r\n\032\032frame-args\r\n.*\032\032frame-end\r\n\r\n\032\032stopped\r\n$gdb_prompt$"
2005-04-27 23:45:16 +02:00
2006-12-31 21:01:25 +01:00
gdb_test_multiple "continue" "continue to printf" {
-re "${pat_begin}($pat_adjust)?$pat_end" {
pass "continue to printf"
}
-re ".*$gdb_prompt$" { fail "continue to printf" }
1999-05-05 23:45:13 +02:00
}
#
# test:
# annotate-frame-where
# annotate-frame-address
# annotate-frame-address-end
#
2008-05-16 14:48:08 +02:00
set pat_begin "\r\n\032\032post-prompt\r\n\r\n\032\032frame-begin 0 $hex\r\n.0 \r\n(\032\032frame-address\r\n$hex\r\n\032\032frame-address-end\r\n in \r\n)*\032\032frame-function-name\r\n.*printf(@.*)?\r\n\032\032frame-args\r\n \\(.*frame-end\r\n\r\n\032\032frame-begin 1 $hex\r\n.1 \r\n\032\032frame-address\r\n$hex\r\n\032\032frame-address-end\r\n in \r\n\032\032frame-function-name\r\nmain\r\n\032\032frame-args\r\n \\(\\)\r\n\032\032frame-source-begin\r\n at \r\n\032\032frame-source-file\r\n"
2010-05-26 20:05:25 +02:00
2006-12-31 21:01:25 +01:00
set pat_end "\r\n\032\032frame-source-file-end\r\n:\r\n\032\032frame-source-line\r\n.*\r\n\032\032frame-source-end\r\n\r\n\r\n\032\032frame-end\r\n(\r\n\032\032frame-begin .*\r\n\r\n\032\032frame-end\r\n)*$gdb_prompt$"
2010-05-26 20:05:25 +02:00
gdb_test_multiple "backtrace" "backtrace from shlibrary" {
-re "$pat_begin$escapedsrcfile$pat_end" {
pass "backtrace from shlibrary"
}
-re "$pat_begin.*$srcfile$pat_end" {
setup_xfail "*-*-*" 1270
fail "backtrace from shlibrary"
}
1999-05-05 23:45:13 +02:00
}
#
# test printing a frame with some arguments:
# annotate-arg-begin
# annotate-arg-name-end
# annotate-arg-value
# annotate-arg-end
#
2004-07-20 02:24:41 +02:00
if [target_info exists gdb,nosignals] {
unsupported "send SIGUSR1"
unsupported "backtrace @ signal handler"
} else {
2010-05-26 20:05:25 +02:00
gdb_test_multiple "signal SIGUSR1" "send SIGUSR1" {
2011-04-27 19:08:42 +02:00
-re "\r\n\032\032post-prompt\r\nContinuing with signal SIGUSR1.\r\n\r\n\032\032starting\(\(\r\n\r\n\032\032frames-invalid\)|\(\r\n\r\n\032\032breakpoints-invalid\)\)+\r\n\r\n\032\032breakpoint 2\r\n\r\nBreakpoint 2, \r\n\032\032frame-begin 0 $hex\r\n\r\n\032\032frame-function-name\r\nhandle_USR1\r\n\032\032frame-args\r\n \\(\r\n\032\032arg-begin\r\nsig\r\n\032\032arg-name-end\r\n=\r\n\032\032arg-value -\r\n$decimal\r\n\032\032arg-end\r\n\\)\r\n\032\032frame-source-begin\r\n at \r\n\032\032frame-source-file\r\n${escapedsrcfile}\r\n\032\032frame-source-file-end\r\n:\r\n\032\032frame-source-line\r\n.*\r\n\032\032frame-source-end\r\n\r\n\r\n\032\032source.*annota1.c:.*:.*:beg:$hex\r\n\r\n\032\032frame-end\r\n\r\n\032\032stopped\r\n$gdb_prompt$" {
2010-05-26 20:05:25 +02:00
pass "send SIGUSR1"
}
2011-04-27 19:08:42 +02:00
-re "\r\n\032\032post-prompt\r\nContinuing with signal SIGUSR1.\r\n\r\n\032\032starting\(\(\r\n\r\n\032\032frames-invalid\)|\(\r\n\r\n\032\032breakpoints-invalid\)\)+\r\n\r\n\032\032breakpoint 2\r\n\r\nBreakpoint 2, \r\n\032\032frame-begin 0 $hex\r\n\r\n\032\032frame-function-name\r\nhandle_USR1\r\n\032\032frame-args\r\n \\(\r\n\032\032arg-begin\r\nsig\r\n\032\032arg-name-end\r\n=\r\n\032\032arg-value -\r\n$decimal\r\n\032\032arg-end\r\n\\)\r\n\032\032frame-source-begin\r\n at \r\n\032\032frame-source-file\r\n.*${srcfile}\r\n\032\032frame-source-file-end\r\n:\r\n\032\032frame-source-line\r\n.*\r\n\032\032frame-source-end\r\n\r\n\r\n\032\032source.*annota1.c:.*:.*:beg:$hex\r\n\r\n\032\032frame-end\r\n\r\n\032\032stopped\r\n$gdb_prompt$" {
2010-05-26 20:05:25 +02:00
setup_xfail "*-*-*" 1270
fail "send SIGUSR1"
}
2004-07-20 02:24:41 +02:00
}
1999-05-05 23:45:13 +02:00
2004-07-20 02:24:41 +02:00
#
# test:
# annotate-signal-handler-caller
#
2010-05-26 20:05:25 +02:00
gdb_test_multiple "backtrace" "backtrace @ signal handler" {
2004-07-20 02:24:41 +02:00
-re "frame-begin 0 $hex\r\n#0.*frame-end.*frame-begin 1 $hex\r\n#1.*(\032\032signal-handler-caller\r\n.signal handler called.\r\n\r\n)+\032\032frame-end\r\n\r\n\032\032frame-begin 2 $hex\r\n#2.*(frame-begin 3 $hex\r\n#3.*)*frame-end.*$gdb_prompt$" {
pass "backtrace @ signal handler"
}
2000-05-24 19:14:50 +02:00
}
1999-05-05 23:45:13 +02:00
}
#
# delete all the breakpoints
#
2010-05-26 20:05:25 +02:00
gdb_test_multiple "delete 1" "delete bp 1" {
All annotate_breakpoints_changed calls are along-side
observer_notify_breakpoints_changed calls. All, except the
init_raw_breakpoint one. But that one is actually wrong. The
breakpoint is being constructed at that point, and hasn't been placed
on the breakpoint chain yet. It would be better placed in
install_breakpoint, and I actually started out that way. But once the
annotate_breakpoints_changed are parallel to the observer calls, we
can fully move annotations to observers too.
One issue is that this changes the order of annotations a bit.
Before, we'd emit the annotation, and after call "mention()" on the
breakpoint (which prints the breakpoint number, etc.). But, we call
the observers _after_ mention is called, so the annotation output will
change a little:
void
install_breakpoint (int internal, struct breakpoint *b, int update_gll)
{
add_to_breakpoint_chain (b);
set_breakpoint_number (internal, b);
if (is_tracepoint (b))
set_tracepoint_count (breakpoint_count);
if (!internal)
mention (b);
observer_notify_breakpoint_created (b);
if (update_gll)
update_global_location_list (1);
}
I believe this order doesn't really matter (the frontend needs to wait
for the prompt anyway), so I just adjust the expected output in the
tests. Emacs in annotations mode doesn't seem to complain. Couple
that with the previous patch that suppressed duplicated annotations,
and, the fact that some annotations calls were actually missing (were
we do have observer calls), more changes to the tests are needed
anyway.
Tested on x86_64 Fedora 17.
gdb/
2013-01-22 Pedro Alves <palves@redhat.com>
* annotate.c (annotate_breakpoints_changed): Rename to ...
(annotate_breakpoints_invalid): ... this. Make static.
(breakpoint_changed): Adjust.
(_initialize_annotate): Always install the observers. Install a
"breakpoint_created" observer.
* annotate.h (annotate_breakpoints_changed): Delete declaration.
* breakpoint.c (set_breakpoint_condition)
(breakpoint_set_commands, do_map_commands_command)
(init_raw_breakpoint, clear_command, set_ignore_count)
(enable_breakpoint_disp): No longer call
annotate_breakpoints_changed.
gdb/testsuite/
2013-01-22 Pedro Alves <palves@redhat.com>
* gdb.base/annota1.exp (breakpoints_invalid): New variable.
Adjust tests to breakpoints-invalid changes.
* gdb.cp/annota2.exp (breakpoints_invalid, frames_invalid): New
variables.
Adjust tests to breakpoints-invalid changes.
2013-01-22 21:19:40 +01:00
-re "\r\n\032\032post-prompt\r\n${breakpoints_invalid}$gdb_prompt$" {
2010-05-26 20:05:25 +02:00
pass "delete bp 1"
}
1999-05-05 23:45:13 +02:00
}
2010-05-26 20:05:25 +02:00
gdb_test_multiple "delete 2" "delete bp 2" {
All annotate_breakpoints_changed calls are along-side
observer_notify_breakpoints_changed calls. All, except the
init_raw_breakpoint one. But that one is actually wrong. The
breakpoint is being constructed at that point, and hasn't been placed
on the breakpoint chain yet. It would be better placed in
install_breakpoint, and I actually started out that way. But once the
annotate_breakpoints_changed are parallel to the observer calls, we
can fully move annotations to observers too.
One issue is that this changes the order of annotations a bit.
Before, we'd emit the annotation, and after call "mention()" on the
breakpoint (which prints the breakpoint number, etc.). But, we call
the observers _after_ mention is called, so the annotation output will
change a little:
void
install_breakpoint (int internal, struct breakpoint *b, int update_gll)
{
add_to_breakpoint_chain (b);
set_breakpoint_number (internal, b);
if (is_tracepoint (b))
set_tracepoint_count (breakpoint_count);
if (!internal)
mention (b);
observer_notify_breakpoint_created (b);
if (update_gll)
update_global_location_list (1);
}
I believe this order doesn't really matter (the frontend needs to wait
for the prompt anyway), so I just adjust the expected output in the
tests. Emacs in annotations mode doesn't seem to complain. Couple
that with the previous patch that suppressed duplicated annotations,
and, the fact that some annotations calls were actually missing (were
we do have observer calls), more changes to the tests are needed
anyway.
Tested on x86_64 Fedora 17.
gdb/
2013-01-22 Pedro Alves <palves@redhat.com>
* annotate.c (annotate_breakpoints_changed): Rename to ...
(annotate_breakpoints_invalid): ... this. Make static.
(breakpoint_changed): Adjust.
(_initialize_annotate): Always install the observers. Install a
"breakpoint_created" observer.
* annotate.h (annotate_breakpoints_changed): Delete declaration.
* breakpoint.c (set_breakpoint_condition)
(breakpoint_set_commands, do_map_commands_command)
(init_raw_breakpoint, clear_command, set_ignore_count)
(enable_breakpoint_disp): No longer call
annotate_breakpoints_changed.
gdb/testsuite/
2013-01-22 Pedro Alves <palves@redhat.com>
* gdb.base/annota1.exp (breakpoints_invalid): New variable.
Adjust tests to breakpoints-invalid changes.
* gdb.cp/annota2.exp (breakpoints_invalid, frames_invalid): New
variables.
Adjust tests to breakpoints-invalid changes.
2013-01-22 21:19:40 +01:00
-re "\r\n\032\032post-prompt\r\n${breakpoints_invalid}$gdb_prompt$" {
2010-05-26 20:05:25 +02:00
pass "delete bp 2"
}
1999-05-05 23:45:13 +02:00
}
2010-05-26 20:05:25 +02:00
gdb_test_multiple "delete 3" "delete bp 3" {
All annotate_breakpoints_changed calls are along-side
observer_notify_breakpoints_changed calls. All, except the
init_raw_breakpoint one. But that one is actually wrong. The
breakpoint is being constructed at that point, and hasn't been placed
on the breakpoint chain yet. It would be better placed in
install_breakpoint, and I actually started out that way. But once the
annotate_breakpoints_changed are parallel to the observer calls, we
can fully move annotations to observers too.
One issue is that this changes the order of annotations a bit.
Before, we'd emit the annotation, and after call "mention()" on the
breakpoint (which prints the breakpoint number, etc.). But, we call
the observers _after_ mention is called, so the annotation output will
change a little:
void
install_breakpoint (int internal, struct breakpoint *b, int update_gll)
{
add_to_breakpoint_chain (b);
set_breakpoint_number (internal, b);
if (is_tracepoint (b))
set_tracepoint_count (breakpoint_count);
if (!internal)
mention (b);
observer_notify_breakpoint_created (b);
if (update_gll)
update_global_location_list (1);
}
I believe this order doesn't really matter (the frontend needs to wait
for the prompt anyway), so I just adjust the expected output in the
tests. Emacs in annotations mode doesn't seem to complain. Couple
that with the previous patch that suppressed duplicated annotations,
and, the fact that some annotations calls were actually missing (were
we do have observer calls), more changes to the tests are needed
anyway.
Tested on x86_64 Fedora 17.
gdb/
2013-01-22 Pedro Alves <palves@redhat.com>
* annotate.c (annotate_breakpoints_changed): Rename to ...
(annotate_breakpoints_invalid): ... this. Make static.
(breakpoint_changed): Adjust.
(_initialize_annotate): Always install the observers. Install a
"breakpoint_created" observer.
* annotate.h (annotate_breakpoints_changed): Delete declaration.
* breakpoint.c (set_breakpoint_condition)
(breakpoint_set_commands, do_map_commands_command)
(init_raw_breakpoint, clear_command, set_ignore_count)
(enable_breakpoint_disp): No longer call
annotate_breakpoints_changed.
gdb/testsuite/
2013-01-22 Pedro Alves <palves@redhat.com>
* gdb.base/annota1.exp (breakpoints_invalid): New variable.
Adjust tests to breakpoints-invalid changes.
* gdb.cp/annota2.exp (breakpoints_invalid, frames_invalid): New
variables.
Adjust tests to breakpoints-invalid changes.
2013-01-22 21:19:40 +01:00
-re "\r\n\032\032post-prompt\r\n${breakpoints_invalid}$gdb_prompt$" {
2010-05-26 20:05:25 +02:00
pass "delete bp 3"
}
1999-05-05 23:45:13 +02:00
}
#
Fix fail in gdb.base/annota1.exp and gdb.base/annota3.exp
Hi,
I am seeing the fail below on aarch64-linux with gcc 4.9.2,
break main
Breakpoint 1 at 0x4006e8: file binutils-gdb/gdb/testsuite/gdb.base/annota1.c, line 14.^M
(gdb) FAIL: gdb.base/annota1.exp: breakpoint main
the test expects the breakpoint is set on line 15. Let us look at
the main function,
12 int
13 main (void)
14 {
15 int my_array[3] = { 1, 2, 3 }; /* break main */
16
17 value = 7;
18
19 #ifdef SIGUSR1
20 signal (SIGUSR1, handle_USR1);
21 #endif
(gdb) disassemble main
Dump of assembler code for function main:
0x00000000004006e0 <+0>: stp x29, x30, [sp,#-48]!
0x00000000004006e4 <+4>: mov x29, sp
0x00000000004006e8 <+8>: adrp x0, 0x411000 <signal@got.plt>
0x00000000004006ec <+12>: add x0, x0, #0x40
the breakpoint is set on the right address after skipping prologue, but
0x00000000004006e8 is mapped to the line 14, as shown below,
(gdb) maintenance info line-table
objfile: /home/yao.qi/source/build-aarch64/gdb/testsuite/outputs/gdb.base/annota1/annota1 ((struct objfile *) 0x2b0e1850)
compunit_symtab: ((struct compunit_symtab *) 0x2b0ded50)
symtab: /home/yao.qi/source/binutils-gdb/gdb/testsuite/gdb.base/annota1.c ((struct symtab *) 0x2b0dedd0)
linetable: ((struct linetable *) 0x2b12c8b0):
INDEX LINE ADDRESS
0 7 0x00000000004006d0
1 8 0x00000000004006d8
2 14 0x00000000004006e0
3 14 0x00000000004006e8
4 15 0x00000000004006fc
so GDB does nothing wrong. Program hits breakpoint on either line 14
or line 15 is right to me. With anther gcc (4.9.3), the line-table looks
correct, and no test fail. Instead of setting breakpoint on main and
assuming the line is what we get from the source, we can set breakpoint
on that line. On the other hand, the test prints the values of the
array and check, so we need to set breakpoint on the line setting the
values of array and "next", rather than setting the breakpoint on main.
gdb/testsuite:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* gdb.base/annota1.exp: Set breakpoint on line $main_line.
* gdb.base/annota3.exp: Likewise.
2016-04-22 16:35:07 +02:00
# break in main, after value is initialized. This is in preparation
1999-05-05 23:45:13 +02:00
# to test the annotate output for the display command.
#
Fix fail in gdb.base/annota1.exp and gdb.base/annota3.exp
Hi,
I am seeing the fail below on aarch64-linux with gcc 4.9.2,
break main
Breakpoint 1 at 0x4006e8: file binutils-gdb/gdb/testsuite/gdb.base/annota1.c, line 14.^M
(gdb) FAIL: gdb.base/annota1.exp: breakpoint main
the test expects the breakpoint is set on line 15. Let us look at
the main function,
12 int
13 main (void)
14 {
15 int my_array[3] = { 1, 2, 3 }; /* break main */
16
17 value = 7;
18
19 #ifdef SIGUSR1
20 signal (SIGUSR1, handle_USR1);
21 #endif
(gdb) disassemble main
Dump of assembler code for function main:
0x00000000004006e0 <+0>: stp x29, x30, [sp,#-48]!
0x00000000004006e4 <+4>: mov x29, sp
0x00000000004006e8 <+8>: adrp x0, 0x411000 <signal@got.plt>
0x00000000004006ec <+12>: add x0, x0, #0x40
the breakpoint is set on the right address after skipping prologue, but
0x00000000004006e8 is mapped to the line 14, as shown below,
(gdb) maintenance info line-table
objfile: /home/yao.qi/source/build-aarch64/gdb/testsuite/outputs/gdb.base/annota1/annota1 ((struct objfile *) 0x2b0e1850)
compunit_symtab: ((struct compunit_symtab *) 0x2b0ded50)
symtab: /home/yao.qi/source/binutils-gdb/gdb/testsuite/gdb.base/annota1.c ((struct symtab *) 0x2b0dedd0)
linetable: ((struct linetable *) 0x2b12c8b0):
INDEX LINE ADDRESS
0 7 0x00000000004006d0
1 8 0x00000000004006d8
2 14 0x00000000004006e0
3 14 0x00000000004006e8
4 15 0x00000000004006fc
so GDB does nothing wrong. Program hits breakpoint on either line 14
or line 15 is right to me. With anther gcc (4.9.3), the line-table looks
correct, and no test fail. Instead of setting breakpoint on main and
assuming the line is what we get from the source, we can set breakpoint
on that line. On the other hand, the test prints the values of the
array and check, so we need to set breakpoint on the line setting the
values of array and "next", rather than setting the breakpoint on main.
gdb/testsuite:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* gdb.base/annota1.exp: Set breakpoint on line $main_line.
* gdb.base/annota3.exp: Likewise.
2016-04-22 16:35:07 +02:00
set test "break in main"
gdb_test_multiple "break ${srcfile}:${main_line}" $test {
All annotate_breakpoints_changed calls are along-side
observer_notify_breakpoints_changed calls. All, except the
init_raw_breakpoint one. But that one is actually wrong. The
breakpoint is being constructed at that point, and hasn't been placed
on the breakpoint chain yet. It would be better placed in
install_breakpoint, and I actually started out that way. But once the
annotate_breakpoints_changed are parallel to the observer calls, we
can fully move annotations to observers too.
One issue is that this changes the order of annotations a bit.
Before, we'd emit the annotation, and after call "mention()" on the
breakpoint (which prints the breakpoint number, etc.). But, we call
the observers _after_ mention is called, so the annotation output will
change a little:
void
install_breakpoint (int internal, struct breakpoint *b, int update_gll)
{
add_to_breakpoint_chain (b);
set_breakpoint_number (internal, b);
if (is_tracepoint (b))
set_tracepoint_count (breakpoint_count);
if (!internal)
mention (b);
observer_notify_breakpoint_created (b);
if (update_gll)
update_global_location_list (1);
}
I believe this order doesn't really matter (the frontend needs to wait
for the prompt anyway), so I just adjust the expected output in the
tests. Emacs in annotations mode doesn't seem to complain. Couple
that with the previous patch that suppressed duplicated annotations,
and, the fact that some annotations calls were actually missing (were
we do have observer calls), more changes to the tests are needed
anyway.
Tested on x86_64 Fedora 17.
gdb/
2013-01-22 Pedro Alves <palves@redhat.com>
* annotate.c (annotate_breakpoints_changed): Rename to ...
(annotate_breakpoints_invalid): ... this. Make static.
(breakpoint_changed): Adjust.
(_initialize_annotate): Always install the observers. Install a
"breakpoint_created" observer.
* annotate.h (annotate_breakpoints_changed): Delete declaration.
* breakpoint.c (set_breakpoint_condition)
(breakpoint_set_commands, do_map_commands_command)
(init_raw_breakpoint, clear_command, set_ignore_count)
(enable_breakpoint_disp): No longer call
annotate_breakpoints_changed.
gdb/testsuite/
2013-01-22 Pedro Alves <palves@redhat.com>
* gdb.base/annota1.exp (breakpoints_invalid): New variable.
Adjust tests to breakpoints-invalid changes.
* gdb.cp/annota2.exp (breakpoints_invalid, frames_invalid): New
variables.
Adjust tests to breakpoints-invalid changes.
2013-01-22 21:19:40 +01:00
-re "post-prompt.*Breakpoint 4 at $hex: file ${escapedsrcfile}, line $main_line.*\032\032breakpoints-invalid.*$gdb_prompt$" {
Fix fail in gdb.base/annota1.exp and gdb.base/annota3.exp
Hi,
I am seeing the fail below on aarch64-linux with gcc 4.9.2,
break main
Breakpoint 1 at 0x4006e8: file binutils-gdb/gdb/testsuite/gdb.base/annota1.c, line 14.^M
(gdb) FAIL: gdb.base/annota1.exp: breakpoint main
the test expects the breakpoint is set on line 15. Let us look at
the main function,
12 int
13 main (void)
14 {
15 int my_array[3] = { 1, 2, 3 }; /* break main */
16
17 value = 7;
18
19 #ifdef SIGUSR1
20 signal (SIGUSR1, handle_USR1);
21 #endif
(gdb) disassemble main
Dump of assembler code for function main:
0x00000000004006e0 <+0>: stp x29, x30, [sp,#-48]!
0x00000000004006e4 <+4>: mov x29, sp
0x00000000004006e8 <+8>: adrp x0, 0x411000 <signal@got.plt>
0x00000000004006ec <+12>: add x0, x0, #0x40
the breakpoint is set on the right address after skipping prologue, but
0x00000000004006e8 is mapped to the line 14, as shown below,
(gdb) maintenance info line-table
objfile: /home/yao.qi/source/build-aarch64/gdb/testsuite/outputs/gdb.base/annota1/annota1 ((struct objfile *) 0x2b0e1850)
compunit_symtab: ((struct compunit_symtab *) 0x2b0ded50)
symtab: /home/yao.qi/source/binutils-gdb/gdb/testsuite/gdb.base/annota1.c ((struct symtab *) 0x2b0dedd0)
linetable: ((struct linetable *) 0x2b12c8b0):
INDEX LINE ADDRESS
0 7 0x00000000004006d0
1 8 0x00000000004006d8
2 14 0x00000000004006e0
3 14 0x00000000004006e8
4 15 0x00000000004006fc
so GDB does nothing wrong. Program hits breakpoint on either line 14
or line 15 is right to me. With anther gcc (4.9.3), the line-table looks
correct, and no test fail. Instead of setting breakpoint on main and
assuming the line is what we get from the source, we can set breakpoint
on that line. On the other hand, the test prints the values of the
array and check, so we need to set breakpoint on the line setting the
values of array and "next", rather than setting the breakpoint on main.
gdb/testsuite:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* gdb.base/annota1.exp: Set breakpoint on line $main_line.
* gdb.base/annota3.exp: Likewise.
2016-04-22 16:35:07 +02:00
pass $test
2010-05-26 20:05:25 +02:00
}
All annotate_breakpoints_changed calls are along-side
observer_notify_breakpoints_changed calls. All, except the
init_raw_breakpoint one. But that one is actually wrong. The
breakpoint is being constructed at that point, and hasn't been placed
on the breakpoint chain yet. It would be better placed in
install_breakpoint, and I actually started out that way. But once the
annotate_breakpoints_changed are parallel to the observer calls, we
can fully move annotations to observers too.
One issue is that this changes the order of annotations a bit.
Before, we'd emit the annotation, and after call "mention()" on the
breakpoint (which prints the breakpoint number, etc.). But, we call
the observers _after_ mention is called, so the annotation output will
change a little:
void
install_breakpoint (int internal, struct breakpoint *b, int update_gll)
{
add_to_breakpoint_chain (b);
set_breakpoint_number (internal, b);
if (is_tracepoint (b))
set_tracepoint_count (breakpoint_count);
if (!internal)
mention (b);
observer_notify_breakpoint_created (b);
if (update_gll)
update_global_location_list (1);
}
I believe this order doesn't really matter (the frontend needs to wait
for the prompt anyway), so I just adjust the expected output in the
tests. Emacs in annotations mode doesn't seem to complain. Couple
that with the previous patch that suppressed duplicated annotations,
and, the fact that some annotations calls were actually missing (were
we do have observer calls), more changes to the tests are needed
anyway.
Tested on x86_64 Fedora 17.
gdb/
2013-01-22 Pedro Alves <palves@redhat.com>
* annotate.c (annotate_breakpoints_changed): Rename to ...
(annotate_breakpoints_invalid): ... this. Make static.
(breakpoint_changed): Adjust.
(_initialize_annotate): Always install the observers. Install a
"breakpoint_created" observer.
* annotate.h (annotate_breakpoints_changed): Delete declaration.
* breakpoint.c (set_breakpoint_condition)
(breakpoint_set_commands, do_map_commands_command)
(init_raw_breakpoint, clear_command, set_ignore_count)
(enable_breakpoint_disp): No longer call
annotate_breakpoints_changed.
gdb/testsuite/
2013-01-22 Pedro Alves <palves@redhat.com>
* gdb.base/annota1.exp (breakpoints_invalid): New variable.
Adjust tests to breakpoints-invalid changes.
* gdb.cp/annota2.exp (breakpoints_invalid, frames_invalid): New
variables.
Adjust tests to breakpoints-invalid changes.
2013-01-22 21:19:40 +01:00
-re "post-prompt.*Breakpoint 4 at $hex: file .*${srcfile}, line $main_line.*\032\032breakpoints-invalid.*$gdb_prompt$" {
2010-05-26 20:05:25 +02:00
setup_xfail "*-*-*" 1270
Fix fail in gdb.base/annota1.exp and gdb.base/annota3.exp
Hi,
I am seeing the fail below on aarch64-linux with gcc 4.9.2,
break main
Breakpoint 1 at 0x4006e8: file binutils-gdb/gdb/testsuite/gdb.base/annota1.c, line 14.^M
(gdb) FAIL: gdb.base/annota1.exp: breakpoint main
the test expects the breakpoint is set on line 15. Let us look at
the main function,
12 int
13 main (void)
14 {
15 int my_array[3] = { 1, 2, 3 }; /* break main */
16
17 value = 7;
18
19 #ifdef SIGUSR1
20 signal (SIGUSR1, handle_USR1);
21 #endif
(gdb) disassemble main
Dump of assembler code for function main:
0x00000000004006e0 <+0>: stp x29, x30, [sp,#-48]!
0x00000000004006e4 <+4>: mov x29, sp
0x00000000004006e8 <+8>: adrp x0, 0x411000 <signal@got.plt>
0x00000000004006ec <+12>: add x0, x0, #0x40
the breakpoint is set on the right address after skipping prologue, but
0x00000000004006e8 is mapped to the line 14, as shown below,
(gdb) maintenance info line-table
objfile: /home/yao.qi/source/build-aarch64/gdb/testsuite/outputs/gdb.base/annota1/annota1 ((struct objfile *) 0x2b0e1850)
compunit_symtab: ((struct compunit_symtab *) 0x2b0ded50)
symtab: /home/yao.qi/source/binutils-gdb/gdb/testsuite/gdb.base/annota1.c ((struct symtab *) 0x2b0dedd0)
linetable: ((struct linetable *) 0x2b12c8b0):
INDEX LINE ADDRESS
0 7 0x00000000004006d0
1 8 0x00000000004006d8
2 14 0x00000000004006e0
3 14 0x00000000004006e8
4 15 0x00000000004006fc
so GDB does nothing wrong. Program hits breakpoint on either line 14
or line 15 is right to me. With anther gcc (4.9.3), the line-table looks
correct, and no test fail. Instead of setting breakpoint on main and
assuming the line is what we get from the source, we can set breakpoint
on that line. On the other hand, the test prints the values of the
array and check, so we need to set breakpoint on the line setting the
values of array and "next", rather than setting the breakpoint on main.
gdb/testsuite:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* gdb.base/annota1.exp: Set breakpoint on line $main_line.
* gdb.base/annota3.exp: Likewise.
2016-04-22 16:35:07 +02:00
fail $test
2010-05-26 20:05:25 +02:00
}
1999-05-05 23:45:13 +02:00
}
#
# display the value; test:
# annotate-display-begin
# annotate-display-number-end
# annotate-display-format
# annotate-display-expression
# annotate-display-expression-end
# annotate-display-end
# FIXME: annotate-display-value not tested
#
2010-05-26 20:05:25 +02:00
gdb_test_multiple "display value" "set up display" {
-re "post-prompt\r\n\r\n\032\032display-begin\r\n1\r\n\032\032display-number-end\r\n: \r\n\032\032display-format\r\n\r\n\032\032display-expression\r\nvalue\r\n\032\032display-expression-end\r\n = \r\n\032\032display-expression\r\n7\r\n\r\n\032\032display-end\r\n$gdb_prompt$" {
pass "set up display"
}
1999-05-05 23:45:13 +02:00
}
# should ask query. Test annotate-query.
# we don't care about anything else here, only the query.
send_gdb "run\n"
gdb_expect {
-re "pre-query.*already.*\\(y or n\\).*query\r\n" {
send_gdb "y\n"
gdb_expect {
-re ".*post-query.*$gdb_prompt$" \
{ pass "re-run" }
-re ".*$gdb_prompt$" { fail "re-run" }
timeout { fail "re-run (timeout)" }
}
}
-re ".*$gdb_prompt$" { fail "re-run" }
timeout { fail "re-run (timeout)" }
}
1999-11-02 05:44:47 +01:00
#
# Test that breakpoints-invalid is issued once and only once for
# breakpoint ignore count changes, after annotation stopped.
#
2012-02-28 23:40:48 +01:00
set value_inc_line [gdb_get_line_number "increment value"]
gdb_test_multiple "break $value_inc_line" "break at value++" {
-re "Breakpoint 5 at $hex: file .*$srcfile, line $value_inc_line.*$gdb_prompt$" {
pass "break at value++"
1999-11-02 05:44:47 +01:00
}
}
2010-05-26 20:05:25 +02:00
gdb_test_multiple "ignore 5 4" "ignore 5 4" {
1999-11-02 05:44:47 +01:00
-re "Will ignore next 4 crossings of breakpoint 5.*$gdb_prompt$" {
pass "ignore 5 4"
}
}
2010-05-26 20:05:25 +02:00
gdb_test_multiple "continue" "annotate ignore count change" {
There's code in annotate.c and breakpoint.c that is supposed to
suppress multiple breakpoints-invalid annotations when the ignore
count of a breakpoint changes, up until the target actually stops.
But, the code is bogus:
void
annotate_breakpoints_changed (void)
{
if (annotation_level == 2)
{
target_terminal_ours ();
printf_unfiltered (("\n\032\032breakpoints-invalid\n"));
if (ignore_count_changed)
ignore_count_changed = 0; /* Avoid multiple break annotations. */
}
}
The "ignore_count_changed" flag isn't actually guarding the output of
the annotation at all. It would have been better written something
like:
void
annotate_breakpoints_changed (void)
{
if (annotation_level == 2 && !ignore_count_changed)
{
target_terminal_ours ();
printf_unfiltered (("\n\032\032breakpoints-invalid\n"));
ignore_count_changed = 0; /* Avoid multiple break annotations. */
}
}
but, it wasn't. AFAICS, that goes all the way back to the original
patch'es submission and check in, at
<http://sourceware.org/ml/gdb-patches/1999-q4/msg00106.html>. I
looked a tar of HP's wdb from 1999, and even though that contains
local changes in the annotate code, this suppression seems borked
there too to me.
The original patch added a test to supposedly exercise this
suppression, but, it actually doesn't. It merely tests that
"breakpoints-invalid" is output after "stopped", but doesn't check
whether the duplicates supression actually works (IOW, check that only
_one_ annotation is seen). I was going to simply delete the tests
too, but a following patch will eliminate the duplicates in a
different way (which I needed for a different reason), so instead, I'm
making the tests actually fail if a duplicate annotation is seen.
Worry not, the test doesn't actually fail! The reason is that
breakpoint.c does:
else if (b->ignore_count > 0)
{
b->ignore_count--;
annotate_ignore_count_change ();
bs->stop = 0;
/* Increase the hit count even though we don't stop. */
++(b->hit_count);
observer_notify_breakpoint_modified (b);
}
where the annotate_ignore_count_change call is meant to inform the
"breakpoint_modified" annotation observer to ignore the notification.
All sounds good. But, the trouble is that nowadays annotate.c only
installs the observers if GDB is started with annotations enabled with
a command line option (gdb --annotate=2):
void
_initialize_annotate (void)
{
if (annotation_level == 2)
{
observer_attach_breakpoint_deleted (breakpoint_changed);
observer_attach_breakpoint_modified (breakpoint_changed);
}
}
and annota1.exp, to enable annotations, starts GDB normally, and
afterwards does "set annotate 2", so the observers aren't installed
when annota1.exp is run, and therefore changing the ignore count isn't
triggering any annotation at all...
gdb/
2013-01-22 Pedro Alves <palves@redhat.com>
* annotate.c (ignore_count_changed): Delete.
(annotate_breakpoints_changed): Don't clear ignore_count_changed.
(annotate_ignore_count_change): Delete.
(annotate_stopped): Don't emit a delayed breakpoints-changed
annotation.
* annotate.h (annotate_ignore_count_change): Delete.
* breakpoint.c (bpstat_check_breakpoint_conditions): Don't call
annotate_ignore_count_change.
gdb/testsuite/
2013-01-22 Pedro Alves <palves@redhat.com>
* gdb.base/annota1.exp (annotate ignore count change): Add
expected output for failure case.
2013-01-22 21:08:30 +01:00
-re ".*breakpoints-invalid.*breakpoints-invalid.*$gdb_prompt$" {
fail "annotate ignore count change"
}
-re ".*$srcfile:$value_inc_line:.*\032\032stopped\r\n$gdb_prompt$" {
1999-11-02 05:44:47 +01:00
pass "annotate ignore count change"
}
}
# check that ignore command is working, or the above can provide
# misleading assurance ...
2010-05-26 20:05:25 +02:00
gdb_test_multiple "next" "next to exit loop" {
-re "source .*annota1.c.*$gdb_prompt$" {
}
1999-11-02 05:44:47 +01:00
}
2012-02-28 23:40:48 +01:00
set after_loop_line [gdb_get_line_number "after loop"]
2010-05-26 20:05:25 +02:00
gdb_test_multiple "next" "breakpoint ignore count" {
2012-02-28 23:40:48 +01:00
-re ".*$srcfile:$after_loop_line:.*$gdb_prompt$" {
1999-11-02 05:44:47 +01:00
pass "breakpoint ignore count"
}
}
1999-05-05 23:45:13 +02:00
2011-09-08 16:56:34 +02:00
# Get the inferior's PID for later.
set test "get inferior pid"
set pid -1
gdb_test_multiple "info inferior 1" "$test" {
-re "process (\[0-9\]*).*$gdb_prompt$" {
set pid $expect_out(1,string)
pass "$test"
}
}
1999-05-05 23:45:13 +02:00
#
# Send a signal that is not handled; test:
# annotate-signalled
# annotate-signal-name
# annotate-signal-name-end
# annotate-signal-string
# annotate-signal-string-end
# FIXME: annotate-signal not tested (requires that the inferior be
# stopped by a "random" signal)
2004-07-20 02:24:41 +02:00
if [target_info exists gdb,nosignals] {
unsupported "signal sent"
} else {
2010-05-26 20:05:25 +02:00
gdb_test_multiple "signal SIGTRAP" "signal sent" {
2013-01-22 21:22:39 +01:00
-re ".*\032\032post-prompt\r\nContinuing with signal SIGTRAP.\r\n\r\n\032\032starting\(\r\n\r\n\032\032frames-invalid\)+\r\n\r\n\032\032signalled\r\n\r\nProgram terminated with signal \r\n\032\032signal-name\r\nSIGTRAP\r\n\032\032signal-name-end\r\n, \r\n\032\032signal-string\r\nTrace.breakpoint trap\r\n\032\032signal-string-end\r\n.\r\nThe program no longer exists.\r\n\r\n\032\032stopped\r\n$gdb_prompt$" {
2010-05-26 20:05:25 +02:00
pass "signal sent"
}
2004-07-20 02:24:41 +02:00
}
1999-05-05 23:45:13 +02:00
}
2004-07-12 23:39:35 +02:00
# Check for production of a core file and remove it!
1999-05-05 23:45:13 +02:00
2004-07-12 23:39:35 +02:00
set test "cleanup core file"
2011-09-08 16:56:34 +02:00
if { [remote_file host exists core] } {
remote_file host delete core
pass "$test (removed)"
} elseif { $pid != -1 && [remote_file host exists core.$pid] } {
remote_file host delete core.$pid
pass "$test (removed)"
1999-05-05 23:45:13 +02:00
} else {
2011-09-08 16:56:34 +02:00
pass "$test (not dumped)"
1999-05-05 23:45:13 +02:00
}
2008-05-20 23:11:04 +02:00
proc thread_test {} {
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
global subdir srcdir testfile srcfile binfile
2008-05-20 23:11:04 +02:00
global gdb_prompt old_gdb_prompt
2009-07-13 21:20:39 +02:00
set srcfile watch_thread_num.c
test suite update - gdb.base/[ab]
Convert files gdb.base/[ab]*.exp to use standard_output_file et al.
* a2-run.exp, all-bin.exp, annota1.exp, annota3.exp, anon.exp,
args.exp, arithmet.exp, arrayidx.exp, assign.exp, async-shell.exp,
async.exp, attach-pie-misread.exp, attach-pie-noexec.exp,
attach-twice.exp, attach.exp, auxv.exp, bang.exp, bfp-test.exp,
bigcore.exp, bitfields.exp, bitfields2.exp, break-entry.exp,
break-interp.exp, break-on-linker-gcd-function.exp,
breakpoint-shadow.exp: Use standard_testfile,
standard_output_file, prepare_for_testing, clean_restart.
2013-06-27 20:47:53 +02:00
set binfile [standard_output_file ${testfile}-watch_thread_num]
2008-05-20 23:11:04 +02:00
set gdb_prompt $old_gdb_prompt
2012-06-21 22:46:25 +02:00
if { ![get_compiler_info] && [gdb_compile_pthreads "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug nowarnings}] == "" } {
2008-05-20 23:11:04 +02:00
gdb_exit
gdb_start
gdb_reinitialize_dir $srcdir/$subdir
gdb_load ${binfile}
if { ![runto main] } then {
fail "run to main"
return
}
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 linenum [gdb_get_line_number "all threads started"]
gdb_breakpoint "$linenum"
2008-05-20 23:11:04 +02:00
set gdb_prompt \
"\r\n\032\032pre-prompt\r\n$gdb_prompt \r\n\032\032prompt\r\n"
2010-05-26 20:05:25 +02:00
gdb_test_multiple "set annotate 2" "" {
-re "set annotate 2\r\n$gdb_prompt$" {
}
2008-05-20 23:11:04 +02: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_multiple "continue" "new thread" {
-re "\032\032new-thread.*\r\n$gdb_prompt$" {
2010-05-26 20:05:25 +02:00
pass "new thread"
2008-05-20 23:11:04 +02:00
}
}
}
}
2008-06-06 02:40:21 +02:00
proc thread_switch {} {
2010-05-26 20:05:25 +02:00
gdb_test_multiple "thread 1" "thread switch" {
-re ".*\032\032thread-changed" {
2008-06-06 02:40:21 +02:00
pass "thread switch"
}
2010-05-26 20:05:25 +02:00
}
2008-06-06 02:40:21 +02:00
}
2008-05-20 23:11:04 +02:00
thread_test
2008-06-06 02:40:21 +02:00
thread_switch
2008-05-20 23:11:04 +02:00
1999-05-05 23:45:13 +02:00
# restore the original prompt for the rest of the testsuite
set gdb_prompt $old_gdb_prompt
