Simon Marchi
2bf4cc2b92
gdb.fortran/lbound-ubound.exp reads the expected lbound and ubound
values by reading some output from the inferior. This is racy when
running on boards where the inferior I/O is on a separate TTY than
GDB's, such as native-gdbserver.
I sometimes see this behavior:
(gdb) continue
Continuing.
Breakpoint 2, do_test (lb=..., ub=...) at /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/nati
ve-gdbserver/src/binutils-gdb/gdb/testsuite/gdb.fortran/lbound-ubound.F90:45
45 print *, "" ! Test Breakpoint
(gdb) Remote debugging from host ::1, port 37496
Expected GDB Output:
LBOUND = (-8, -10)
UBOUND = (-1, -2)
APB: Run a test here
APB: Expected lbound '(-8, -10)'
APB: Expected ubound ''
What happened is that expect read the output from GDB before the output
from the inferior, triggering this gdb_test_multiple clause:
-re "$gdb_prompt $" {
set found_prompt true
if {$found_dealloc_breakpoint
|| ($expected_lbound != "" && $expected_ubound != "")} {
# We're done.
} else {
exp_continue
}
}
So it set found_prompt, but the gdb_test_multiple kept going because
found_dealloc_breakpoint is false (this is the flag indicating that the
test is finished) and we still don't have expected_lbound and
expected_ubound. Then, expect reads in the inferior I/O, triggering
this clause:
-re ".*LBOUND = (\[^\r\n\]+)\r\n" {
set expected_lbound $expect_out(1,string)
if {!$found_prompt} {
exp_continue
}
}
This sets expected_lbound, but since found_prompt is true, we don't do
exp_continue, and exit the gdb_test_multiple, without having an
expected_ubound.
Change the test to read the values from the lb and ub function
parameters instead. As far as I understand, this still exercises what
we want to test. These variables contain the return values of the
lbound and ubound functions as computed by the program. We'll use them
to check the return values of the lbound and ubound functions as
computed by GDB.
Change-Id: I3c4d3d17d9291870a758a42301d15a007821ebb5
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30414
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.