parse_qfloat_immediate() accidentaly parses register with size
qualifier as immediate constant (It takes '<n>.' substring as
valid floating point constant).
Due to this, slightly reorder cases in parse_neon_mov() and move parsing of
vmov with immediate constant to last place.
MFC after: 2 weeks
In r208737 jmallett@ added support for the "mips64r2" architecture
and "octeon" CPU, and the saa/saad instructions.
Upstream binutils also added the "octeon+" CPU, and the saa/saad
instructions are only available in octeon+, not octeon. Since our
base system tool chain already accepts saa/saad with -march=octeon,
just allow octeon+ as an alias.
This allows the use of octeon+ in kernel config files, for use with both
external tool chain and in-tree GCC/binutils.
PR: 216516
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
We normally use the binutils from ports but on other systems this
is required for building gcc 4.9.
Obtained from: OpenBSD (CVS rev. 1.5)
MFC after: 3 weeks
partial_where points into the buffer that begins with buffer_start
so we need to use memmove() to handle the overlap.
Sourceware-PR 11456.
Obtained from: OpenBSD (CVS rev. 1.2)
MFC after: 3 days
Corresponds to 727fc41e077139570ea8b8ddfd6c546b2a55627c.
This allows us to use -no-integrated-as with clang, if we prefer.
Obtained from: binutils-gdb (Relicensed from Alan Modra as GPLv2)
MFC after: 2 weeks
X-MFC-with: r275718
Otherwise, clang can effectively remove the first iteration of the for
loops where this macro is invoked, and as a result, "cmp r0, #99" fails
to assemble.
Obtained from: joerg at netbsd
MFC after: 3 days
The powerpc support was the only supported architecture not prepending the elf format name
with "-freebsd" in base this change makes it consistent with other architectures.
On newer version of binutils the powerpc format is also prepended with "-freebsd".
Also modify the kernel ldscripts in that regards.
As a result it is now possible cross build the kernel on powerpc using newer binutils
Differential Revision: https://reviews.freebsd.org/D926
Differential Revision: https://reviews.freebsd.org/D928
names that must nnot be adjusted. This fixes a bug where code such as:
movw r2, :lower16:symbol
movt r2, :upper16:symbol
It is common for clang to generate such code when targeting armv7.
including an alignment. Previously binutils would only allow instructions
in the form "vld1.64 {d0, d1}, [r0, :128]" where the final comma should
not be there, instead the above instruction should be
"vld1.64 {d0, d1}, [r0:128]".
This change duplicates the alignment code from within the function to
handle this case.
the same values as the -march= command line option. Add support for the
"sec" extension (security extensions).
We've been getting away without support for the sec extension because
it's bogusly enabled even on arches where its presence is optional. This
support for .arch_extension is being added mainly so that we can use the
right directives in our source code, and that helps folks using external
toolchains (and will help us when we finally update our toolchain).
Add support for stac/clac instructions to manipulate the flag
that controls the behaviour of Intel's Supervisor Mode Access
Prevention (SMAP) feature.
Tested by: dim
Obtained from: OpenBSD
MFC after: 5 days
64-bit debug data is only necessary for objects with greater than 4GB of
debug data, and is not used on other 64-bit FreeBSD targets.
Sponsored by: DARPA, AFRL
Fix the VCVT instruction. It must round towards zero when converting from
a floating-point to an integer value. This was not the case causing issues
when printing certain values.
There is a VCVTR instruction that will round depending on the current
rounding mode. We don't yet support this instruction, or setting the
rounding mode.
The header_length field is the number of bytes following the field to
the first byte of the line number program. The hard-coded constants
previously here (4 + 2 + 4) were correct only for 32-bit DWARF.
Sponsored by: DARPA, AFRL
smlal, and umlal the output registers are allowed to be the same as either
input registers, where in ARMv4 and ARMv5 they could only be the same as the
last input register.
register added to the symbol table by the assembler. On further
investigation it was found the problem was with the my_get_expression
function. This is called by parse_big_immediate.
Fix this by moving the call to parse_big_immediate to the end of the if,
else if, ..., else block.
Thanks to Mike Belopuhov for the pointer to the OpenBSD patch, though
OpenBSD's gcc is very different that it only helped w/ where to modify,
not how... Thanks to jhb for some early reviews...
Reviewed by: imp, kib
MFC after: 1 month
r238211:
Support TARGET_ARCH=armv6 and TARGET_ARCH=armv6eb
This adds a new TARGET_ARCH for building on ARM
processors that support the ARMv6K multiprocessor
extensions. In particular, these processors have
better support for TLS and mutex operations.
This mostly touches a lot of Makefiles to extend
existing patterns for inferring CPUARCH from ARCH.
It also configures:
* GCC to default to arm1176jz-s
* GCC to predefine __FreeBSD_ARCH_armv6__
* gas to default to ARM_ARCH_V6K
* uname -p to return 'armv6'
* make so that MACHINE_ARCH defaults to 'armv6'
It also changes a number of headers to use
the compiler __ARM_ARCH_XXX__ macros to configure
processor-specific support routines.
Submitted by: Tim Kientzle <kientzle@freebsd.org>
adding appropriate table entries, the assembler had to be adjusted as
these are the first non-SSE instructions to use a 3-byte opcode (and a
mandatory prefix to boot).
MFC after: 1 month
instructions. I reimplemented this from scratch based on the Intel
manuals and the existing support for handling the fxsave and fxrstor
instructions. This will let us use these instructions natively with GCC
rather than hardcoding the opcodes in hex.
Reviewed by: kib
MFC after: 1 month
us up to version 2.17.50.20070703, at the last GPLv2 commit.
Amongst others, this added upstream support for some FreeBSD-specific
things that we previously had to manually hack in, such as the OSABI
label support, and so on.
There are also quite a number of new files, some for cpu's (e.g. SPU)
that we may or may not be interested in, but those can be cleaned up
later on, if needed.
The change made to bfd/elf.c in upstream revision 1.217.4.3 (which was a
revert of an earlier change), caused objcopy on powerpc to fail to copy
debug info from kernel modules. This had to be fixed by applying the
diff from upstream revision 1.243 on top of it.
o) Add TARGET_ABI to the MIPS toolchain build process. This sets the default
ABI to one of o32, n32 or n64. If it is not set, o32 is assumed as that is
the current default.
o) Set the default GCC cpu type to any specified TARGET_CPUTYPE. This is
necessary to have a working "cc" if e.g. mips64 is specified, as binutils
will refuse to link objects using different ISAs in some cases.
o) Add support for n32 and n64 ABIs to binutils and GCC.
o) Add additional required libgcc2 stubs for n32 and n64.
o) Add support for the "mips64r2" architecture to GCC. Add the "octeon"
o) When static linking, wrap default libraries in --start-group and
--end-group. This is required for static linking to work on n64 with the
interdependencies between libraries there. This is what other OSes that
support n64 seem to do, as well.
o) Fix our GCC spec to define __mips64 for 64-bit targets, not __mips64__, the
former being what libgcc, etc., check and the latter seemingly being a
misspelling of a hand merge from a Linux spec.
o) When no TARGET_CPUTYPE is specified at build time, make GCC take the default
ISA from the ABI. Our old defaults were too liberal and assumed that 64-bit
ABIs should default to the MIPS64 ISA and that 32-bit ABIs should default to
the MIPS32 ISA, when we are supporting or will support some systems based on
earlier 32-bit and 64-bit ISAs, most notably MIPS-III.
o) Merge a new opcode file (and support code) from a later version of binutils
and add flags and code necessary to support Octeon-specific instructions.
This should also make merging opcodes for other modern architectures easier.
Reviewed by: imp
