mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-06-20 18:08:24 +08:00
68ce1575fc
When asking GDB to print a variable from an imported namespace, we only want to see variables imported in lines that the inferior has already gone through, as is being tested last in gdb.cp/nsusing.exp. However with the proposed change to gdb.cp/nsusing.exp, we get the following failures: (gdb) PASS: gdb.cp/nsusing.exp: continue to breakpoint: marker10 stop print x $9 = 911 (gdb) FAIL: gdb.cp/nsusing.exp: print x, before using statement next 15 y += x; (gdb) PASS: gdb.cp/nsusing.exp: using namespace M print x $10 = 911 (gdb) PASS: gdb.cp/nsusing.exp: print x, only using M Showing that the feature wasn't functioning properly, it just so happened that gcc ordered the namespaces in a convenient way. This happens because GDB doesn't take into account the line where the "using namespace" directive is written. So long as it shows up in the current scope, we assume it is valid. To fix this, add a new member to struct using_direct, that stores the line where the directive was written, and a new function that informs if the using directive is valid already. Unfortunately, due to a GCC bug, the failure still shows up. Compilers that set the declaration line of the using directive correctly (such as Clang) do not show such a bug, so the test includes an XFAIL for gcc code. Finally, because the final test of gdb.cp/nsusing.exp has turned into multiple that all would need XFAILs for older GCCs (<= 4.3), and that GCC is very old, if it is detected, the test just exits early. 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.