| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Upgrade our copies of clang, llvm, lldb, compiler-rt and libc++ to 3.9.0
release, and add lld 3.9.0. Also completely revamp the build system for
clang, llvm, lldb and their related tools.
Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11
support to build; see UPDATING for more information.
Release notes for llvm, clang and lld are available here:
<http://llvm.org/releases/3.9.0/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.9.0/tools/clang/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.9.0/tools/lld/docs/ReleaseNotes.html>
Thanks to Ed Maste, Bryan Drewery, Andrew Turner, Antoine Brodin and Jan
Beich for their help.
Relnotes: yes
MFC r309147:
Pull in r282174 from upstream llvm trunk (by Krzysztof Parzyszek):
[PPC] Set SP after loading data from stack frame, if no red zone is
present
Follow-up to r280705: Make sure that the SP is only restored after
all data is loaded from the stack frame, if there is no red zone.
This completes the fix for
https://llvm.org/bugs/show_bug.cgi?id=26519.
Differential Revision: https://reviews.llvm.org/D24466
Reported by: Mark Millard
PR: 214433
MFC r309149:
Pull in r283060 from upstream llvm trunk (by Hal Finkel):
[PowerPC] Refactor soft-float support, and enable PPC64 soft float
This change enables soft-float for PowerPC64, and also makes
soft-float disable all vector instruction sets for both 32-bit and
64-bit modes. This latter part is necessary because the PPC backend
canonicalizes many Altivec vector types to floating-point types, and
so soft-float breaks scalarization support for many operations. Both
for embedded targets and for operating-system kernels desiring
soft-float support, it seems reasonable that disabling hardware
floating-point also disables vector instructions (embedded targets
without hardware floating point support are unlikely to have Altivec,
etc. and operating system kernels desiring not to use floating-point
registers to lower syscall cost are unlikely to want to use vector
registers either). If someone needs this to work, we'll need to
change the fact that we promote many Altivec operations to act on
v4f32. To make it possible to disable Altivec when soft-float is
enabled, hardware floating-point support needs to be expressed as a
positive feature, like the others, and not a negative feature,
because target features cannot have dependencies on the disabling of
some other feature. So +soft-float has now become -hard-float.
Fixes PR26970.
Pull in r283061 from upstream clang trunk (by Hal Finkel):
[PowerPC] Enable soft-float for PPC64, and +soft-float -> -hard-float
Enable soft-float support on PPC64, as the backend now supports it.
Also, the backend now uses -hard-float instead of +soft-float, so set
the target features accordingly.
Fixes PR26970.
Reported by: Mark Millard
PR: 214433
MFC r309212:
Add a few missed clang 3.9.0 files to OptionalObsoleteFiles.
MFC r309262:
Fix packaging for clang, lldb and lld 3.9.0
During the upgrade of clang/llvm etc to 3.9.0 in r309124, the PACKAGE
directive in the usr.bin/clang/*.mk files got dropped accidentally.
Restore it, with a few minor changes and additions:
* Correct license in clang.ucl to NCSA
* Add PACKAGE=clang for clang and most of the "ll" tools
* Put lldb in its own package
* Put lld in its own package
Reviewed by: gjb, jmallett
Differential Revision: https://reviews.freebsd.org/D8666
MFC r309656:
During the bootstrap phase, when building the minimal llvm library on
PowerPC, add lib/Support/Atomic.cpp. This is needed because upstream
llvm revision r271821 disabled the use of std::call_once, which causes
some fallback functions from Atomic.cpp to be used instead.
Reported by: Mark Millard
PR: 214902
MFC r309835:
Tentatively apply https://reviews.llvm.org/D18730 to work around gcc PR
70528 (bogus error: constructor required before non-static data member).
This should fix buildworld with the external gcc package.
Reported by: https://jenkins.freebsd.org/job/FreeBSD_HEAD_amd64_gcc/
MFC r310194:
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to
3.9.1 release.
Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11
support to build; see UPDATING for more information.
Release notes for llvm, clang and lld will be available here:
<http://releases.llvm.org/3.9.1/docs/ReleaseNotes.html>
<http://releases.llvm.org/3.9.1/tools/clang/docs/ReleaseNotes.html>
<http://releases.llvm.org/3.9.1/tools/lld/docs/ReleaseNotes.html>
Relnotes: yes
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When MAKEOBJDIRPREFIX points to a case-insensitive file system, the
build can break when different source files create the same object
files (case-insensitivity speaking). This is the case for object
files compiled with -fpic and shared libraries. The former uses
an extension of ".So", and the latter an extension ".so". Rename
shared object files from *.So to *.pico to match what NetBSD does.
Also:
o Compile _Exit.c as C99_Exit.c, as it conflicts with _exit.s
o Add entry to UPDATING
o Document .pico extension
|
|
|
|
|
|
|
| |
Minor wording improvements to the note about pipe(2) removal.
Approved by: re (gjb)
Sponsored by: DARPA, AFRL
|
|
|
|
|
|
|
|
|
| |
- Enable MALLOC_PRODUCTION
- Default dumpdev=NO
- Remove UPDATING entry regarding debugging features
Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation
|
|
|
|
| |
Approved by: re (implicit)
|
|
|
|
|
| |
Approved by: re (gjb)
Sponsored by: DARPA, AFRL
|
|
|
|
|
|
| |
Reported by: rpokala
MFC after: Never
Sponsored by: Spectra Logic Corp
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sys/cam/scsi/scsi_xpt.c
Strip leading spaces off of a SCSI disk's reported serial number
when populating the CAM serial number. This affects the output of
"diskinfo -v" and the names of /dev/diskid/DISK-* device nodes,
among other things.
SPC5r05 says that the Product Serial Number field from the Unit
Serial Number VPD page is right-aligned. So any leading spaces are
not part of the actual serial number. Most devices don't left-pad
their serial numbers, but some do. In particular, the SN VPD page
that an LSI HBA emulates for a SATA drive contains enough
left-padding to fill a 20-byte field.
UPDATING
Add a note to UPDATING, because some users may have to update
/etc/fstab or geom labels.
Reviewed by: ken, mav
MFC after: Never
Sponsored by: Spectra Logic Corp
Differential Revision: https://reviews.freebsd.org/D6516
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a bit_count function, which efficiently counts the number of bits set in
a bitstring.
sys/sys/bitstring.h
tests/sys/sys/bitstring_test.c
share/man/man3/bitstring.3
Add bit_alloc
sys/kern/subr_unit.c
Use bit_count instead of a naive counting loop in check_unrhdr, used
when INVARIANTS are enabled. The userland test runs about 6x faster
in a generic build, or 8.5x faster when built for Nehalem, which has
the POPCNT instruction.
sys/sys/param.h
Bump __FreeBSD_version due to the addition of bit_alloc
UPDATING
Add a note about the ABI incompatibility of the bitstring(3)
changes, as suggested by lidl.
Suggested by: gibbs
Reviewed by: gibbs, ngie
MFC after: 9 days
X-MFC-With: 299090, 300538
Relnotes: yes
Sponsored by: Spectra Logic Corp
Differential Revision: https://reviews.freebsd.org/D6255
|
|
|
|
| |
describing the armv6hf->armv6 change.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Specification, Version 2, but marked as legacy, and have been removed from
later specifications. After 12 years it is time to remove them from new
architectures when the main use for sbrk is an invalid method to attempt
to find how much memory has been allocated from malloc.
There are a few places in the tree that still call sbrk, however they are
not used on arm64. They will need to be fixed to cross build from arm64,
but these will be fixed in a follow up commit.
Old copies of binutils from ports called into sbrk, however this has been
fixed around 6 weeks ago. It is advised to update binutils on arm64 before
installing a world that includes this change.
Reviewed by: brooks, emaste
Obtained from: brooks
Relnotes: yes
Sponsored by: ABT Systems Ltd
Differential Revision: https://reviews.freebsd.org/D6464
|
|
|
|
|
|
|
| |
Allow CPUTYPE=soft to build the current soft-float abi libraries.
Add UPDATING entry to announce this.
Approved by: re@ (gjb)
|
|
|
|
|
|
|
|
|
|
|
| |
Kernel installs always override KMODDIR when installing modules, so
this default setting is only used for standalone module builds. Many
out-of-tree modules manually override KMODDIR already to avoid placing
modules in /boot/kernel. This now makes that behavior the default.
Discussed on: arch@
Reviewed by: imp
Relnotes: yes
|
|
|
|
| |
No functional change.
|
| |
|
| |
|
|
|
|
|
|
|
| |
Reviewed by: emaste, hselasky (partial), brooks (brief)
Discussed on: arch@
Sponsored by: EMC / Isilon Storage Division
Differential Revision: https://reviews.freebsd.org/D5742
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On some architectures, u_long isn't large enough for resource definitions.
Particularly, powerpc and arm allow 36-bit (or larger) physical addresses, but
type `long' is only 32-bit. This extends rman's resources to uintmax_t. With
this change, any resource can feasibly be placed anywhere in physical memory
(within the constraints of the driver).
Why uintmax_t and not something machine dependent, or uint64_t? Though it's
possible for uintmax_t to grow, it's highly unlikely it will become 128-bit on
32-bit architectures. 64-bit architectures should have plenty of RAM to absorb
the increase on resource sizes if and when this occurs, and the number of
resources on memory-constrained systems should be sufficiently small as to not
pose a drastic overhead. That being said, uintmax_t was chosen for source
clarity. If it's specified as uint64_t, all printf()-like calls would either
need casts to uintmax_t, or be littered with PRI*64 macros. Casts to uintmax_t
aren't horrible, but it would also bake into the API for
resource_list_print_type() either a hidden assumption that entries get cast to
uintmax_t for printing, or these calls would need the PRI*64 macros. Since
source code is meant to be read more often than written, I chose the clearest
path of simply using uintmax_t.
Tested on a PowerPC p5020-based board, which places all device resources in
0xfxxxxxxxx, and has 8GB RAM.
Regression tested on qemu-system-i386
Regression tested on qemu-system-mips (malta profile)
Tested PAE and devinfo on virtualbox (live CD)
Special thanks to bz for his testing on ARM.
Reviewed By: bz, jhb (previous)
Relnotes: Yes
Sponsored by: Alex Perez/Inertial Computing
Differential Revision: https://reviews.freebsd.org/D4544
|
|
|
|
|
| |
Discussed on: arch
Sponsored by: EMC / Isilon Storage Division
|
|
|
|
| |
the kernel, on amd64.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
release.
Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11
support to build; see UPDATING for more information.
Release notes for llvm and clang will soon be available here:
<http://llvm.org/releases/3.8.0/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.8.0/tools/clang/docs/ReleaseNotes.html>
Thanks to Ed Maste, Roman Divacky, Davide Italiano and Antoine Brodin
for their help.
Relnotes: yes
|
|
|
|
| |
Suggested by: maxim
|
|
|
|
| |
Reported by: dhw
|
|
|
|
|
|
|
|
|
|
|
|
| |
As of r295661 elfcopy supports PE format for EFI boot binaries and is a
viable objcopy implementation for the base system and ports.
The (temporary) src.conf knob WITHOUT_ELFCOPY_AS_OBJCOPY knob may be set
to obtain the GNU version if necessary.
PR: 207091 [exp-run]
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change 294329 removed the ability to build ZFS pools that are backed by
zvols, because having that ability (even if it's not used) leads to
deadlocks. By popular demand, I'm adding an off-by-default sysctl to
reenable that ability.
Reviewed by: lidl, delphij
MFC after: Never
Sponsored by: Spectra Logic Corp
Differential Revision: https://reviews.freebsd.org/D4998
|
|
|
|
| |
Noticed by: glebius
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit, fix a core dump on ypldap(8) related with memory allocation.
Also an example of how to set the ypldap.conf(5) properly is added to
examples files.
A new user _ypldap is required to be able to run ypldap(8) as well as
in a chroot mode.
Reviewed by: rodrigc (mentor), bjk
Approved by: bapt (mentor)
Relnotes: Yes
Sponsored by: gandi.net
Differential Revision: https://reviews.freebsd.org/D4744
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pxeboot in tftp loader mode (when built with LOADER_TFTP_SUPPORT) now
prefix all the path to open with the path obtained via the option 'root-path'
directive.
This allows to be able to use the traditional content /boot out of box. Meaning
it now works pretty much like all other loaders. It simplifies hosting hosting
multiple version of FreeBSD on a tftp server.
As a consequence, pxeboot does not look anymore for a pxeboot.4th (which was
never provided)
Note: that pxeboot in tftp loader mode is not built by default.
Reviewed by: rpokala
Relnotes: yes
Sponsored by: Gandi.net
Differential Revision: https://reviews.freebsd.org/D4590
|
|
|
|
| |
warnings. Make a note of it to inform people how to get around it.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Debug data files are now built by default with 'make buildworld' and
installed with 'make installworld'. This facilitates debugging but
requires more disk space both during the build and for the installed
world. Debug files may be disabled by setting WITHOUT_DEBUG_FILES=yes
in src.conf(5).
Reviewed by: bdrewery, eadler, vangyzen
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D4018
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
integration.
Say it with me, "I will not chain commands with && in Makefiles"
This was originally fixed and explained quite well by bde@ in r36074. The
initial bmake integration caused 'set -e' to stop being used which lead to
r252419. Later 'set -e' expectations were fixed with bmake in r254980.
Because of the && here, errors would be ignored when building in parallel and
a dependency failed. Such as bootstrap-tools since it builds everything in
parallel. If any tool failed in obj/depend/all, it would just ignore the error
and continue to build. This later would result in cascaded errors that only
confused the real issue. This could also cause commands after the failed
command to still execute, leading to more confusion.
This should be fine if the command is in a sub-shell such as: (cmd1 && cmd2)
This reverts r252419.
MFC after: 1 week
Sponsored by: EMC / Isilon Storage Division
|
| |
|
|
|
|
| |
Add a missing full stop
|
| |
|
|
|
|
| |
Submitted by: ngie
|
|
|
|
|
|
|
| |
inconsistency when installing new locales and may also result in failures
when reinstalling after having run make delete-old (due to previous
inconsistencies) for now recommand removing all locales until install(1) is
fixed
|
|
|
|
| |
Reported by: girgen
|
|
|
|
| |
now supporting correctly string collation
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bmake has a documented feature of '-N' to skip executing commands which is
specifically intended for debugging top-level builds and not recursing into
sub-directories. This matches the older 'make -n' behavior we added which made
'-n -n' the recursing target and '-n' a non-recursing target.
Removing the '-n -n' feature allows the build to work as documented in
the bmake manpage with '-n' and '-N'. The older '-n -n' feature was also
not documented anywhere that I could see.
Note that the ${_+_} var is still needed as currently bmake incorrectly
executes '+' commands when '-N' is specified.
The '-n' and '-n -n' features were broken for several reasons prior to this.
r251748 made '_+_' never expand with '-n -n' which resulted in many
sub-directories not being visited until fixed 2 years later in r288391, and
many targets were given .MAKE over the past few years which resulted in
non-sub-make commands, such as rm and ln and mtree, to be executed.
This should also allow removing some indirection hacks in bsd.subdir.mk and
other cases of .USE that have a .MAKE by using '+'.
Sponsored by: EMC / Isilon Storage Division
Discussed on: arch@ (mostly silence)
|
|
|
|
| |
Difference appeared much less drammatic then seemed originally.
|
|
|
|
| |
send/receive support in ZFS.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
target. This is the feeder for mergemaster / etcupdate. This change
makes installworld/mergemaster/etcupdate behave the same regardless of
whether SENDMAIL_MC or SENDMAIL_CF is used.
If you use a custom SENDMAIL_MC/CF in make.conf and excluded it from
mergemaster.rc/etcupdate.conf to work around the conflicts, you may wish
to revert that or change it from 'ignore' to 'always install'.
If you do not use a custom SENDMAIL_MC/CF, there should be no change in
behavior.
|
|
|
|
|
| |
We got new ATA stack in FreeBSD 8.x, switched to it at 9.x, completely
removed old stack at 10.x, so at 11.x it is time to remove compat shims.
|
| |
|