mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2025-01-24 12:35:55 +08:00
75ac3a7f57
This patch fixes two related problems: - By default gas is supposed to bump the current architecture (starting with v6) as it finds "higher" instructions as the assembling progresses. There are four possible cases depending on the usage of the -A and -bump options: (a) No -A and -bump are specified. In this case max_architecture must be the highest architecture not conflicting with the default architecture. The default opcode architecture is indirectly set in configure.tgt and is "v9" in sparc64 systems (from "v9-64"). Thus the maximum architecture in sparc64 systems must be "v9b". No warnings are echoed when the assembly of an instruction bumps the current architecture. (b) Only -bump is specified. This is like (a) but warnings are always issued when the assembly of an instruction bumps the current architecture. (c) Only -A is specified. In this case bumping to a new architecture is an error. (d) Both -A and -bump are specified. In this case max_architecture must be the highest architecture not conflicting with the default architecture, but warnings are only to be issued when bumping to an architecture higher than the architecture selected in the -A option. `max_architecture' is a global variable defined in tc-sparc.c which is initialized to the opcode architecture corresponding to the default architecture ("sparclite" for sparc-* targets and "v9" for sparc64-* targets). Then in `md_begin' it is set to the highest non-conflicting architecture, but only when both -A and -bump are specified. Thus (a) does not work: $ echo "fzero %f0" | as {standard input}: Assembler messages: {standard input}:1: Error: Architecture mismatch on "fzero". {standard input}:1: (Requires v9a|v9b; requested architecture is v9.) Neither (b): $ echo "fzero %f0" | as -bump {standard input}: Assembler messages: {standard input}:1: Error: Architecture mismatch on "fzero". {standard input}:1: (Requires v9a|v9b; requested architecture is v9.) Only (d) does: $ echo "fzero %f0" | as -Av9 -bump {standard input}: Assembler messages: {standard input}:1: Warning: architecture bumped from "v6" to "v9a" on "fzero" This patch fixes that function to "upgrade" `max_architecture' also in the (a) and (b) cases. Note that this problem becomes apparent only in sparc64-* targets because in sparc-* targets the default architecture is the "higher" among the 32bit architectures ("sparclite"). - Gas maintains a set of hardware capabilities associated with each gas architecture, in `sparc_arch_table'. On the other hand libopcodes maintains a set of hardware capabilities needed by each individual sparc instruction. When an instruction is assembled in `sparc_ip' gas checks for the presence of the hardware capabilities required by the instruction, emitting an error if some capability is missing. However, this mechanism does not work properly if the current architecture is bumped due to an instruction requiring new hw capabilities not present on either the default architecture or an architecture specified with -A: $ echo "fzero %f0" | as -bump {standard input}: Assembler messages: {standard input}:1: Warning: architecture bumped from "v6" to "v9a" on "fzero" {standard input}:1: Error: Hardware capability "vis" not enabled for "fzero". This patch fixes this by adding the set of required hw caps of an instruction if it triggers an architecture bump. The patch has been tested in sparc64-unknown-linux-gnu. gas/ChangeLog: 2014-09-12 Jose E. Marchesi <jose.marchesi@oracle.com> * config/tc-sparc.c (sparc_ip): Update the set of allowed hwcaps when bumping the current architecture. (md_begin): Adjust the highetst architecture level also when a specific architecture is not requested. |
||
---|---|---|
bfd | ||
binutils | ||
config | ||
cpu | ||
elfcpp | ||
etc | ||
gas | ||
gdb | ||
gold | ||
gprof | ||
include | ||
intl | ||
ld | ||
libdecnumber | ||
libiberty | ||
opcodes | ||
readline | ||
sim | ||
texinfo | ||
.cvsignore | ||
.gitattributes | ||
.gitignore | ||
ChangeLog | ||
compile | ||
config-ml.in | ||
config.guess | ||
config.rpath | ||
config.sub | ||
configure | ||
configure.ac | ||
COPYING | ||
COPYING3 | ||
COPYING3.LIB | ||
COPYING.LIB | ||
COPYING.LIBGLOSS | ||
COPYING.NEWLIB | ||
depcomp | ||
djunpack.bat | ||
install-sh | ||
libtool.m4 | ||
lt~obsolete.m4 | ||
ltgcc.m4 | ||
ltmain.sh | ||
ltoptions.m4 | ||
ltsugar.m4 | ||
ltversion.m4 | ||
MAINTAINERS | ||
Makefile.def | ||
Makefile.in | ||
Makefile.tpl | ||
makefile.vms | ||
missing | ||
mkdep | ||
mkinstalldirs | ||
move-if-change | ||
README | ||
README-maintainer-mode | ||
setup.com | ||
src-release.sh | ||
symlink-tree | ||
ylwrap |
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.