mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-06-24 20:28:28 +08:00
a56c63f78e
When running the gdb.mi/mi-exec-run.exp test using the native-extended-gdbserver I see failures like this: FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=main: mi=main: force-fail=1: run failure detected FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=main: mi=separate: force-fail=1: run failure detected FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=1: run failure detected There's a race condition here, so you might see a slightly different set of failures, but I always see some from the 'run failure detected' test. NOTE: I also see an additional test failure: FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=0: breakpoint hit reported on console (timeout) but that is a completely different issue, and is not being addressed in this commit. The problem for the 'run failure detected' test is that we end up in gdb_expect looking for output from two spawn-ids, one from gdbserver, and one from gdb. We're looking for one output pattern from each spawn-id, and for the test to pass we need to see both patterns. Now, if gdb exits then this is a test failure (this would indicate gdb crashing, which is bad), so we have an eof pattern associated with the gdb spawn-id. However, in this particular test we expect gdbserver to fail to execute the binary (the test binary is set non-executable), and so we get an error message from gdbserver (which matches the pattern), and then gdbserver exits, this is expected. The problem is that after spotting the pattern from gdbserver, we often see the eof from gdbserver before we see the pattern from gdb. If this happens then we drop out of the gdb_expect without ever seeing the pattern from gdb, and fail the test. In this commit, I place the spawn-id of gdbserver into a global variable, and then use this global variable as the -i option within the gdb_expect. Now, once we have seen the expected pattern on the gdbserver spawn-id, the global variable is cleared. After this the gdb_expect no longer checks the gdbserver spawn-id for additional output, and so never sees the eof event. This leaves the gdb_expect running, which allows the pattern from gdb to be seen, and for the test to pass. I now see no failures relating to 'run failure detected'.
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.