The MIPS bug was introduced by upstream commit 7403cb630, which failed
to account for the additional indirection introduced and also dropped
one of the checks; change it to the standard "NULL-or-empty" check as
used elsewhere in BFD, which is also what upstream now has.
Submitted by: James Clarke <jrtc27@jrtc27.com>
Obtained from: CheriBSD
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D21911
In the future FreeBSD will ship without GNU binutils 2.17.50. Add a
note advising users who require GNU as to install the binutils port
or package.
Note that on armv7, arm64, amd64, i386 we currently ship only two
binutils tools (as and objdump). A deprecation notice was added to
objdump's man page some time ago.
PR: 233611
Discussed with: jhb
MFC after: 1 week
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
We may install llvm-objdump as objdump (see review D18307) or just
provide no /usr/bin/objdump, but either way GNU objdump won't be
installed in the future.
MFC after: 3 days
Summary:
This change fixes the following compilation error when using clang 8 to cross
compile base to powerpc64:
```
/usr/src/gnu/usr.bin/binutils/libopcodes/../../../../contrib/binutils/opcodes/ppc-dis.c💯35:
error: arithmetic on a null pointer treated as a cast from integer to pointer is
a GNU extension [-Werror,-Wnull-pointer-arithmetic]
info->private_data = (char *) 0 + dialect;
~~~~~~~~~~ ^
1 error generated.
*** [ppc-dis.o] Error code 1
make[6]: stopped in /usr/src/gnu/usr.bin/binutils/libopcodes
1 error
```
Test Plan:
- buildworld for x86_64 (native)
- buildworld for powerpc64 (cross)
- buildworld for powerpc64 (native)
Submitted by: alfredo.junior_eldorado.org.br
Reviewed By: emaste, pfg, brooks
Differential Revision: https://reviews.freebsd.org/D19235
Latest clang git has a warning -Wnull-pointer-arithmetic which will
trigger a -Werror failure. Addition and subtraction from a null pointer
is undefined behaviour and could be optimized into anything.
Furthermore, using the difference between two pointers and casting the
result back to a pointer is not portable since the size of ptrdiff_t
does not necessary have to be the same as size of void* (this happens
e.g. on CHERI). Using intptr_t instead fixes this portability issue and
the compiler warning.
Submitted by; Alexander Richardson
Obtained from: CheriBSD
Differential Revision: https://reviews.freebsd.org/D12928
MFC after: 3 days
allocated memory when it returns early.
Free the memory associated with the variables full_programe, bin_dirs,
prog_dirs, and prefix_dirs when the function returns early.
Submitted by: Tom Rix <trix@juniper.net>
Reviewed by: jhibbits, emaste
Approved by: sjg (mentor)
Obtained from: Juniper Networks, Inc.
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D9691
From binutils commits 5a4b0ccc20ba30caef53b01bee2c0aaa5b855339 and
7e1e19887abd24aeb15066b141cdff5541e0ec8e, made available under GPLv2
by Nick Clifton.
PR: 198824
MFC after: 1 week
Security: CVE-2014-8501
Security: CVE-2014-8502
From binutils commit 0102ea8cec5fc509bba6c91df61b7ce23a799d32, made
available under GPLv2 by Nick Clifton.
PR: 198824
MFC after: 1 week
Security: CVE-2014-8503
This fixes clang-built binaries on a gcc powerpc64 world. Gets us one step
closer to a clang-built world. The same change was made in later upstream
binutils.
Submitted by: rdivacky
MFC after: 2 weeks
Enable the in-tree binutils to assemble and disassemble amd64 FSGSBASE
instructions (rdfsbase, rdgsbase, wrfsbase, wrgsbase), used in the base
system since r322763.
This gives one last gasp for in-tree gcc, and provides a small
enhancement for in-tree binutils objdump.
Reviewed by: dim, kib
Approved by: markj (mentor)
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D12222
error: implicit conversion from 'bfd_vma' (aka 'unsigned long long')
to 'int' changes value from 18446744073709551615 to -1
return BFD_ALIGN (ret, 16);
~~~~~~ ^~~~~~~~~~~~~~~~~~~
note: expanded from macro 'BFD_ALIGN'
: ~ (bfd_vma) 0)
^~~~~~~~~~~~~
Sponsored by: The FreeBSD Foundation
This is no-op and only for reference: the S/390 port seems to be elusive
in the BSDs so it is convenient to keep some trace from past efforts.
It is likely newer attempts will focus on a newer toolchain using clang
instead.
Obtained from: Perforce depot/projects/s390
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
We should never end up executing the inter-function padding, so we
are better off faulting than silently carrying on to whatever function
happens to be next.
Note that LLD will soon do this by default (although it currently pads
with zeros).
Reviewed by: dim, kib
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D10047
The rfdi instruction is part of the e500mc and derivative cores. It came into
binutils in a GPLv3 patch, along with the rest of the e500mc instruction set.
Currently only rfdi is planned to be used, so rather than attempt to backport
the full patch, take a surgical route and add instructions as needed.
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
Initialize l_sec_contents to make sure that free(l_sec_contents) is called
on valid pointers.
Obtained from: OpenBSD (partial CVS rev 1.18)
MFC after: 5 days
Summary:
The Freescale e500v2 PowerPC core does not use a standard FPU.
Instead, it uses a Signal Processing Engine (SPE)--a DSP-style vector processor
unit, which doubles as a FPU. The PowerPC SPE ABI is incompatible with the
stock powerpc ABI, so a new MACHINE_ARCH was created to deal with this.
Additionaly, the SPE opcodes overlap with Altivec, so these are mutually
exclusive. Taking advantage of this fact, a new file, powerpc/booke/spe.c, was
created with the same function set as in powerpc/powerpc/altivec.c, so it
becomes effectively a drop-in replacement. setjmp/longjmp were modified to save
the upper 32-bits of the now-64-bit GPRs (upper 32-bits are only accessible by
the SPE).
Note: This does _not_ support the SPE in the e500v1, as the e500v1 SPE does not
support double-precision floating point.
Also, without a new MACHINE_ARCH it would be impossible to provide binary
packages which utilize the SPE.
Additionally, no work has been done to support ports, work is needed for this.
This also means no newer gcc can yet be used. However, gcc's powerpc support
has been refactored which would make adding a powerpcspe-freebsd target very
easy.
Test Plan:
This was lightly tested on a RouterBoard RB800 and an AmigaOne A1222
(P1022-based) board, compiled against the new ABI. Base system utilities
(/bin/sh, /bin/ls, etc) still function appropriately, the system is able to boot
multiuser.
Reviewed By: bdrewery, imp
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D5683
The partition_name field is an array, so can never be NULL itself. Check only
the first byte instead.
This was found when test building with clang, but I'm not sure how it passes
gcc's warnings either.
libiberty currently defines the prototype for basename() itself instead
of using <libgen.h>. It still uses the BSD-style prototype instead of
the POSIX one, meaning that if FreeBSD would switch over to the POSIX
one, you wouldn't be able to use libiberty.h and libgen.h in a single
source file. It turns out that kgdb does this. Patch up libiberty to
just include <libgen.h>.
I'm currently talking to upstream to see whether we can come up with a
more complete solution that could be integrated, but for our
unmaintained copy of GDB in base, let's just apply the simplest
workaround possible.
Reviewed by: pfg
Differential Revision: https://reviews.freebsd.org/D6631
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
"invalid string offset 65521 >= 27261 for section `.strtab'". for object
files produced by recent versions of clang.
In BFD's elf_create_symbuf() function, the size of the symbol buffer
('ssymbuf') is not calculated correctly, and the initial value for the
'ssym' variable is off by one, since 'ssymbuf' has shndx_count + 1
members.
MFC after: 1 week
When the armv6 support was imported from a project branch, this complex
conditional logic and related #define'd values came along, but it's really
not clear what the intent of it all was. The effect, however, was that
OSABI was always set to zero, which is "UNIX System V ABI". Having the wrong
value there causes pkg(8) to avoid looking inside arm elf binaries to
determine shared-lib required/provides info for packaging.
entries. This fixes the segfaults in arm userland code compiled with
-march= or -mcpu= values that allow the compiler to generate movw/movt
sequences to load 32-bit constants.
however it will fail to output them if the type is not set correctly. This
can happen when it finds an attribute it hasn't seen before, for example
when building shared objects it will use the attributes from crti.o, hwever
this file has no attributes set.
Differential Revision: https://reviews.freebsd.org/D2413
Reviewed by: imp
to include the Unaligned Access and Floating-point Half-precision
attributes. the former marks ELF objects that may access ARMv6 style
unaligned data, the latter that the binary uses the VFPv3/Advanced SIMD
half-precision extension.
These may be emmitted by clang so it's best to print a warning when the
linker hits one of them.
Differential Revision: http://reviews.freebsd.org/D2194
Submitted by: Michal Meloun <meloun@miracle.cz>
MFC after: 1 week
bfd_dwarf2_find_line() calls find_line() with NULL functionname_ptr,
which resulted in a crash on certain ELF objects.
This change was implemented independently from upstream binutils, but
I have checked that the crash does not happen there.
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
order as the .init_array section. Finalisation routines need to be called
in the opposite order as their corresponding initialisation routines but
rtld(1) handles that by calling the function pointers in .fini_array in
reverse order.
Reviewed by: kib
MFC after: 2 weeks
