old-cross-binutils/gdb/testsuite/gdb.ada/tasks.exp
Joel Brobecker a812315168 [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

73 lines
2.6 KiB
Text

# Copyright 2009, 2010, 2011 Free Software Foundation, Inc.
#
# 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/>.
if $tracelevel then {
strace $tracelevel
}
load_lib "ada.exp"
set testdir "tasks"
set testfile "${testdir}/foo"
set srcfile ${srcdir}/${subdir}/${testfile}.adb
set binfile ${objdir}/${subdir}/${testfile}
file mkdir ${objdir}/${subdir}/${testdir}
if {[gdb_compile_ada "${srcfile}" "${binfile}" executable [list debug ]] != "" } {
return -1
}
clean_restart ${testfile}
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" \
[join {" +ID +TID P-ID Pri State +Name" \
"\\* +1 .* main_task" \
" +2 .* task_list\\(1\\)" \
" +3 .* task_list\\(2\\)" \
" +4 .* task_list\\(3\\)"} \
"\r\n"] \
"info tasks before inserting breakpoint"
# Now, insert a breakpoint that should stop only if task 3 stops.
gdb_test "break break_me task 3" "Breakpoint .* at .*"
# 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
# point.
gdb_test "continue" \
".*Breakpoint.*, foo.break_me \\(\\).*" \
"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" \
[join {" +ID +TID P-ID Pri State +Name" \
" +1 .* main_task" \
" +2 .* task_list\\(1\\)" \
"\\* +3 .* task_list\\(2\\)" \
" +4 .* task_list\\(3\\)"} \
"\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.
gdb_continue_to_end "" continue 1