2014-01-01 03:54:24 +00:00
|
|
|
# Copyright 2009-2014 Free Software Foundation, Inc.
|
2009-03-31 16:48:49 +00: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/>.
|
|
|
|
|
|
|
|
|
|
load_lib "ada.exp"
|
|
|
|
|
|
2012-07-26 18:43:02 +00:00
|
|
|
standard_ada_testfile foo
|
2009-03-31 16:48:49 +00:00
|
|
|
|
|
|
|
|
if {[gdb_compile_ada "${srcfile}" "${binfile}" executable [list debug ]] != "" } {
|
|
|
|
|
return -1
|
|
|
|
|
}
|
|
|
|
|
|
[testsuite/gdb.ada] simplify some testcases by using clean_restart.
gdb/testsuite/ChangeLog:
* gdb.ada/array_bounds.exp, gdb.ada/array_return.exp,
gdb.ada/array_subscript_addr.exp, gdb.ada/arrayidx.exp,
gdb.ada/arrayparam.exp, gdb.ada/arrayptr.exp,
gdb.ada/atomic_enum.exp, gdb.ada/call_pn.exp,
gdb.ada/catch_ex.exp, gdb.ada/char_param.exp,
gdb.ada/complete.exp, gdb.ada/exprs.exp, gdb.ada/fixed_cmp.exp,
gdb.ada/fixed_points.exp, gdb.ada/formatted_ref.exp,
gdb.ada/frame_args.exp, gdb.ada/fun_addr.exp,
gdb.ada/fun_in_declare.exp, gdb.ada/funcall_param.exp,
gdb.ada/homonym.exp, gdb.ada/int_deref.exp,
gdb.ada/interface.exp, gdb.ada/lang_switch.exp,
gdb.ada/mod_from_name.exp, gdb.ada/nested.exp,
gdb.ada/null_array.exp, gdb.ada/null_record.exp,
gdb.ada/packed_array.exp, gdb.ada/packed_tagged.exp,
gdb.ada/print_chars.exp, gdb.ada/print_pc.exp,
gdb.ada/ptype_field.exp, gdb.ada/ptype_tagged_param.exp,
gdb.ada/rec_return.exp, gdb.ada/ref_param.exp,
gdb.ada/ref_tick_size.exp, gdb.ada/start.exp,
gdb.ada/str_ref_cmp.exp, gdb.ada/sym_print_name.exp,
gdb.ada/taft_type.exp, gdb.ada/tagged.exp, gdb.ada/tasks.exp,
gdb.ada/tick_last_segv.exp, gdb.ada/type_coercion.exp,
gdb.ada/uninitialized_vars.exp,
gdb.ada/variant_record_packed_array.exp, gdb.ada/watch_arg.exp:
Simplify by using clean_restart.
2011-01-06 10:35:00 +00:00
|
|
|
clean_restart ${testfile}
|
2009-03-31 16:48:49 +00:00
|
|
|
|
|
|
|
|
set bp_location [gdb_get_line_number "STOP_HERE" ${testdir}/foo.adb]
|
|
|
|
|
runto "foo.adb:$bp_location"
|
|
|
|
|
|
|
|
|
|
# Make sure that all tasks appear in the "info tasks" listing, and
|
|
|
|
|
# that the active task is the environment task.
|
|
|
|
|
gdb_test "info tasks" \
|
[Ada] Re-implement `info tasks' command using ui-out
This is in preparation for providing a GDB/MI equivalent of
the `info tasks' command. The previous implementation was using
various printf commands to generate the command output, which
does not work at all if we want to use that same code to generate
the result for that new GDB/MI command.
This patch thus re-implements the `info tasks' command (with no
arguments) in a way that makes it GDB/MI friendly.
There is an additional hicup, which is the fact that the `info tasks'
command displays a completely different type of output when a task
ID is given. For instance:
(gdb) info task 2
Ada Task: 0x644d20
Name: my_callee
Thread: 0
LWP: 0x5809
Parent: 1 (main_task)
Base Priority: 48
State: Blocked in accept or select with terminate
The above output is better when in CLI mode, but really not
what we want when in GDB/MI mode. In GDB/MI mode, we want to
follow what the `-thread-info' command does when a task-id
is given as an argument, which is to produce the same table,
but with only one element/task in it.
For compatibility as well as practical reasons, we do not want
to change the output of the `info task TASKNO' command when in
CLI mode. But it's easy to preserve this behavior while providing
the desirable output when in GDB/MI mode. For this, the function
used to generated the `info tasks' output has been enhanced to take
an argument interpreted as a string. The CLI command knows to never
provide that argument, while the GDB/MI command will pass one if
provided by the user.
gdb/ChangeLog:
* ada-tasks.c (print_ada_task_info): New function, merging
short_task_info and info_tasks together. Reimplement using
ui-out instead of printing to stdout directly. Move the code
building and checking the task list here, instead of leaving it
in info_tasks_command.
(info_task): Move the code building and checking the task
list here, instead of leaving it in info_tasks_command.
(info_tasks_command): Delete code building and checking
the task list - moved elsewhere. Update calls to info_tasks
and info_task.
One of the minor changes the switch caused is the introduction
of a space between the "current" column, and the task "ID"
column, which wasn't there before. This matches what we do
in the "info threads" command, so I kept that change. This
required an adjustment in the testsuite, however...
gdb/testsuite/ChangeLog:
* gdb.ada/tasks.exp: Make the expected output for
the `info tasks' tests more resilient to spacing
changes.
2011-09-16 19:09:57 +00:00
|
|
|
[join {" +ID +TID P-ID Pri State +Name" \
|
|
|
|
|
"\\* +1 .* main_task" \
|
|
|
|
|
" +2 .* task_list\\(1\\)" \
|
|
|
|
|
" +3 .* task_list\\(2\\)" \
|
|
|
|
|
" +4 .* task_list\\(3\\)"} \
|
2009-03-31 16:48:49 +00:00
|
|
|
"\r\n"] \
|
|
|
|
|
"info tasks before inserting breakpoint"
|
|
|
|
|
|
Multiple Ada task-specific breakpoints at the same address.
With the test changed as in the patch, against current mainline, we get:
(gdb) PASS: gdb.ada/tasks.exp: info tasks before inserting breakpoint
break break_me task 1
Breakpoint 2 at 0x4030b0: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb, line 27.
(gdb) PASS: gdb.ada/tasks.exp: break break_me task 1
break break_me task 3
Note: breakpoint 2 also set at pc 0x4030b0.
Breakpoint 3 at 0x4030b0: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb, line 27.
(gdb) PASS: gdb.ada/tasks.exp: break break_me task 3
continue
Continuing.
[Switching to Thread 0x7ffff7dc7700 (LWP 27133)]
Breakpoint 2, foo.break_me () at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb:27
27 null;
(gdb) FAIL: gdb.ada/tasks.exp: continue to breakpoint
info tasks
ID TID P-ID Pri State Name
1 63b010 48 Waiting on RV with 3 main_task
2 63bd80 1 48 Accept or Select Term task_list(1)
* 3 63f510 1 48 Accepting RV with 1 task_list(2)
4 642ca0 1 48 Accept or Select Term task_list(3)
(gdb) PASS: gdb.ada/tasks.exp: info tasks after hitting breakpoint
The breakpoint that caused a stop is breakpoint 3, but GDB end up
reporting (and running breakpoint commands of) "Breakpoint 2" instead.
The issue is that the bpstat_check_breakpoint_conditions logic of
"wrong thread" is missing the "wrong task" check. This is usually
harmless, because the thread hop code in infrun.c code that handles
wrong-task-hitting-breakpoint does check for task-specific breakpoints
(within breakpoint_thread_match):
/* Check if a regular breakpoint has been hit before checking
for a potential single step breakpoint. Otherwise, GDB will
not see this breakpoint hit when stepping onto breakpoints. */
if (regular_breakpoint_inserted_here_p (aspace, stop_pc))
{
if (!breakpoint_thread_match (aspace, stop_pc, ecs->ptid))
thread_hop_needed = 1;
}
IOW, usually, when one only has a task specific breakpoint at a given
address, things work correctly. Put another task-specific or
non-task-specific breakpoint there, and things break.
A patch that eliminates the special thread hop code in infrun.c is
what exposed this, as after that GDB solely relies on
bpstat_check_breakpoint_conditions to know whether the right or wrong
task hit a breakpoint. IOW, given the latent bug, Ada task-specific
breakpoints become non-task-specific, and that is caught by the
testsuite, as:
break break_me task 3
Breakpoint 2 at 0x4030b0: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb, line 27.
(gdb) PASS: gdb.ada/tasks.exp: break break_me task 3
continue
Continuing.
[Switching to Thread 0x7ffff7fcb700 (LWP 17122)]
Breakpoint 2, foo.break_me () at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb:27
27 null;
(gdb) PASS: gdb.ada/tasks.exp: continue to breakpoint
info tasks
ID TID P-ID Pri State Name
1 63b010 48 Waiting on RV with 2 main_task
* 2 63bd80 1 48 Accepting RV with 1 task_list(1)
3 63f510 1 48 Accept or Select Term task_list(2)
4 642ca0 1 48 Accept or Select Term task_list(3)
(gdb) FAIL: gdb.ada/tasks.exp: info tasks after hitting breakpoint
It was after seeing this that I thought of how to expose the bug with
current mainline.
Tested on x86_64 Fedora 17.
gdb/
2014-02-26 Pedro Alves <palves@redhat.com>
* breakpoint.c (bpstat_check_breakpoint_conditions): Handle
task-specific breakpoints.
gdb/testsuite/
2014-02-26 Pedro Alves <palves@redhat.com>
* gdb.ada/tasks.exp: Set a task-specific breakpoint at break_me
that won't ever trigger. Make sure that GDB reports the correct
breakpoint that caused the stop.
2014-02-26 14:22:33 +00:00
|
|
|
# Insert a breakpoint that should stop only if task 1 stops. Since
|
|
|
|
|
# task 1 never calls break_me, this shouldn't actually ever trigger.
|
|
|
|
|
# The fact that this breakpoint is created _before_ the next one
|
|
|
|
|
# matters. GDB used to have a bug where it would report the first
|
|
|
|
|
# breakpoint in the list that matched the triggered-breakpoint's
|
|
|
|
|
# address, no matter which task it was specific to.
|
|
|
|
|
gdb_test "break break_me task 1" "Breakpoint .* at .*"
|
|
|
|
|
|
|
|
|
|
# Now, insert a breakpoint that should stop only if task 3 stops, and
|
|
|
|
|
# extract its number.
|
|
|
|
|
set bp_number -1
|
|
|
|
|
set test "break break_me task 3"
|
|
|
|
|
gdb_test_multiple $test $test {
|
|
|
|
|
-re "Breakpoint (.*) at .*$gdb_prompt $" {
|
|
|
|
|
set bp_number $expect_out(1,string)
|
|
|
|
|
pass $test
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if {$bp_number < 0} {
|
|
|
|
|
return
|
|
|
|
|
}
|
2009-03-31 16:48:49 +00:00
|
|
|
|
|
|
|
|
# Continue to that breakpoint. Task 2 should hit it first, and GDB
|
|
|
|
|
# is expected to ignore that hit and resume the execution. Only then
|
|
|
|
|
# task 3 will hit our breakpoint, and GDB is expected to stop at that
|
Multiple Ada task-specific breakpoints at the same address.
With the test changed as in the patch, against current mainline, we get:
(gdb) PASS: gdb.ada/tasks.exp: info tasks before inserting breakpoint
break break_me task 1
Breakpoint 2 at 0x4030b0: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb, line 27.
(gdb) PASS: gdb.ada/tasks.exp: break break_me task 1
break break_me task 3
Note: breakpoint 2 also set at pc 0x4030b0.
Breakpoint 3 at 0x4030b0: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb, line 27.
(gdb) PASS: gdb.ada/tasks.exp: break break_me task 3
continue
Continuing.
[Switching to Thread 0x7ffff7dc7700 (LWP 27133)]
Breakpoint 2, foo.break_me () at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb:27
27 null;
(gdb) FAIL: gdb.ada/tasks.exp: continue to breakpoint
info tasks
ID TID P-ID Pri State Name
1 63b010 48 Waiting on RV with 3 main_task
2 63bd80 1 48 Accept or Select Term task_list(1)
* 3 63f510 1 48 Accepting RV with 1 task_list(2)
4 642ca0 1 48 Accept or Select Term task_list(3)
(gdb) PASS: gdb.ada/tasks.exp: info tasks after hitting breakpoint
The breakpoint that caused a stop is breakpoint 3, but GDB end up
reporting (and running breakpoint commands of) "Breakpoint 2" instead.
The issue is that the bpstat_check_breakpoint_conditions logic of
"wrong thread" is missing the "wrong task" check. This is usually
harmless, because the thread hop code in infrun.c code that handles
wrong-task-hitting-breakpoint does check for task-specific breakpoints
(within breakpoint_thread_match):
/* Check if a regular breakpoint has been hit before checking
for a potential single step breakpoint. Otherwise, GDB will
not see this breakpoint hit when stepping onto breakpoints. */
if (regular_breakpoint_inserted_here_p (aspace, stop_pc))
{
if (!breakpoint_thread_match (aspace, stop_pc, ecs->ptid))
thread_hop_needed = 1;
}
IOW, usually, when one only has a task specific breakpoint at a given
address, things work correctly. Put another task-specific or
non-task-specific breakpoint there, and things break.
A patch that eliminates the special thread hop code in infrun.c is
what exposed this, as after that GDB solely relies on
bpstat_check_breakpoint_conditions to know whether the right or wrong
task hit a breakpoint. IOW, given the latent bug, Ada task-specific
breakpoints become non-task-specific, and that is caught by the
testsuite, as:
break break_me task 3
Breakpoint 2 at 0x4030b0: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb, line 27.
(gdb) PASS: gdb.ada/tasks.exp: break break_me task 3
continue
Continuing.
[Switching to Thread 0x7ffff7fcb700 (LWP 17122)]
Breakpoint 2, foo.break_me () at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb:27
27 null;
(gdb) PASS: gdb.ada/tasks.exp: continue to breakpoint
info tasks
ID TID P-ID Pri State Name
1 63b010 48 Waiting on RV with 2 main_task
* 2 63bd80 1 48 Accepting RV with 1 task_list(1)
3 63f510 1 48 Accept or Select Term task_list(2)
4 642ca0 1 48 Accept or Select Term task_list(3)
(gdb) FAIL: gdb.ada/tasks.exp: info tasks after hitting breakpoint
It was after seeing this that I thought of how to expose the bug with
current mainline.
Tested on x86_64 Fedora 17.
gdb/
2014-02-26 Pedro Alves <palves@redhat.com>
* breakpoint.c (bpstat_check_breakpoint_conditions): Handle
task-specific breakpoints.
gdb/testsuite/
2014-02-26 Pedro Alves <palves@redhat.com>
* gdb.ada/tasks.exp: Set a task-specific breakpoint at break_me
that won't ever trigger. Make sure that GDB reports the correct
breakpoint that caused the stop.
2014-02-26 14:22:33 +00:00
|
|
|
# point. Also make sure that GDB reports the correct breakpoint number.
|
2009-03-31 16:48:49 +00:00
|
|
|
gdb_test "continue" \
|
Multiple Ada task-specific breakpoints at the same address.
With the test changed as in the patch, against current mainline, we get:
(gdb) PASS: gdb.ada/tasks.exp: info tasks before inserting breakpoint
break break_me task 1
Breakpoint 2 at 0x4030b0: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb, line 27.
(gdb) PASS: gdb.ada/tasks.exp: break break_me task 1
break break_me task 3
Note: breakpoint 2 also set at pc 0x4030b0.
Breakpoint 3 at 0x4030b0: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb, line 27.
(gdb) PASS: gdb.ada/tasks.exp: break break_me task 3
continue
Continuing.
[Switching to Thread 0x7ffff7dc7700 (LWP 27133)]
Breakpoint 2, foo.break_me () at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb:27
27 null;
(gdb) FAIL: gdb.ada/tasks.exp: continue to breakpoint
info tasks
ID TID P-ID Pri State Name
1 63b010 48 Waiting on RV with 3 main_task
2 63bd80 1 48 Accept or Select Term task_list(1)
* 3 63f510 1 48 Accepting RV with 1 task_list(2)
4 642ca0 1 48 Accept or Select Term task_list(3)
(gdb) PASS: gdb.ada/tasks.exp: info tasks after hitting breakpoint
The breakpoint that caused a stop is breakpoint 3, but GDB end up
reporting (and running breakpoint commands of) "Breakpoint 2" instead.
The issue is that the bpstat_check_breakpoint_conditions logic of
"wrong thread" is missing the "wrong task" check. This is usually
harmless, because the thread hop code in infrun.c code that handles
wrong-task-hitting-breakpoint does check for task-specific breakpoints
(within breakpoint_thread_match):
/* Check if a regular breakpoint has been hit before checking
for a potential single step breakpoint. Otherwise, GDB will
not see this breakpoint hit when stepping onto breakpoints. */
if (regular_breakpoint_inserted_here_p (aspace, stop_pc))
{
if (!breakpoint_thread_match (aspace, stop_pc, ecs->ptid))
thread_hop_needed = 1;
}
IOW, usually, when one only has a task specific breakpoint at a given
address, things work correctly. Put another task-specific or
non-task-specific breakpoint there, and things break.
A patch that eliminates the special thread hop code in infrun.c is
what exposed this, as after that GDB solely relies on
bpstat_check_breakpoint_conditions to know whether the right or wrong
task hit a breakpoint. IOW, given the latent bug, Ada task-specific
breakpoints become non-task-specific, and that is caught by the
testsuite, as:
break break_me task 3
Breakpoint 2 at 0x4030b0: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb, line 27.
(gdb) PASS: gdb.ada/tasks.exp: break break_me task 3
continue
Continuing.
[Switching to Thread 0x7ffff7fcb700 (LWP 17122)]
Breakpoint 2, foo.break_me () at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/tasks/foo.adb:27
27 null;
(gdb) PASS: gdb.ada/tasks.exp: continue to breakpoint
info tasks
ID TID P-ID Pri State Name
1 63b010 48 Waiting on RV with 2 main_task
* 2 63bd80 1 48 Accepting RV with 1 task_list(1)
3 63f510 1 48 Accept or Select Term task_list(2)
4 642ca0 1 48 Accept or Select Term task_list(3)
(gdb) FAIL: gdb.ada/tasks.exp: info tasks after hitting breakpoint
It was after seeing this that I thought of how to expose the bug with
current mainline.
Tested on x86_64 Fedora 17.
gdb/
2014-02-26 Pedro Alves <palves@redhat.com>
* breakpoint.c (bpstat_check_breakpoint_conditions): Handle
task-specific breakpoints.
gdb/testsuite/
2014-02-26 Pedro Alves <palves@redhat.com>
* gdb.ada/tasks.exp: Set a task-specific breakpoint at break_me
that won't ever trigger. Make sure that GDB reports the correct
breakpoint that caused the stop.
2014-02-26 14:22:33 +00:00
|
|
|
".*Breakpoint $bp_number, foo.break_me \\(\\).*" \
|
2009-03-31 16:48:49 +00:00
|
|
|
"continue to breakpoint"
|
|
|
|
|
|
|
|
|
|
# Check that it is indeed task 3 that hit the breakpoint by checking
|
|
|
|
|
# which is the active task.
|
|
|
|
|
gdb_test "info tasks" \
|
[Ada] Re-implement `info tasks' command using ui-out
This is in preparation for providing a GDB/MI equivalent of
the `info tasks' command. The previous implementation was using
various printf commands to generate the command output, which
does not work at all if we want to use that same code to generate
the result for that new GDB/MI command.
This patch thus re-implements the `info tasks' command (with no
arguments) in a way that makes it GDB/MI friendly.
There is an additional hicup, which is the fact that the `info tasks'
command displays a completely different type of output when a task
ID is given. For instance:
(gdb) info task 2
Ada Task: 0x644d20
Name: my_callee
Thread: 0
LWP: 0x5809
Parent: 1 (main_task)
Base Priority: 48
State: Blocked in accept or select with terminate
The above output is better when in CLI mode, but really not
what we want when in GDB/MI mode. In GDB/MI mode, we want to
follow what the `-thread-info' command does when a task-id
is given as an argument, which is to produce the same table,
but with only one element/task in it.
For compatibility as well as practical reasons, we do not want
to change the output of the `info task TASKNO' command when in
CLI mode. But it's easy to preserve this behavior while providing
the desirable output when in GDB/MI mode. For this, the function
used to generated the `info tasks' output has been enhanced to take
an argument interpreted as a string. The CLI command knows to never
provide that argument, while the GDB/MI command will pass one if
provided by the user.
gdb/ChangeLog:
* ada-tasks.c (print_ada_task_info): New function, merging
short_task_info and info_tasks together. Reimplement using
ui-out instead of printing to stdout directly. Move the code
building and checking the task list here, instead of leaving it
in info_tasks_command.
(info_task): Move the code building and checking the task
list here, instead of leaving it in info_tasks_command.
(info_tasks_command): Delete code building and checking
the task list - moved elsewhere. Update calls to info_tasks
and info_task.
One of the minor changes the switch caused is the introduction
of a space between the "current" column, and the task "ID"
column, which wasn't there before. This matches what we do
in the "info threads" command, so I kept that change. This
required an adjustment in the testsuite, however...
gdb/testsuite/ChangeLog:
* gdb.ada/tasks.exp: Make the expected output for
the `info tasks' tests more resilient to spacing
changes.
2011-09-16 19:09:57 +00:00
|
|
|
[join {" +ID +TID P-ID Pri State +Name" \
|
|
|
|
|
" +1 .* main_task" \
|
|
|
|
|
" +2 .* task_list\\(1\\)" \
|
|
|
|
|
"\\* +3 .* task_list\\(2\\)" \
|
|
|
|
|
" +4 .* task_list\\(3\\)"} \
|
2009-03-31 16:48:49 +00:00
|
|
|
"\r\n"] \
|
|
|
|
|
"info tasks after hitting breakpoint"
|
|
|
|
|
|
|
|
|
|
# Now, resume the execution and make sure that GDB does not stop when
|
|
|
|
|
# task 4 hits the breakpoint. Continuing thus results in our program
|
|
|
|
|
# running to completion.
|
2011-03-09 14:17:05 +00:00
|
|
|
gdb_continue_to_end "" continue 1
|
