Pedro Alves
5068630ad3
I have patches that:
1 - make the CLI print stop info from a normal_stop observer, like MI
does.
2 - happen to change the order in which the Python and CLI/TUI
normal_stop observers are installed.
With those in place, py-events.exp regresses like shown below [1],
because the Python stop events are output before CLI prints stop info,
instead of after, and the test doesn't expect that.
With the same Python hooks, the order in which MI and Python events is
emited today is already undefined, because MI also uses the
normal_stop observer for output. I see no reason that we should in
general define the order observers, interpreters and scripting
languages get their turn at being notified of these events. So this
patch makes the test cope with Python->CLI output order too.
Tested on x86_64 Fedora 20.
gdb/testsuite/
2015-07-24 Pedro Alves <palves@redhat.com>
* gdb.python/py-events.exp: Accept output between the stop event
and the prompt.
* gdb.python/py-evsignal.exp: Likewise.
* gdb.python/py-evthreads.exp: Likewise.
[1] - The regressions in question look like:
Before said patches:
(gdb) continue
Continuing.
event type: continue
Breakpoint 2, first () at /home/pedro/gdb/mygit/build/../src/gdb/testsuite/gdb.python/py-events.c:30
30 for (i = 0; i < 2; i++)
event type: stop
event type: stop
stop reason: breakpoint
first breakpoint number: 2
breakpoint number: 2
breakpoint number: 3
all threads stopped
(gdb) PASS: gdb.python/py-events.exp: continue
After said patches:
(gdb) continue
Continuing.
event type: continue
event type: stop
event type: stop
stop reason: breakpoint
first breakpoint number: 2
breakpoint number: 2
breakpoint number: 3
all threads stopped
Breakpoint 2, first () at /home/pedro/gdb/mygit/build/../src/gdb/testsuite/gdb.python/py-events.c:30
30 for (i = 0; i < 2; i++)
(gdb) FAIL: gdb.python/py-events.exp: continue
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.