forked from Imagelibrary/binutils-gdb
e2fe3cbd0c
After this commit: commita68f7e9844Date: Tue May 9 10:28:42 2023 +0100 gdb/testsuite: extend special '^' handling to gdb_test_multiple buildbot notified me of a regression on s390 in the test: gdb.base/break-main-file-remove-fail.exp the failure looks like this: print /d ((int (*) (void *, size_t)) munmap) (16781312, 4096) warning: Error removing breakpoint 0 $2 = 0 (gdb) FAIL: gdb.base/break-main-file-remove-fail.exp: cmdline: get integer valueof "((int (*) (void *, size_t)) munmap) (16781312, 4096)" On the mailing list it has been reported that this failure also impacts arm, aarch64, and possibly ppc/ppc64 too. The above commit changed get_integer_valueof so that no output is expected between the command and the '$2 = 0' line. In this case the 'warning: Error removing breakpoint 0' output is causing the get_integer_valueof call to fail. The reason for this warning is that this test deliberately calls munmap on a page of the inferior's code. The test is checking that GDB can handle the situation where a s/w breakpoint can't be removed (due to the page no longer being readable/writable). The test that is supposed to trigger the warning is later in the test script when we delete a breakpoint. So why do some targets trigger the warning earlier during the inferior call? The impacted targets use AT_ENTRY_POINT as their strategy for handling inferior calls, that is, the trampoline that calls the inferior function is placed at the program's entry point, e.g. often the _start label. If this location happens to be on the same page as the page that the test script unmaps then, when the inferior function call returns, GDB will not be able to remove the temporary breakpoint that is inserted to catch the inferior function call returning! As a result we end up seeing the warning earlier than expected. I did wonder if this means I should relax the pattern in get_integer_valueof - just accept that there might be additional output from GDB which we should ignore. However, I don't think this the right way to go. With the change ina68f7e9844we are now stricter for GDB emitting additional, unexpected, output, and I think that is a good thing. So, I think, in this case, in order to handle the possible extra output, we should implement something like get_integer_valueof directly in the gdb.base/break-main-file-remove-fail.exp test script. This local version will handle the possible warning output. After this the test should pass again on the impacted targets.
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.