mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-12-19 01:19:41 +08:00
17f6581c36
The gdb.threads/thread-specific-bp.exp test has been a little problematic, see commits: commit89702edd93Date: Thu Mar 9 12:31:26 2023 +0100 [gdb/testsuite] Fix gdb.threads/thread-specific-bp.exp on native-gdbserver and commit2e5843d87cDate: Fri Nov 19 14:33:39 2021 +0100 [gdb/testsuite] Fix gdb.threads/thread-specific-bp.exp But I recently saw a test failure for that test, which looked like this: ... (gdb) PASS: gdb.threads/thread-specific-bp.exp: non_stop=on: thread 1 selected continue -a Continuing. Thread 1 "thread-specific" hit Breakpoint 4, end () at /tmp/binutils-gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/thread-specific-bp.c:29 29 } (gdb) [Thread 0x7ffff7c5c700 (LWP 1552086) exited] Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list. FAIL: gdb.threads/thread-specific-bp.exp: non_stop=on: continue to end (timeout) ... This only crops up (for me) when running on a loaded machine, and still only occurs sometimes. I've had to leave the test running in a loop for 10+ minutes sometimes in order to see the failure. The problem is that we use gdb_test_multiple to try and match two patterns: (1) The 'Thread-specific breakpoint 3 deleted ....' message, and (2) The GDB prompt. As written in the test, we understand that these patterns can occur in any order, and we have a flag for each pattern. Once both patterns have been seen then we PASS the test. The problem is that once expect has matched a pattern, everything up to, and including the matched text is discarded from the input buffer. Thus, if the input buffer contains: <PATTERN 2><PATTERN 1> Then expect will first try to match <PATTERN 1>, which succeeds, and then expect discards the entire input buffer up to the end of the <PATTERN 1>. As a result, we will never spot <PATTERN 2>. Obviously we can't just reorder the patterns within the gdb_test_multiple, as the output can legitimately (and most often does) occur in the other order, in which case the test would mostly fail, and only occasionally pass! I think the easiest solution here is just to have the gdb_test_multiple contain two patterns, each pattern consists of the two parts, but in the alternative orders, thus, for a particular output configuration, only one regexp will match. With this change in place, I no longer see the intermittent failure. Approved-By: Tom Tromey <tom@tromey.com>
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.