mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2025-03-31 14:11:36 +08:00
c5196c9298
Select `bfd_mach_mips4000', which corresponds to the MIPS III ISA, the earlies with 64-bit support, whenever a 32-bit BFD architecture has been chosen to use with a 64-bit ABI. The situation can happen in a few cases: 1. When the user has used `set architecture' or `set mips abi' commands to override automatic selection and then starts a debug session by requesting to run, attach or connect to a target. 2. In native debugging when reattaching to a previously debugged process where the program to be debugged has been since discarded, as observed with: FAIL: gdb.base/attach.exp: attach2, with no file (GDB internal error) in n32 and n64 regression testing. 3. In remote debugging with a non-XML debug stub when discarding the program to be debugged while connected to the remote target, as observed with: FAIL: gdb.base/break-unload-file.exp: cmdline: always-inserted on: break: file (GDB internal error) in n32 and n64 regression testing. In the latter two cases the ABI, quite rightfully, is retained while the program to be debugged is discarded. This is because in that case the ABI previously determined is carried over along with `gdbarch' in use, which is retained. The BFD architecture is however discarded and the default then applies, because it is not attached to `gdbarch'. In all these cases we trip with an internal error message as follows: .../gdb/mips-tdep.c:766: internal-error: bad register size A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) n This is a bug, please report it. For instructions, see: <http://www.gnu.org/software/gdb/bugs/>. coming from `mips_pseudo_register_read', because the raw register width inferred from the BFD architecture turns out to be 4 for the general registers while the cooked register width inferred from the ABI in effect is 8. We do not hit this internal error in remote debugging with an XML debug stub, because in that case raw register width information is passed by the stub along with the XML target description. Ultimately I think we ought to make the BFD architecture sticky like the ABI, however in the interim this simple fix will do, removing the error across all three cases. The case where the user has used `set mips abi' or `set architecture' commands has to be handled anyway, and although a more sophisticated solution could be envisaged, such as reporting an error with the respective `set' command, I think this is too much of a corner case to bother. gdb/ * mips-tdep.c (mips_gdbarch_init): Don't use a 32-bit BFD architecture with a 64-bit ABI.
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.