mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-06-26 22:07:58 +08:00
90af06793e
Currently, if the target announces that it has floating point registers in its target description then GDB assumes that the hardware float ABI should be used. However, there's nothing stopping a user compiling a program for the soft-float abi, and then trying to run this on a target with hardware floating point registers. This commit adjusts the logic that decides if GDB should use the hardware float abi. The primary decision now is based on what the ELF currently being executed says in its headers. If the file was compiled for h/w float abi, then GDB uses h/w float abi, otherwise s/w float is used. If the current BFD is not an ELF then we don't currently have a mechanism for figuring out if the file was compiled for float or not. In this case we disable the h/w float abi. This shouldn't be a problem as, right now, the RISC-V linker can only produce ELFs. If there is NO current BFD (can this happen?) then we will enable h/w float abi if the target has floating point hardware, otherwise, s/w float abi is used. This commit also adds some sanity checking that the features requested in the BFD (xlen and flen) match the target description. For testing I ran the testsuite on a target that returns a target description containing both integer and floating point registers, but used a compiler that didn't have floating point support. Before this commit I would see failures on may tests that made inferior calls using floating point arguments, after this commit, all of these issues are resolved. One example from the testsuite is gdb.base/infcall-nested-structs.exp. gdb/ChangeLog: * riscv-tdep.c (riscv_features_from_gdbarch_info): New function. (riscv_find_default_target_description): Use new function to extract feature from gdbarch_info. (riscv_gdbarch_init): Add error checks for xlen and flen between target description and bfd headers. Be smarter about when we think the hardware floating point abi should be used.
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.