#
368827 |
|
30-Dec-2020 |
hselasky |
MFC r368659 and r368664: Improve handling of alternate settings in the USB stack.
Allow setting the alternate interface number to fail when there is only one alternate setting present, to comply with the USB specification.
Refactor how iface->num_altsetting is computed.
Bump the __FreeBSD_version due to change of core USB structure.
PR: 251856 Submitted by: Ma, Horse <Shichun.Ma@dell.com> Sponsored by: Mellanox Technologies // NVIDIA Networking
Git Hash: d511b855ed55bf72e88f7b00fa1268379f30a792 Git Author: hselasky@FreeBSD.org
|
#
367513 |
|
09-Nov-2020 |
delphij |
Bump __FreeBSD_version after ptsname_r addition.
|
#
366889 |
|
20-Oct-2020 |
hselasky |
MFC r349277 and r366669: Implement more RCU list functions in the LinuxKPI.
Differential Revision: https://reviews.freebsd.org/D20719 Sponsored by: Mellanox Technologies // NVIDIA Networking
|
#
366879 |
|
20-Oct-2020 |
hselasky |
MFC r347596 and r366432: Populate the acquire context field of a ww_mutex in the LinuxKPI. Bump the FreeBSD version to force recompilation of external kernel modules.
Differential Revision: https://reviews.freebsd.org/D19565 Differential Revision: https://reviews.freebsd.org/D26657 Submitted by: greg_unrelenting.technology (Greg V) Sponsored by: Mellanox Technologies // NVIDIA Networking
|
#
365661 |
|
12-Sep-2020 |
dim |
MFC r364753:
Add atomic and bswap functions to libcompiler_rt
There have been several mentions on our mailing lists about missing atomic functions in our system libraries (e.g. __atomic_load_8 and friends), and recently I saw __bswapdi2 and __bswapsi2 mentioned too.
To address this, add implementations for the functions from compiler-rt to the system compiler support libraries, e.g. libcompiler_rt.a and and libgcc_s.so.
This also needs a small fixup in compiler-rt's atomic.c, to ensure that 32-bit mips can build correctly.
Bump __FreeBSD_version to make it easier for port maintainers to detect when these functions were added.
Differential Revision: https://reviews.freebsd.org/D26159
MFC r364782:
After r364753, there should be no need to suppress -Watomic-alignment warnings anymore for compiler-rt's atomic.c. This occurred because the IS_LOCK_FREE_8 macro was not correctly defined to 0 for mips, and this caused the compiler to emit a runtime call to __atomic_is_lock_free(), and that triggers the warning.
MFC r365509:
Follow-up r364753 by enabling compiler-rt's atomic implementation only for clang, as it uses clang specific builtins, and does not compile correctly with gcc. Note that gcc packages usually come with their own libatomic, providing these primitives.
MFC r365588:
Follow-up r364753 by only using arm's stdatomic.c implementation, as it already covers the functions in compiler-rt's atomic.c, leading to conflicts when linking.
PR: 230888
|
#
365471 |
|
08-Sep-2020 |
dim |
MFC r364753:
Add atomic and bswap functions to libcompiler_rt
There have been several mentions on our mailing lists about missing atomic functions in our system libraries (e.g. __atomic_load_8 and friends), and recently I saw __bswapdi2 and __bswapsi2 mentioned too.
To address this, add implementations for the functions from compiler-rt to the system compiler support libraries, e.g. libcompiler_rt.a and and libgcc_s.so.
This also needs a small fixup in compiler-rt's atomic.c, to ensure that 32-bit mips can build correctly.
Bump __FreeBSD_version to make it easier for port maintainers to detect when these functions were added.
PR: 230888 Differential Revision: https://reviews.freebsd.org/D26159
MFC r364782:
After r364753, there should be no need to suppress -Watomic-alignment warnings anymore for compiler-rt's atomic.c. This occurred because the IS_LOCK_FREE_8 macro was not correctly defined to 0 for mips, and this caused the compiler to emit a runtime call to __atomic_is_lock_free(), and that triggers the warning.
|
#
364391 |
|
19-Aug-2020 |
hselasky |
MFC r364109: Need to clone the task struct fields related to RCU aswell in the LinuxKPI after r359727. This fixes a minor regression issue. Else the priority tracking won't work properly when both sleepable and non-sleepable RCU is in use on the same thread.
Bump the __FreeBSD_version to force recompilation of external kernel modules.
PR: 242272 Sponsored by: Mellanox Technologies
|
#
363792 |
|
03-Aug-2020 |
hselasky |
MFC r363077: Implement the array_size() function in the LinuxKPI. This function basically multiplies its two arguments and returns SIZE_MAX if the result overflows the size_t type. Else the product of the two arguments is returned.
Bump the FreeBSD_version to mitigate issues with existing implementation of array_size() in drm-devel-kmod.
Discussed with: manu@ Sponsored by: Mellanox Technologies
|
#
363496 |
|
24-Jul-2020 |
dim |
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 10.0.1 final (aka llvmorg-10.0.1-0-gef32c611aa2).
MFC r360702:
Merge commit 4ca2cad94 from llvm git (by Justin Hibbits):
[PowerPC] Add clang -msvr4-struct-return for 32-bit ELF
Summary:
Change the default ABI to be compatible with GCC. For 32-bit ELF targets other than Linux, Clang now returns small structs in registers r3/r4. This affects FreeBSD, NetBSD, OpenBSD. There is no change for 32-bit Linux, where Clang continues to return all structs in memory.
Add clang options -maix-struct-return (to return structs in memory) and -msvr4-struct-return (to return structs in registers) to be compatible with gcc. These options are only for PPC32; reject them on PPC64 and other targets. The options are like -fpcc-struct-return and -freg-struct-return for X86_32, and use similar code.
To actually return a struct in registers, coerce it to an integer of the same size. LLVM may optimize the code to remove unnecessary accesses to memory, and will return i32 in r3 or i64 in r3:r4.
Fixes PR#40736
Patch by George Koehler!
Reviewed By: jhibbits, nemanjai Differential Revision: https://reviews.llvm.org/D73290
Requested by: jhibbits
MFC r361410:
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp llvmorg-10.0.1-rc1-0-gf79cd71e145 (aka 10.0.1 rc1).
MFC r362235 (by kp):
llvm: Default to -mno-relax on RISC-V
Compiling on a RISC-V system fails with 'relocation R_RISCV_ALIGN requires unimplemented linker relaxation; recompile with -mno-relax'.
Our default linker (ld.lld) doesn't support relaxation, so default to no-relax so we don't generate object files the linker can't handle.
Reviewed by: mhorne Sponsored by: Axiado Differential Revision: https://reviews.freebsd.org/D25210
MFC r362445:
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp llvmorg-10.0.0-97-g6f71678ecd2 (not quite 10.0.1 rc2, as more fixes are still pending).
MFC r362587 (by cem):
Add WITH_CLANG_FORMAT option
clang-format is enabled conditional on either WITH_CLANG_EXTRAS or WITH_CLANG_FORMAT. Some sources in libclang are build conditional on either rule, and obviously the clang-format binary itself depends on the rule.
clang-format could still use a manual page.
Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D25427
MFC r362609:
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp llvmorg-10.0.0-129-gd24d5c8e308. Getting closer to 10.0.1-rc2.
MFC r362679:
Regenerate ReStructuredText based manpages for llvm-project tools:
* bugpoint.1 * clang.1 * llc.1 * lldb.1 * lli.1 * llvm-ar.1 * llvm-as.1 * llvm-bcanalyzer.1 * llvm-cov.1 * llvm-diff.1 * llvm-dis.1 * llvm-dwarfdump.1 * llvm-extract.1 * llvm-link.1 * llvm-mca.1 * llvm-nm.1 * llvm-pdbutil.1 * llvm-profdata.1 * llvm-symbolizer.1 * llvm-tblgen.1 * opt.1
Add newly generated manpages for:
* llvm-addr2line.1 (this is an alias of llvm-symbolizer) * llvm-cxxfilt.1 * llvm-objcopy.1 * llvm-ranlib.1 (this is an alias of llvm-ar)
Note that llvm-objdump.1 is an exception, as upstream has both a plain .1 file, and a .rst variant. These will have to be reconciled upstream first.
MFC r362680:
Follow-up to r362679, add more entries to OptionalObsoleteFiles.inc
MFC r362719:
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp llvmorg-10.0.1-rc2-0-g77d76b71d7d.
Also add a few more llvm utilities under WITH_CLANG_EXTRAS:
* llvm-dwp, a utility for merging DWARF 5 Split DWARF .dwo files into .dwp (DWARF package files) * llvm-size, a size(1) replacement * llvm-strings, a strings(1) replacement
MFC r362733:
Remove older llvm-ranlib.1 entry from ObsoleteFiles.inc, as it has gotten its own manpage now, and should be no longer be removed by "make delete-old".
MFC r362734:
Fix llvm-strings.1 not installing, this was a copy/paste error.
MFC r363401:
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 10.0.1 final (aka llvmorg-10.0.1-0-gef32c611aa2).
There were no changes since rc2, except in the upstream regression tests, which we do not ship.
Relnotes: yes
|
#
362919 |
|
04-Jul-2020 |
delphij |
Bump __FreeBSD_version after making liblzma to use libmd implementation of SHA256.
|
#
362320 |
|
18-Jun-2020 |
hselasky |
MFC r361724: Implement __is_constexpr() function macro in the LinuxKPI. Bump the FreeBSD version.
Sponsored by: Mellanox Technologies
|
#
360805 |
|
08-May-2020 |
gjb |
- Update stable/11 from PRERELEASE to STABLE after releng/11.4 had branched. - Bump __FreeBSD_version.
Approved by: re (implicit) Sponsored by: Rubicon Communications, LLC (netgate.com)
|
#
360784 |
|
07-May-2020 |
dim |
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp llvmorg-10.0.0-0-gd32170dbd5b (aka 10.0.0 release), and a number of follow-ups.
MFC r356479 (by bdragon):
[PowerPC] Fix libllvmminimal build when building from powerpc64 ELFv1.
When bootstrapping on powerpc64 ELFv1, it is necessary to use binutils ld.bfd from ports for the bootstrap, as this is the only modern linker for ELFv1 host tools.
As binutils ld.bfd is rather strict in its handling of undefined symbols, it is necessary to pull in Support/Atomic.cpp to avoid an undefined symbol.
Reviewed by: dim, emaste Sponsored by: Tag1 Consulting, Inc. Differential Revision: https://reviews.freebsd.org/D23072
MFC r356930:
Add more Subversion mergeinfo bootstrap information, to hopefully increase the probability of merging in vendor changes.
MFC r358408 (by brooks):
Merge commit 7214f7a79 from llvm git (by Sam Elliott):
[RISCV] Lower llvm.trap and llvm.debugtrap
Summary: Until this commit, these have lowered to a call to abort().
`llvm.trap()` now lowers to `unimp`, which should trap on all systems.
`llvm.debugtrap()` now lowers to `ebreak`, which is exactly what this instruction is for.
Reviewers: asb, luismarques
Reviewed By: asb
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D69390
This fixes miscompilation resulting in linking failures with INVARIANTS disabled.
Reviewed by: dim Differential Revision: https://reviews.freebsd.org/D23857
MFC r358851:
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 10.0.0-rc3 c290cb61fdc.
Release notes for llvm, clang, lld and libc++ 10.0.0 will become available here:
https://releases.llvm.org/10.0.0/docs/ReleaseNotes.html https://releases.llvm.org/10.0.0/tools/clang/docs/ReleaseNotes.html https://releases.llvm.org/10.0.0/tools/lld/docs/ReleaseNotes.html https://releases.llvm.org/10.0.0/projects/libcxx/docs/ReleaseNotes.html
PR: 244251
MFC r358854:
Add one additional file to libllvmminimal, to help the ppc64 bootstrap.
Reported by: bdragon PR: 244251
MFC r358857:
Move another file in libllvm from sources required for world, to sources required for bootstrap, as the PowerPC builds need this.
Reported by: bdragon PR: 244251
MFC r359082:
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp llvmorg-10.0.0-rc4-5-g52c365aa9ca. The actual release should follow Real Soon Now.
PR: 244251
MFC r359084:
Merge commit 00925aadb from llvm git (by Fangrui Song):
[ELF][PPC32] Fix canonical PLTs when the order does not match the PLT order
Reviewed By: Bdragon28
Differential Revision: https://reviews.llvm.org/D75394
This is needed to fix miscompiled canonical PLTs on ppc32/lld10.
Requested by: bdragon Differential Revision: https://reviews.freebsd.org/D24109
MFC r359085:
Merge commit 315f8a55f from llvm git (by Fangrui Song):
[ELF][PPC32] Don't report "relocation refers to a discarded section" for .got2
Similar to D63182 [ELF][PPC64] Don't report "relocation refers to a discarded section" for .toc
Reviewed By: Bdragon28
Differential Revision: https://reviews.llvm.org/D75419
This is needed to fix compile errors when building for ppc32/lld10.
Requested by: bdragon Differential Revision: https://reviews.freebsd.org/D24110
MFC r359086:
Merge commit b8ebc11f0 from llvm git (by Sanjay Patel):
[EarlyCSE] avoid crashing when detecting min/max/abs patterns (PR41083)
As discussed in PR41083: https://bugs.llvm.org/show_bug.cgi?id=41083 ...we can assert/crash in EarlyCSE using the current hashing scheme and instructions with flags.
ValueTracking's matchSelectPattern() may rely on overflow (nsw, etc) or other flags when detecting patterns such as min/max/abs composed of compare+select. But the value numbering / hashing mechanism used by EarlyCSE intersects those flags to allow more CSE.
Several alternatives to solve this are discussed in the bug report. This patch avoids the issue by doing simple matching of min/max/abs patterns that never requires instruction flags. We give up some CSE power because of that, but that is not expected to result in much actual performance difference because InstCombine will canonicalize these patterns when possible. It even has this comment for abs/nabs:
/// Canonicalize all these variants to 1 pattern. /// This makes CSE more likely.
(And this patch adds PhaseOrdering tests to verify that the expected transforms are still happening in the standard optimization pipelines.
I left this code to use ValueTracking's "flavor" enum values, so we don't have to change the callers' code. If we decide to go back to using the ValueTracking call (by changing the hashing algorithm instead), it should be obvious how to replace this chunk.
Differential Revision: https://reviews.llvm.org/D74285
This fixes an assertion when building the math/gsl port on PowerPC64.
Requested by: pkubja
MFC r359087:
Merge commit 585a3cc31 from llvm git (by me):
Fix -Wdeprecated-copy-dtor and -Wdeprecated-dynamic-exception-spec warnings.
Summary: The former are like:
libcxx/include/typeinfo:322:11: warning: definition of implicit copy constructor for 'bad_cast' is deprecated because it has a user-declared destructor [-Wdeprecated-copy-dtor] virtual ~bad_cast() _NOEXCEPT; ^ libcxx/include/typeinfo:344:11: note: in implicit copy constructor for 'std::bad_cast' first required here throw bad_cast(); ^
Fix these by adding an explicitly defaulted copy constructor.
The latter are like:
libcxx/include/codecvt:105:37: warning: dynamic exception specifications are deprecated [-Wdeprecated-dynamic-exception-spec] virtual int do_encoding() const throw(); ^~~~~~~
Fix these by using the _NOEXCEPT macro instead.
Reviewers: EricWF, mclow.lists, ldionne, #libc
Reviewed By: EricWF, #libc
Subscribers: dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D76150
This is because we use -Wsystem-headers during buildworld, and the two warnings above are now triggered by default with clang 10, preventing most C++ code from compiling without NO_WERROR.
Requested by: brooks Differential Revision: https://reviews.freebsd.org/D24049
MFC r359333:
Merge commit f0990e104 from llvm git (by Justin Hibbits):
[PowerPC]: e500 target can't use lwsync, use msync instead
The e500 core has a silicon bug that triggers an illegal instruction program trap on any sync other than msync. Other cores will typically ignore illegal sync types, and the documentation even implies that the 'illegal' bits are ignored.
Address this hardware deficiency by only using msync, like the PPC440.
Differential Revision: https://reviews.llvm.org/D76614
Requested by: jhibbits
MFC r359334:
Merge commit 459e8e948 from llvm git (by Justin Hibbits):
[PowerPC]: Don't allow r0 as a target for LD_GOT_TPREL_L/32
Summary: The linker is free to relax this (relocation R_PPC_GOT_TPREL16) against R_PPC_TLS, if it sees fit (initial exec to local exec). If r0 is used, this can generate execution-invalid code (converts to 'addi %rX, %r0, FOO, which translates in PPC-lingo to li %rX, FOO). Forbid this instead.
This fixes static binaries using locales on FreeBSD/powerpc (tested on FreeBSD/powerpcspe).
Reviewed By: nemanjai Differential Revision: https://reviews.llvm.org/D76662
Requested by: jhibbits
MFC r359338:
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp llvmorg-10.0.0-0-gd32170dbd5b (aka 10.0.0 release).
PR: 244251
MFC r359506 (by emaste):
lldb: stop excluding bindings/ subdir
With liblua in the tree we should be able to enable lldb's lua scripting. We'll need the files in bindings/, so start by allowing them to come in with the next import.
Approved by: dim Sponsored by: The FreeBSD Foundation
MFC r359578:
Merge once more from ^/vendor/llvm-project/release-10.x, to get the lldb/bindings directory, which will be used to provide lua bindings for lldb.
Requested by: emaste
MFC r359826:
Merge commit 30588a739 from llvm git (by Erich Keane):
Make target features check work with ctor and dtor-
The problem was reported in PR45468, applying target features to an always_inline constructor/destructor runs afoul of GlobalDecl construction assert when checking for target-feature compatibility.
The core problem is fixed by using the version of the check that takes a FunctionDecl rather than the GlobalDecl. However, while writing the test, I discovered that source locations weren't properly set for this check on ctors/dtors. This patch also fixes constructors and CALLED destructors.
Unfortunately, it doesn't seem too possible to get a meaningful source location for a 'cleanup' destructor, so those are still 'frontend' level errors unfortunately. A fixme was added to the test to cover that situation.
This should fix 'Assertion failed: (!isa<CXXConstructorDecl>(D) && "Use other ctor with ctor decls!"), function Init, file /usr/src/contrib/llvm-project/clang/include/clang/AST/GlobalDecl.h, line 45' when compiling the security/botan2 port.
PR: 245550
MFC r359981:
Revert commit a9ad65a2b from llvm git (by Nemanja Ivanovic):
[PowerPC] Change default for unaligned FP access for older subtargets
This is a fix for https://bugs.llvm.org/show_bug.cgi?id=40554
Some CPU's trap to the kernel on unaligned floating point access and there are kernels that do not handle the interrupt. The program then fails with a SIGBUS according to the PR. This just switches the default for unaligned access to only allow it on recent server CPUs that are known to allow this.
Differential revision: https://reviews.llvm.org/D71954
This upstream commit causes a compiler hang when building certain ports (e.g. security/nss, multimedia/x264) for powerpc64. The hang has been reported in https://bugs.llvm.org/show_bug.cgi?id=45186, but in the mean time it is more convenient to revert the commit.
Requested by: jhibbits
MFC r359994:
Revert commit b6cf400aa fro llvm git (by Nemanja Ivanovic):
Fix bots after a9ad65a2b34f
In the last commit, I neglected to initialize the new subtarget feature I added which caused failures on a few bots. This should fix that.
This unbreaks the build after r359981, which reverted upstream commit a9ad65a2b34f.
Reported by: jhibbits (and jenkins :)
MFC r360129:
Merge commit ce5173c0e from llvm git (by Reid Kleckner):
Use FinishThunk to finish musttail thunks
FinishThunk, and the invariant of setting and then unsetting CurCodeDecl, was added in 7f416cc42638 (2015). The invariant didn't exist when I added this musttail codepath in ab2090d10765 (2014). Recently in 28328c3771, I started using this codepath on non-Windows platforms, and users reported problems during release testing (PR44987).
The issue was already present for users of EH on i686-windows-msvc, so I added a test for that case as well.
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D76444
This should fix 'Assertion failed: (!empty() && "popping exception stack when not empty"), function popTerminate, file /usr/src/contrib/llvm-project/clang/lib/CodeGen/CGCleanup.h, line 583' when building the net-p2p/libtorrent-rasterbar
PR: 244830 Reported by: jbeich, yuri
MFC r360134:
Merge commit 64b31d96d from llvm git (by Nemanja Ivanovic):
[PowerPC] Do not attempt to reuse load for 64-bit FP_TO_UINT without FPCVT
We call the function that attempts to reuse the conversion without checking whether the target matches the constraints that the callee expects. This patch adds the check prior to the call.
Fixes: https://bugs.llvm.org/show_bug.cgi?id=43976
Differential revision: https://reviews.llvm.org/D77564
This should fix 'Assertion failed: ((Op.getOpcode() == ISD::FP_TO_SINT || Subtarget.hasFPCVT()) && "i64 FP_TO_UINT is supported only with FPCVT"), function LowerFP_TO_INTForReuse, file /usr/src/contrib/llvm/lib/Target/PowerPC/PPCISelLowering.cpp, line 7276' when building the devel/libslang2 port (and a few others) for PowerPC64.
Requested by: pkubaj
MFC r360350:
Tentatively apply https://reviews.llvm.org/D78877 (by Dave Green):
[ARM] Only produce qadd8b under hasV6Ops
When compiling for a arm5te cpu from clang, the +dsp attribute is set. This meant we could try and generate qadd8 instructions where we would end up having no pattern. I've changed the condition here to be hasV6Ops && hasDSP, which is what other parts of ARMISelLowering seem to use for similar instructions.
Fixed PR45677.
This fixes "fatal error: error in backend: Cannot select: t37: i32 = ARMISD::QADD8b t43, t44" when compiling sys/dev/sound/pcm/feeder_mixer.c for armv5. For some reason we do not encounter this on head, but this error popped up while building universes for stable/12.
MFC r360697:
In r358396 I merged llvm upstream commit 2e24219d3, which fixed "error: unsupported relocation on symbol" when assembling arm 'adr' pseudo instructions. However, the upstream commit did not take big-endian arm into account.
Applying the same changes to the big-endian handling is straightforward, thanks to Andrew Turner and Peter Smith for the hint. This will also be submitted upstream.
|
#
360658 |
|
05-May-2020 |
dim |
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 9.0.0 final release r372316.
(NOTE: This does not yet consolidate all the llvm project sources under contrib/llvm-project (e.g., MFC r355940), due to Subversion limitations. It will be done in a follow-up MFC.)
MFC r348610 (by emaste):
build llvm-ar and llvm-nm with Clang (promote out of CLANG_EXTRAS)
To facilitate experimentation with LTO we require an ar that supports LLVM IR, and to a lesser degree also an nm. As a first step always install llvm-ar and llvm-nm.
Sponsored by: The FreeBSD Foundation
MFC r350453 (by asomers):
Add a CXXWARNFLAGS variable
Some warning flags are valid for C++ but not C. GCC 8 complains if you pass such flags when building a C file. Using a separate variable for these flags allows building both C and C++ files in the same directory (such as the fusefs tests) under GCC.
Reviewed by: cem, emaste Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D21116
MFC r350467 (by luporl):
[PPC64] Backport fix for missing IRELATIVE relocations
This is a backport of LLVM commit 8331f61a51a7a0a1efbf5ed398e181593023d151, llvm-svn: 353981:
ELF: Allow GOT relocs pointing to non-preemptable ifunc to resolve to an IRELATIVE where possible.
This is needed in order to make ifuncs work correctly on PPC64.
It fixes an issue with lld, in which it would skip emitting necessary IRELATIVE relocations. Without this change, indirect calls to ifuncs would result in a segmentation fault, in static binaries or when defined in the main binary (outside shared libraries).
This change also reverts the local "Preserve relocations against ifuncs when -zifunc-noplt" commit and replaces it by its upstream version, as part of the merge.
Reviewed by: markj Differential Revision: https://reviews.freebsd.org/D21102
MFC r351662 (by emaste):
lldb: shorten thread names to make logs easier to follow
lldb prepends the thread name to log entries, and the existing thread name for the FreeBSD ProcessMonitor thread was longer than the kernel's supported thread name length, and so was truncated. This made logs hard to read, as the truncated thread name ran into the log message. Shorten "lldb.process.freebsd.operation" to just "freebsd.op" so that logs are more readable.
(Upstreaming to lldb still to be done).
MFC r352095 (by emaste):
compiler-rt: use more __sanitizer_time_t on FreeBSD
A few structs were using long for time_t members.
Obtained from: LLVM r370755
MFC r352096 (by emaste):
compiler-rt: use 64-bit time_t for all FreeBSD archs except i386
Obtained from: LLVM r370756
MFC r352167 (by imp):
Remove dir empty since r276851
MFC r352168 (by imp):
Remove dirs empty since r280031
MFC r352169 (by imp):
Remove dir empty since r314564
MFC r352170 (by imp):
Remove dir empty since r327952
MFC r352171 (by imp):
Remove dirs (and their now-empty parents) empty since r344779
MFC r352792 (by emaste):
compiler-rt: correct RISC-V struct_kernel_stat64_sz
The value of struct_kernel_stat64_sz introduced by review D5021 for RISC-V was incorrect.
Also add a __riscv_xlen == 64 conditional as the 32-bit ABI is not yet finalized.
Submitted by: Luís Marques Differential Revision: https://reviews.freebsd.org/D21684
MFC r353018 (by kevans):
clang: use -mxgot for 32-bit mips
Various bits in usr.bin/clang/* will fail to compile without -mxgot due to truncated relocations. -mxgot entails a speed penalty, but I suspect we don't care as much about compiler performance in 32-bit mips land.
Reviewed by: arichardson Differential Revision: https://reviews.freebsd.org/D21698
MFC r353358:
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 9.0.0 final release r372316.
Release notes for llvm, clang, lld and libc++ 9.0.0 are available here:
https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/clang/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/tools/lld/docs/ReleaseNotes.html https://releases.llvm.org/9.0.0/projects/libcxx/docs/ReleaseNotes.html
PR: 240629
MFC r353363:
Put in a band-aid fix for lldb 9 exiting with "Expected<T> must be checked before access or destruction" when launching executables, while we sort this out with upstream.
Reported by: jbeich PR: 241137
MFC r353415:
Revert r353363 in preparation for applying upstream fix:
Put in a band-aid fix for lldb 9 exiting with "Expected<T> must be checked before access or destruction" when launching executables, while we sort this out with upstream.
PR: 241137
MFC r353416:
Pull in r374444 from upstream lldb trunk (by me):
Fix process launch failure on FreeBSD after r365761
Summary: After rLLDB365761, and with `LLVM_ENABLE_ABI_BREAKING_CHECKS` enabled, launching any process on FreeBSD crashes lldb with:
``` Expected<T> must be checked before access or destruction. Expected<T> value was in success state. (Note: Expected<T> values in success mode must still be checked prior to being destroyed). ```
This is because `m_operation_thread` and `m_monitor_thread` were wrapped in `llvm::Expected<>`, but this requires the objects to be correctly initialized before accessing them.
To fix the crashes, use `llvm::Optional<>` for the members (as indicated by labath), and use local variables to store the return values of `LaunchThread` and `StartMonitoringChildProcess`. Then, only assign to the member variables after checking if the return values indicated success.
Reviewers: devnexen, emaste, MaskRay, mgorny
Reviewed By: devnexen
Subscribers: jfb, labath, krytarowski, lldb-commits
Differential Revision: https://reviews.llvm.org/D68723
PR: 241137
MFC r353579 (by jhb):
Use __FreeBSD_version to determine if gets() has been removed.
GCC compilers set __FreeBSD__ statically to a build-time determined targeted version (which in ports always matches the build host's version). This means that when building any version (12 or 13, etc.) of riscv or some other architecture via GCC on a 12.x host, __FreeBSD__ will always be set to 12. As a result, __FreeBSD__ cannot be used to reliably detect the target FreeBSD version being built. Instead, __FreeBSD_version from either <sys/param.h> (in the kernel) or <osreldate.h> (in userland) should be used.
This changes the gets() test in libc++ to use __FreeBSD_version from <osreldate.h>.
Reported by: jenkins (riscv64 and amd64-gcc) Reviewed by: dim, imp Differential Revision: https://reviews.freebsd.org/D22034
MFC r353711 (by mhorne):
Fix build of LLVM RISC-V backend
Reviewed by: dim MFC with: r353358 Differential Revision: https://reviews.freebsd.org/D21963
MFC r353738:
Pull in r372651 from upstream lld trunk (by Simon Atanasyan):
[mips] Support elf32btsmipn32_fbsd / elf32ltsmipn32_fbsd emulations
Patch by Kyle Evans.
Requested by: kevans
MFC r353739:
Pull in r374154 from upstream clang trunk (by Simon Atanasyan):
[mips] Set default float ABI to "soft" on FreeBSD
Initial patch by Kyle Evans.
Fix PR43596
Requested by: kevans
MFC r353936:
Bump clang's default target CPU for the i386 architecture (aka "x86") to i686, as per the discussion on the freebsd-arch mailing list. Earlier in r352030, I had already bumped it to i586, to work around missing atomic 64 bit functions for the i386 architecture.
Relnotes: yes
MFC r354097:
Pull in r372186 from upstream llvm trunk (by Eli Friedman):
[ARM] VFPv2 only supports 16 D registers.
r361845 changed the way we handle "D16" vs. "D32" targets; there used to be a negative "d16" which removed instructions from the instruction set, and now there's a "d32" feature which adds instructions to the instruction set. This is good, but there was an oversight in the implementation: the behavior of VFPv2 was changed. In particular, the "vfp2" feature was changed to imply "d32". This is wrong: VFPv2 only supports 16 D registers.
In practice, this means if you specify -mfpu=vfpv2, the compiler will generate illegal instructions.
This patch gets rid of "vfp2d16" and "vfp2d16sp", and fixes "vfp2" and "vfp2sp" so they don't imply "d32".
Differential Revision: https://reviews.llvm.org/D67375
Pull in r372187 from upstream clang trunk (by Eli Friedman):
[ARM] Update clang for removal of vfp2d16 and vfp2d16sp
Matching fix for https://reviews.llvm.org/D67375 (r372186).
Differential Revision: https://reviews.llvm.org/D67467
This should fix clang generating invalid opcodes for floating point operations on armv6.
Requested by: mmel
MFC r354146:
Pull in r373338 from upstream llvm trunk (by Simon Pilgrim):
Revert rL349624 : Let TableGen write output only if it changed, instead of doing so in cmake, attempt 2
Differential Revision: https://reviews.llvm.org/D55842 ----------------- As discussed on PR43385 this is causing Visual Studio msbuilds to perpetually rebuild all tablegen generated files
Pull in r373664 from upstream llvm trunk (by Nico Weber):
Reland r349624: Let TableGen write output only if it changed, instead of doing so in cmake
Move the write-if-changed logic behind a flag and don't pass it with the MSVC generator. msbuild doesn't have a restat optimization, so not doing write-if-change there doesn't have a cost, and it should fix whatever causes PR43385.
This should fix the scenario where an incremental build from before r353358 (the clang 9.0.0 upgrade) to r353358 or later fails to update the timestamp of the generated lib/clang/headers/arm_fp16.h header.
After such a build, installing world from read-only source and object directories would attempt to generate the header again, leading to "clang-tblgen: error opening arm_fp16.h.d:Read-only file system".
Reported by: avg, np PR: 241402
MFC r354339:
Merge commit 97e362607 from llvm git (by Nemanja Ivanovic):
[PowerPC] Do not emit HW loop if the body contains calls to lrint/lround
These two intrinsics are lowered to calls so should prevent the formation of CTR loops. In a subsequent patch, we will handle all currently known intrinsics and prevent the formation of HW loops if any unknown intrinsics are encountered.
Differential revision: https://reviews.llvm.org/D68841
This should fix an "invalid CRT loop" assertion when building the www/node port for powerpc64.
Requested by: Alfredo Dal'Ava Júnior <alfredo.junior@eldorado.org.br>
MFC r354347 (by cem):
Fix llvm-libunwind userspace build on ARM
GCC's libgcc exports a few ARM-specific symbols for ARM EABI, AEABI, or EHABI or whatever it's called. Export the same ones from LLVM-libunwind's libgcc_s, on ARM. As part of this, convert libgcc_s from a direct Version.map to one constructed from component Symbol.map files. This allows the ARM-specific Symbol.map to be included only on ARM.
Fix ARM-only oddities in struct name/aliases in LLVM-libunwind to match non-ARM definitions and ARM-specific expectations in libcxxrt / libcompiler_rt.
No functional change intended for non-ARM architectures.
This commit does not actually flip the switch for ARM defaults from libgcc to llvm-libunwind, but makes it possible (to compile, anyway).
MFC r354418 (by cem):
clang: Enable unwind tables on !amd64
There doesn't seem to be much sense in defaulting "on" unwind tables on amd64 and not on other arches. It causes surprising differences between platforms, such as the PR below.
Prior to this change, FreeBSD inherited the default implementation of the method from the Gnu.h Generic_Elf => Generic_GCC parent class, which returned true only for amd64 targets. Override that and opt on always, similar to, e.g., NetBSD.
PR: 241562 Reported by: lwhsu Reviewed by: dim Discussed with: emaste Relnotes: yes Differential Revision: https://reviews.freebsd.org/D22252
MFC r354429:
Merge commit 8e34dd941 from llvm git (by Sanjay Patel):
[x86] avoid crashing when splitting AVX stores with non-simple type (PR43916)
The store splitting transform was assuming a simple type (MVT), but that's not necessarily the case as shown in the test.
This should fix 'Assertion failed: (isSimple() && "Expected a SimpleValueType!")' when building the security/openssl111 port targeting a CPU that supports AVX, but not AVX2, such as sandybridge.
PR: 241747
MFC r354469:
Merge commit f596f4507 from llvm git (by Sam Elliott):
[RISCV] Add Custom Parser for Atomic Memory Operands
Summary: GCC Accepts both (reg) and 0(reg) for atomic instruction memory operands. These instructions do not allow for an offset in their encoding, so in the latter case, the 0 is silently dropped.
Due to how we have structured the RISCVAsmParser, the easiest way to add support for parsing this offset is to add a custom AsmOperand and parser. This parser drops all the parens, and just keeps the register.
This commit also adds a custom printer for these operands, which matches the GCC canonical printer, printing both `(a0)` and `0(a0)` as `(a0)`.
Reviewers: asb, lewis-revill
Reviewed By: asb
Subscribers: s.egerton, hiraditya, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, jfb, PkmX, jocewei, psnobl, benna, Jim, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65205
llvm-svn: 367553
Merge commit f596f4507 from llvm git (by Sam Elliott):
[RISCV] Add FreeBSD targets
Reviewers: asb
Reviewed By: asb
Subscribers: simoncook, s.egerton, lenary, psnobl, benna, mhorne, emaste, kito-cheng, shiva0217, rogfer01, rkruppe, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57795
Patch by James Clarke (jrtc27)
llvm-svn: 367557
Merge commit f596f4507 from llvm git (by Hsiangkai Wang):
[DebugInfo] Generate fixups as emitting DWARF .debug_frame/.eh_frame.
It is necessary to generate fixups in .debug_frame or .eh_frame as relaxation is enabled due to the address delta may be changed after relaxation.
There is an opcode with 6-bits data in debug frame encoding. So, we also need 6-bits fixup types.
Differential Revision: https://reviews.llvm.org/D58335
llvm-svn: 366524
Merge commit f596f4507 from llvm git (by Hsiangkai Wang):
[DebugInfo] Some fields do not need relocations even relax is enabled.
In debug frame information, some fields, e.g., Length in CIE/FDE and Offset in FDE are attributes to describe the structure of CIE/FDE. They are not related to the relaxed code. However, these attributes are symbol differences. So, in current design, these attributes will be filled as zero and LLVM generates relocations for them.
We only need to generate relocations for symbols in executable sections. So, if the symbols are not located in executable sections, we still evaluate their values under relaxation.
Differential Revision: https://reviews.llvm.org/D61584
llvm-svn: 366531
Merge commit f596f4507 from llvm git (by Alex Bradbury):
[RISCV] Don't force absolute FK_Data_X fixups to relocs
The current behavior of shouldForceRelocation forces relocations for the majority of fixups when relaxation is enabled. This makes sense for fixups which incorporate symbols but is unnecessary for simple data fixups where the fixup target is already resolved to an absolute value.
Differential Revision: https://reviews.llvm.org/D63404 Patch by Edward Jones.
llvm-svn: 369257
Merge commit f596f4507 from llvm git (by Alex Bradbury):
[RISCV] Implement getExprForFDESymbol to ensure RISCV_32_PCREL is used for the FDE location
Follow binutils in using RISCV_32_PCREL for the FDE initial location. As explained in the relevant binutils commit <https://github.com/riscv/riscv-binutils-gdb/commit/a6cbf936e3dce68114d28cdf60d510a3f78a6d40>, the ADD/SUB pair of relocations is problematic in the presence of linker relaxation.
This patch has the same end goal as D64715 but includes test changes and avoids adding a new global VariantKind to MCExpr.h (preferring RISCVMCExpr VKs like the rest of the RISC-V backend).
Differential Revision: https://reviews.llvm.org/D66419
llvm-svn: 369375
This series of merges will permit riscv64 kernels and riscv64sf worlds to build with clang instead of gcc (but still using the bfd linker).
Requested by: jhb Obtained from: https://github.com/freebsd/freebsd/compare/master...bsdjhb:riscv_clang
MFC r354662 (by jhb):
Sync target triple generation with the version in Makefile.inc1.
Reviewed by: dim Sponsored by: DARPA Differential Revision: https://reviews.freebsd.org/D22333
MFC r354692 (by emaste):
llvm: use AT_EXECPATH from ELF auxiliary vectors for getExecutablePath
/proc/curproc/file and the KERN_PROC_PATHNAME sysctl may not return the desired path if there are multiple hardlinks to the file.
PR: 241932 Tested by: ler Sponsored by: The FreeBSD Foundation
MFC r354707 (by emaste):
llvm: use elf_aux_info to get executable's path, if available
Obtained from: LLVM a0a38b81ea MFC with: r354692 Sponsored by: The FreeBSD Foundation
MFC r354979:
Merge commit 7bed381ea from llvm git (by Simon Atanasyan):
[mips] Implement Octeon+ `saa` and `saad` instructions
`saa` and `saad` are 32-bit and 64-bit store atomic add instructions.
memory[base] = memory[base] + rt
These instructions are available for "Octeon+" CPU. The patch adds support for both instructions to MIPS assembler and diassembler and introduces new CPU type - "octeon+".
Next patches will implement `.set arch=octeon+` directive and `AFL_EXT_OCTEONP` ISA extension flag support.
Differential Revision: https://reviews.llvm.org/D69849
This is one of the upstream changes needed for adding support for the OCTEON+ CPU type, so that we can test Clang builds using the most commonly available FreeBSD/mips64 reference platform, the Edge Router Lite.
Requested by: kevans
MFC r354980:
Merge commit 3718102d4 from llvm git (by Simon Atanasyan):
[mips] Support `octeon+` CPU in the `.set arch=` directive
Differential Revision: https://reviews.llvm.org/D69850
This is one of the upstream changes needed for adding support for the OCTEON+ CPU type, so that we can test Clang builds using the most commonly available FreeBSD/mips64 reference platform, the Edge Router Lite.
Requested by: kevans
MFC r354981:
Merge commit bf996f761 from llvm git (by Simon Atanasyan):
[mips] Write `AFL_EXT_OCTEONP` flag to the `.MIPS.abiflags` section
Differential Revision: https://reviews.llvm.org/D69851
This is one of the upstream changes needed for adding support for the OCTEON+ CPU type, so that we can test Clang builds using the most commonly available FreeBSD/mips64 reference platform, the Edge Router Lite.
Requested by: kevans
MFC r354982:
Merge commit 3552d3e0f from llvm git (by Simon Atanasyan):
[mips] Add `octeon+` to the list of CPUs accepted by the driver
This is one of the upstream changes needed for adding support for the OCTEON+ CPU type, so that we can test Clang builds using the most commonly available FreeBSD/mips64 reference platform, the Edge Router Lite.
Requested by: kevans
MFC r354983:
Merge commit e578d0fd2 from llvm git (by Simon Atanasyan):
[mips] Fix `__mips_isa_rev` macros value for Octeon CPU
This is one of the upstream changes needed for adding support for the OCTEON+ CPU type, so that we can test Clang builds using the most commonly available FreeBSD/mips64 reference platform, the Edge Router Lite.
Requested by: kevans
MFC r354984:
Merge commit 0d14656b9 from llvm git (by Simon Atanasyan):
[mips] Set __OCTEON__ macros
This is one of the upstream changes needed for adding support for the OCTEON+ CPU type, so that we can test Clang builds using the most commonly available FreeBSD/mips64 reference platform, the Edge Router Lite.
Requested by: kevans
MFC r354985:
Merge commit a751f557d from llvm git (by Simon Atanasyan):
[mips] Set macros for Octeon+ CPU
This is one of the upstream changes needed for adding support for the OCTEON+ CPU type, so that we can test Clang builds using the most commonly available FreeBSD/mips64 reference platform, the Edge Router Lite.
Requested by: kevans
MFC r355397:
Merge commit 241cbf201 from llvm git (by Nemanja Ivanovic):
[PowerPC] Fix crash in peephole optimization
When converting reg+reg shifts to reg+imm rotates, we neglect to consider the CodeGenOnly versions of the 32-bit shift mnemonics. This means we produce a rotate with missing operands which causes a crash.
Committing this fix without review since it is non-controversial that the list of mnemonics to consider should include the 64-bit aliases for the exact mnemonics.
Fixes PR44183.
This should fix "Assertion failed: (idx < size()), function operator[], file /usr/src/contrib/llvm/include/llvm/ADT/SmallVector.h, line 153" when building the graphics/mesa-dri port for the PowerPC64 ELFv2 ABI.
Reported by: Alfredo Dal'Ava Júnior <alfredo.junior@eldorado.org.br>
MFC r355602:
Add a few missed source files to libllvm, for the MK_LLVM_TARGET_BPF=yes case. Otherwise, linking of clang and other llvm based executables would complain about missing symbols.
Reported by: rstone
MFC r355645 (by cem):
arm: libgcc_s: Fix ABI breakage introduced in r354347
Provide the symbol version for llvm-libunwind's _Unwind_Backtrace that libgcc has historically provided on arm, in addition to the (default) standard version used on all other arch.
Reported by: mmel
MFC r355803 (by mmel):
Fix LLVM libunwnwind _Unwind_Backtrace symbol version for ARM. In original GNU libgcc, _Unwind_Backtrace is published with GCC_3.3 version for all architectures but ARM. For ARM should be publishes with GCC_4.3.0 version. This was originally omitted in r255095, fixed in r318024 and omitted aging in LLVM libunwind implementation in r354347.
For ARM _Unwind_Backtrace should be published as default with GCC_4.3.0 version , (because this is right original version) and again as normal(not-default) with GCC_3.3 version (to maintain ABI compatibility compiled/linked with wrong pre r318024 libgcc)
PR: 233664
|
#
359958 |
|
15-Apr-2020 |
hselasky |
MFC r359727: Clone the RCU interface into a sleepable and a non-sleepable part in the LinuxKPI.
This allows synchronize RCU to be used inside a SRCU read section. No functional change intended.
Bump the __FreeBSD_version to force recompilation of external kernel modules.
PR: 242272 Sponsored by: Mellanox Technologies
|
#
357613 |
|
06-Feb-2020 |
hselasky |
Bump FreeBSD version due to recent LinuxKPI changes.
This is a direct commit.
Sponsored by: Mellanox Technologies
|
#
356680 |
|
13-Jan-2020 |
hselasky |
MFC r356409: Add own counter for cancelled USB transfers. Do not count these as errors.
Bump the FreeBSD version to force recompilation of external modules.
Sponsored by: Mellanox Technologies
|
#
356395 |
|
06-Jan-2020 |
hselasky |
MFC r356135: Make USB statistics per device instead of per bus.
Bump the FreeBSD version due to structure change to force recompilation of external USB modules.
Sponsored by: Mellanox Technologies
|
#
355899 |
|
19-Dec-2019 |
kevans |
MFC r355643: __FreeBSD__version bumps for sigsetops
|
#
354616 |
|
11-Nov-2019 |
hselasky |
MFC r354335: Enable device class group attributes in the LinuxKPI.
Bump the __FreeBSD_version to force recompilation of external kernel modules due to structure change.
Differential Revision: https://reviews.freebsd.org/D21564 Submitted by: Greg V <greg@unrelenting.technology> Sponsored by: Mellanox Technologies
|
#
354615 |
|
11-Nov-2019 |
hselasky |
MFC r351937: LinuxKPI: Improve sysfs support.
- Add functions for creating and merging sysfs groups. - Add sysfs_streq function to compare strings ignoring newline from the sysctl userland call. - Add a call to sysfs_create_groups in device_add. - Remove duplicate header include. - Bump __FreeBSD_version.
Differential Revision: D21542
|
#
354614 |
|
11-Nov-2019 |
hselasky |
MFC r351701: LinuxKPI: Add sysfs create/remove functions that handles multiple files in one call.
Differential Revision: D21475
|
#
354598 |
|
10-Nov-2019 |
dim |
MFC r354460:
Merge commit e8316372b from llvm git (by Louis Dionne):
[libc++] Add `__truncating_cast` for safely casting float types to integers
This is needed anytime we need to clamp an arbitrary floating point value to an integer type.
Thanks to Eric Fiselier for the patch.
Differential Revision: https://reviews.llvm.org/D66836
llvm-svn: 370891
Merge commit b92deded8 from llvm git (by Louis Dionne):
[libc++] Move __clamp_to_integral to <cmath>, and harden against min()/max() macros
llvm-svn: 370900
Merge commit 0ec6a4882 from llvm git (by Louis Dionne):
[libc++] Fix potential OOB in poisson_distribution
See details in the original Chromium bug report: https://bugs.chromium.org/p/chromium/issues/detail?id=994957
Together, these fix a security issue in libc++'s implementation of std::poisson_distribution, which can be exploited to read data which is out of bounds.
Note there are no programs in the FreeBSD base system that use std::poisson_distribution, so this is only a possible issue for ports and external programs which have been built against libc++. Therefore, I am bumping __FreeBSD_version for the benefit of our port maintainers.
Requested by: emaste Security: potential OOB read
|
#
349027 |
|
14-Jun-2019 |
gjb |
Rename stable/11 from BETA3 to PRERELEASE as releng/11.3 has branched. Bump __FreeBSD_version.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
|
#
347883 |
|
16-May-2019 |
hselasky |
MFC r347325: Bump the Mellanox driver version numbers and the FreeBSD version number.
Sponsored by: Mellanox Technologies
|
#
347212 |
|
06-May-2019 |
erj |
MFC r345303, 345658, and partially MFC r345305
These are: r345303: prevent possible infinite loop in iflib_encap r345305: expose the Rx mbuf buffer size to drivers r345658: return ENETDOWN when the network device is down
r345305 is only partially MFC'd with no mergeinfo because it includes changes to iflib-using drivers, and none of the drivers it changes use iflib in stable/11. This commit just makes the function it adds available for use with iflib-using kernel modules.
Sponsored by: Intel Corporation
|
#
346784 |
|
27-Apr-2019 |
kevans |
Bump __FreeBSD_version for ether_gen_addr availability
This is a direct commit to stable branches as the bump wasn't present in head.
|
#
346296 |
|
16-Apr-2019 |
dim |
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 8.0.0 final release r356365.
MFC r306265 (by emaste):
Force LLVM_LIBUNWIND off if we don't have a C++11 compiler
Tested by: bde Differential Revision: https://reviews.freebsd.org/D7746
MFC r308100 (by emaste):
compile libunwind c source with -fexceptions
When an exception is thrown the unwinder must unwind its own C source (starting with _Unwind_RaiseException in UnwindLevel1.c), so it needs to be built with unwinding data.
MFC r324998 (by bdrewery):
Prefix {TARGET,BUILD}_TRIPLE with LLVM_ to avoid Makefile.inc1 collision.
The Makefile.inc1 TARGET_TRIPLE is for specifying which -target is used during the build of world.
Reviewed by: dim, imp Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D12792
MFC r329093 (by emaste):
Promote llvm-cov to a standalone option
Introduce WITH_/WITHOUT_LLVM_COV to match GCC's WITH_/WITHOUT_GCOV. It is intended to provide a superset of the interface and functionality of gcov.
It is enabled by default when building Clang, similarly to gcov and GCC.
This change moves one file in libllvm to be compiled unconditionally. Previously it was included only when WITH_CLANG_EXTRAS was set, but the complexity of a new special case for (CLANG_EXTRAS | LLVM_COV) is not worth avoiding a tiny increase in build time.
Reviewed by: dim, imp Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D142645
MFC r331244 (by jhb):
Add support for MIPS to LLVM's libunwind.
This is originally based on a patch from David Chisnall for soft-float N64 but has since been updated to support O32, N32, and hard-float ABIs. The soft-float O32, N32, and N64 support has been committed upstream. The hard-float changes are still in review upstream.
Enable LLVM_LIBUNWIND on mips when building with a suitable (C+11-capable) toolchain. This has been tested with external GCC for all ABIs and O32 and N64 with clang.
Reviewed by: emaste Obtained from: CheriBSD (original N64 patch) Sponsored by: DARPA / AFRL Differential Revision: https://reviews.freebsd.org/D14701
MFC r336691 (by emaste):
llvm: remove __FreeBSD_version conditionals
All supported FreeBSD build host versions have backtrace.h, so we can just eliminate that test. For futimes() we can test the compiler's built-in __FreeBSD__ major version rather than relying on including osreldate.h. This should reduce the frequency with which Clang gets rebuilt when building world.
Reviewed by: dim Sponsored by: The FreeBSD Foundation
MFC r337379 (by andrew):
Default to armv5te in LINT on arm. This should fix building LINT there.
MFC r337552:
Add optional LLVM BPF target support
BPF (eBPF) is an independent instruction set architecture which is introduced in Linux a few years ago. Originally, eBPF execute environment was only inside Linux kernel. However, recent years there are some user space implementation (https://github.com/iovisor/ubpf, https://doc.dpdk.org/guides/prog_guide/bpf_lib.html) and kernel space implementation for FreeBSD is going on (https://github.com/YutaroHayakawa/generic-ebpf).
The BPF target support can be enabled using WITH_LLVM_TARGET_BPF, as it is not built by default.
Submitted by: Yutaro Hayakawa <yhayakawa3720@gmail.com> Reviewed by: dim, bdrewery Differential Revision: https://reviews.freebsd.org/D16033
MFC r337585:
In r308100, an explicit -fexceptions flag was added for the C sources from LLVM's libunwind, which end up in libgcc_eh.a and libgcc_s.so. This is because the unwinder needs the unwinder data for its own functions.
However, for the C++ sources in libunwind, -fexceptions is already the default, and this can have the side effect of generating a reference to __gxx_personality_v0, the so-called personality function, which is normally provided by the C++ ABI library (libcxxrt or libsupc++).
If the reference ends up in the eventual libgcc_s.so, linking any non-C++ programs against it will fail with "undefined reference to `__gxx_personality_v0'".
Note that at high optimization levels, the reference is usually optimized away, which is why we have never noticed this problem before.
With clang 7.0.0 though, higher optimization levels don't help anymore, since the addition of address-significance tables [1] in <https://reviews.llvm.org/rL337339>. Effectively, this always causes a reference to __gxx_personality_v0.
After discussion with the upstream author of that change, it turns out that we should compile libunwind sources with the -fno-exceptions -funwind-tables flags instead. This ensures unwind tables are generated, but no references to any personality functions are emitted.
[1] https://lists.llvm.org/pipermail/llvm-dev/2018-May/123514.html
Reported by: jbeich PR: 230399
MFC r340287 (by emaste):
Consolidate gcov entries in OptionalObsoleteFiles
Sponsored by: The FreeBSD Foundation
MFC r340289 (by emaste):
llvm-cov: also install as gcov (if GNU gcov is disabled)
llvm-cov provides a gcov-compatible interface when invoked as gcov.
Reviewed by: dim, markj Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D17923
MFC r340296 (by emaste):
Move llvm-profdata build into MK_LLVM_COV block
llvm-profdata is used with llvm-cov for code coverage (although llvm-cov can also operate independently in a gcov-compatible mode). Although llvm-profdata can be used independently of llvm-cov it makes sense to group these under one option.
Also handle these in OptionalObsoleteFiles.inc while here.
Sponsored by: The FreeBSD Foundation
MFC r340300 (by emaste):
libllvm: Move SampleProfWriter to SRCS_MIN
It is required by llvm-profdata, now built by default under the LLVM_COV knob. The additional complexity that would come from avoiding building it if CLANG_EXTRAS and LLVM_COV are both disabled is not worth the small savings in build time.
Sponsored by: The FreeBSD Foundation
MFC r340972 (by emaste):
llvm-objdump: initial man page
Based on llvm-objdump's online documentation and usage information. This serves as a starting point; additional detail and cleanup still required.
Also being submitted upstream in LLVM review D54864. I expect to use this bespoke copy while we have LLVM 6.0 or 7.0 in FreeBSD; when we update to LLVM 8.0 it should be upstream and we will switch to it.
PR: 233437 Reviewed by: bcr (man formatting) Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D18309
MFC r340973 (by emaste):
llvm-objdump.1: remove invalid options
Some options appear in llvm-objdump's usage information as a side effect of its option parsing implementation and are not actually llvm-objdump options. Reported in LLVM review https://reviews.llvm.org/D54864.
Reported by: Fangrui Song Sponsored by: The FreeBSD Foundation
MFC r340975 (by emaste):
llvm-objdump.1: fix igor / mandoc -Tlint warnings
Accidentally omitted from r340972.
MFC r341055 (by emaste):
llvm-objdump.1: remove more unintentional options
Some options come from static constructors in LLVM libraries and are automatically added to llvm's usage output. They're not really supposed to be llvm-objdump options.
Reported by: Fangrui Song in LLVM review D54864 Sponsored by: The FreeBSD Foundation
MFC r344779:
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to the upstream release_80 branch r355313 (effectively, 8.0.0 rc3). The release will follow very soon, but no more functional changes are expected.
Release notes for llvm, clang and lld 8.0.0 will soon be available here: <https://releases.llvm.org/8.0.0/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/clang/docs/ReleaseNotes.html> <https://releases.llvm.org/8.0.0/tools/lld/docs/ReleaseNotes.html>
PR: 236062 Relnotes: yes
MFC r344798 (by emaste):
libllvm: promote WithColor and xxhash to SRCS_MIN
The armv6 build failed in CI due to missing symbols (from these two source files) in the bootstrap Clang.
This affected only armv6 because other Clang-using archs are using LLD as the bootstrap linker, and thus include SRCS_MIW via LLD_BOOTSTRAP.
Reported by: CI, via lwhsu Sponsored by: The FreeBSD Foundation
MFC r344825:
Add a few missed files to the MK_LLVM_TARGET_BPF=yes case, otherwise clang and various other executables will fail to link with undefined symbols.
Reported by: O. Hartmann <ohartmann@walstatt.org>
MFC r344852:
Put in a temporary workaround for what is likely a gcc 6 bug (it does not occur with gcc 7 or later). This should prevent the following error from breaking the head-amd64-gcc CI builds:
In file included from /workspace/src/contrib/llvm/tools/lldb/source/API/SBMemoryRegionInfo.cpp:14:0: /workspace/src/contrib/llvm/tools/lldb/include/lldb/Target/MemoryRegionInfo.h:128:54: error: 'template<class _InputIterator> lldb_private::MemoryRegionInfos::MemoryRegionInfos(_InputIterator, _InputIterator, const allocator_type&)' inherited from 'std::__1::vector<lldb_private::MemoryRegionInfo>' using std::vector<lldb_private::MemoryRegionInfo>::vector; ^~~~~~ /workspace/src/contrib/llvm/tools/lldb/include/lldb/Target/MemoryRegionInfo.h:128:54: error: conflicts with version inherited from 'std::__1::vector<lldb_private::MemoryRegionInfo>'
Reported by: CI
MFC r344896:
Pull in r354937 from upstream clang trunk (by Jörg Sonnenberger):
Fix inline assembler constraint validation
The current constraint logic is both too lax and too strict. It fails for input outside the [INT_MIN..INT_MAX] range, but it also implicitly accepts 0 as value when it should not. Adjust logic to handle both correctly.
Differential Revision: https://reviews.llvm.org/D58649
Pull in r355491 from upstream clang trunk (by Hans Wennborg):
Inline asm constraints: allow ICE-like pointers for the "n" constraint (PR40890)
Apparently GCC allows this, and there's code relying on it (see bug).
The idea is to allow expression that would have been allowed if they were cast to int. So I based the code on how such a cast would be done (the CK_PointerToIntegral case in IntExprEvaluator::VisitCastExpr()).
Differential Revision: https://reviews.llvm.org/D58821
These should fix assertions and errors when using the inline assembly "n" constraint in certain ways.
In case of devel/valgrind, a pointer was used as the input for the constraint, which lead to "Assertion failed: (isInt() && "Invalid accessor"), function getInt".
In case of math/secp256k1, a very large integer value was used as input for the constraint, which lead to "error: value '4624529908474429119' out of range for constraint 'n'".
PR: 236216, 236194
MFC r344951:
Merge llvm, clang, compiler-rt, libc++, lld, and lldb release_80 branch r355677 (effectively, 8.0.0 rc4), resolve conflicts, and bump version numbers.
PR: 236062
MFC r345018:
Merge LLVM libunwind trunk r351319, from just before upstream's release_80 branch point. Afterwards, we will merge the rest of the changes in the actual release_80 branch.
PR: 236062
MFC r345019:
Merge LLVM libunwind release_80 branch r355677 (effectively, 8.0.0 rc4).
PR: 236062
MFC r345021:
Pull in r355854 from upstream llvm trunk (by Jonas Paulsson):
[RegAlloc] Avoid compile time regression with multiple copy hints.
As a fix for https://bugs.llvm.org/show_bug.cgi?id=40986 ("excessive compile time building opencollada"), this patch makes sure that no phys reg is hinted more than once from getRegAllocationHints().
This handles the case were many virtual registers are assigned to the same physreg. The previous compile time fix (r343686) in weightCalcHelper() only made sure that physical/virtual registers are passed no more than once to addRegAllocationHint().
Review: Dimitry Andric, Quentin Colombet https://reviews.llvm.org/D59201
This should fix a hang when compiling certain generated .cpp files in the graphics/opencollada port.
PR: 236313
MFC r345068 (by jhb):
Move libunwind out of contrib/llvm/projects.
Move LLVM's libunwind to its own contrib/ directory similar to other runtime libraries like libc++ and libcxxrt.
Reviewed by: dim, emaste Differential Revision: https://reviews.freebsd.org/D19534
MFC r345073:
Revert r308867 (which was originally committed in the clang390-import project branch):
Work around LLVM PR30879, which is about a bad interaction between X86 Call Frame Optimization on i386 and libunwind, by disallowing the optimization for i386-freebsd12.
This should fix some instances of broken exception handling when frame pointers are omitted, in particular some unittests run during the build of editors/libreoffice.
This hack will be removed as soon as upstream has implemented a more permanent fix for this problem.
And indeed, after r345018 and r345019, which updated LLVM libunwind to the most recent version, the above workaround is no longer needed. The upstream commit which fixed this is:
https://llvm.org/viewvc/llvm-project?view=revision&revision=292723
Specifically, 32 bit (i386-freebsd) executables optimized with omitted frame pointers and Call Frame Optimization should now behave correctly when a C++ exception is thrown, and the stack is unwound.
Upstream PR: https://llvm.org/bugs/show_bug.cgi?id=30879 PR: 236062
MFC r345152:
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, and lldb release_80 branch r356034 (effectively, 8.0.0 rc5), resolve conflicts, and bump version numbers.
PR: 236062
MFC r345231:
Add LLVM openmp trunk r351319 (just before the release_80 branch point) to contrib/llvm. This is not yet connected to the build, the glue for that will come in a follow-up commit.
PR: 236062
MFC r345232:
Bootstrap svn:mergeinfo on contrib/openmp.
PR: 236062
MFC r345233:
Merge openmp release_80 branch r356034 (effectively, 8.0.0 rc5).
PR: 236062
MFC r345234:
Add openmp __kmp_gettid() wrapper, using pthread_getthreadid_np(3). This has also been submitted upstream.
PR: 236062
MFC r345283:
Enable building libomp.so for 32-bit x86. This is done by selectively enabling the functions that save and restore MXCSR, since access to this register requires SSE support.
Note that you may run into other issues with OpenMP on i386, since this *not* yet supported upstream, and certainly not extensively tested.
PR: 236062, 236582
MFC r345345:
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 8.0.0 final release r356365. There were no functional changes since the most recent merge, of 8.0.0 rc5.
Release notes for llvm, clang, lld and libc++ 8.0.0 are now available:
https://llvm.org/releases/8.0.0/docs/ReleaseNotes.html https://llvm.org/releases/8.0.0/tools/clang/docs/ReleaseNotes.html https://llvm.org/releases/8.0.0/tools/lld/docs/ReleaseNotes.html https://llvm.org/releases/8.0.0/projects/libcxx/docs/ReleaseNotes.html
PR: 236062
MFC r345349:
Pull in r352826 from upstream lld trunk (by Fangrui Song):
[ELF] Support --{,no-}allow-shlib-undefined
Summary: In ld.bfd/gold, --no-allow-shlib-undefined is the default when linking an executable. This patch implements a check to error on undefined symbols in a shared object, if all of its DT_NEEDED entries are seen.
Our approach resembles the one used in gold, achieves a good balance to be useful but not too smart (ld.bfd traces all DSOs and emulates the behavior of a dynamic linker to catch more cases).
The error is issued based on the symbol table, different from undefined reference errors issued for relocations. It is most effective when there are DSOs that were not linked with -z defs (e.g. when static sanitizers runtime is used).
gold has a comment that some system libraries on GNU/Linux may have spurious undefined references and thus system libraries should be excluded (https://sourceware.org/bugzilla/show_bug.cgi?id=6811). The story may have changed now but we make --allow-shlib-undefined the default for now. Its interaction with -shared can be discussed in the future.
Reviewers: ruiu, grimar, pcc, espindola
Reviewed By: ruiu
Subscribers: joerg, emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D57385
Pull in r352943 from upstream lld trunk (by Fangrui Song):
[ELF] Default to --no-allow-shlib-undefined for executables
Summary: This follows the ld.bfd/gold behavior.
The error check is useful as it captures a common type of ld.so undefined symbol errors as link-time errors:
// a.cc => a.so (not linked with -z defs) void f(); // f is undefined void g() { f(); }
// b.cc => executable with a DT_NEEDED entry on a.so void g(); int main() { g(); }
// ld.so errors when g() is executed (lazy binding) or when the program is started (-z now) // symbol lookup error: ... undefined symbol: f
Reviewers: ruiu, grimar, pcc, espindola
Reviewed By: ruiu
Subscribers: llvm-commits, emaste, arichardson
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D57569
Together, these add support for --no-allow-shlib-undefined, and make it the default for executables, so they will fail to link if any symbols from needed shared libraries are undefined.
Reported by: jbeich PR: 236062, 236141
MFC r345449:
Pull in r356809 from upstream llvm trunk (by Eli Friedman):
[ARM] Don't form "ands" when it isn't scheduled correctly.
In r322972/r323136, the iteration here was changed to catch cases at the beginning of a basic block... but we accidentally deleted an important safety check. Restore that check to the way it was.
Fixes https://bugs.llvm.org/show_bug.cgi?id=41116
Differential Revision: https://reviews.llvm.org/D59680
This should fix "Assertion failed: (LiveCPSR && "CPSR liveness tracking is wrong!"), function UpdateCPSRUse" errors when building the devel/xwpe port for armv7.
PR: 236062, 236568
|
#
344220 |
|
17-Feb-2019 |
kevans |
MFC lualoader: r326353, r328440, r328443, r329166-r329167, r329274, r329329, r329349-r329352, r329355-r329359, r329366-r329369, r329386-r329387, r329393, r329413-r329415, r329417, r329424-r329436, r329457, r329473-r329474, r329496-r329501, r329503-r329504, r329543, r329547-r329551, r329576-r329578, r329580, r329583, r329585-r329590, r329592-r329596, r329609-r329611, r329614, r329619, r329621-r329622, r329624, r329626-r329627, r329629-r329632, r329640-r329641, r329643-r329646, r329649-r329650, r329654, r329656, r329662, r329669-r329671, r329673-r329674, r329680, r329684-r329689, r329692-r329693, r329696-r329700, r329709, r329716, r329731, r329733-r329734, r329747-r329748, r329756, r329779, r329782, r329784, r329786, r329804, r329806, r329809, r329811, r329836, r329850-r329852, r329854, r329856-r329858, r329861, r329895, r329897-r329899, r329901-r329903, r329922-r329924, r329927-r329928, r329944-r329949, r329986-r329987, r330008-r330010, r330012, r330020, r330082-r330084, r330087-r330088, r330098-r330101, r330138-r330139, r330261-r330263, r330267-r330269, r330281-r330284, r330287, r330339-r330342, r330345-r330346, r330369-r330370, r330434-r330435, r330564, r330616-r330618, r330620, r330625, r330690, r330701, r330703, r330825, r331211, r331257, r331259, r331281-r331282, r331304, r331314, r331476-r331477, r331563-r331564, r331854-r331857, r331859-r331860, r332106, r334723, r334879, r334891, r334907, r334912, r334939, r334986, r335009, r335371, r336759, r337711, r337807-r337810, r338054, r338063, r338065-r338067, r338083, r338085-r338086, r338108, r338167-r338168, r338173, r338203, r338255, r338259, r338309, r338394, r338438, r338886, r338893, r339173, r339200, r339218, r339222, r339301, r339307, r339677-r339678, r339702, r339805, r339831, r339849, r340040, r340152
Some notes for this MFC: - This is still pre-forth/lua coexistance; that will come shortly-ish so that forth/lua may be installed together (with forth remaining the default)
- module_blacklist support for lualoader has been MFC'd, but the drm modules are not blacklisted in this stable branch.
r326353: Import lua 5.3.4 to contrib r328440: Preserve the original luaconf.h in a convenient place. Clients will r328443: Gross hack to omit printing hex floating point when the lua number r329166: Add Lua as a scripting langauge to /boot/loader r329167: Add the lua scripts from the lua-bootloader SoC r329274: stand/lua: Exit sub-menus on backspace r329329: stand/lua: Always boot on 'enter' keypress in menus r329349: stand/lua: Reduce magic numbers r329350: stand/lua: Don't descend into an empty kernels submenu r329351: stand/lua: Set reasonable ACPI default based on presence r329352: stand/lua: Consistently use semicolons for line endings r329355: stand/lua: Move kernel selection into main menu r329356: stand/lua: Allow menu items to not have explicit aliases r329357: stand/lua: Remove explicit alias from "Back to main menu" r329358: stand/lua: Say "loader prompt" instead of "lua interpreter" r329359: stand/lua: Remove a magic number/string (not a trivial literal) r329366: stand/lua: Set ACPI's default the proper way (setACPI) r329367: stand/lua: Create a "carousel" menu entry type r329368: stand/lua: Create/use some MENU_ constants where applicable r329369: stand/lua: Remove sneaky kernel assignment r329386: stand/lua: Correct usage and acceptance of BACKSPACE/DELETE keys r329387: stand/lua: Chop off the decimal for numbers passed to setcursor r329393: stand/lua: Use escaped dot instead of single character class r329413: stand/lua: Allow MENU_RETURN items to have func, fix esc. to prompt r329414: stand/lua: Don't try to divide by 0; do nothing r329415: stand/lua: Don't reload kernel config if we only have one kernel r329417: stand/lua: Make CAROUSEL_ENTRY func parameters consistent with name r329424: stand/lua: Don't set autoboot_delay=NO in menu autoboot sequence r329425: stand/lua: Enable menu autoboot; it seems to work r329426: stand/lua: Correct interpretation of autoboot_delay r329427: stand/lua: Color non-default kernels blue r329428: stand/lua: Correct some trivial errors in config r329429: stand/lua: Add debug method to dump modules r329430: stand/lua: Address some nits r329431: stand/lua: Correct test sense, this should have been 'not nil' r329432: stand/lua: Try to load alternate kernels as directories first r329433: stand/lua: Add optional GELI passphrase prompt r329434: stand/lua: Check for nil (GELI prompt) r329435: stand/lua: Style pass r329436: stand/lua: Debugging string snuck in... r329457: stand/lua: dumpModules => lsModules r329473: liblua: Clean up io/loader C module registration r329474: liblua: Emulate DIR, opendir, fdopendir, closedir r329496: stand/lua: Fix verbiage and some typos r329497: stand/lua: Fix module_path handling with multiple kernels r329498: stand/lua: Remove some debugging bits that snuck in... gr... r329499: interp_lua: Register io/loader with regular Lua module system r329500: Lua loader: Add barebones "lfs" module r329501: lua loader: Auto detect eligible list of kernels to boot r329503: liblua: Fix missing '}' in lutil.c after r329499 r329504: stand/lua: More style nits, config.lua r329543: Create style.lua(9) r329547: stand/lua: Allow menu items to be conditionally (in)visible r329548: stand/lua: Addres style.lua(9) concern r329549: stand/lua: Clear the screen before prompting for passwords r329550: stand/lua: Store the loaded kernel as config.kernel_loaded r329551: stand/lua: reload previously loaded kernel at config-load/reload r329576: stand/lua: Defer kernel/module loading until boot or menu escape r329577: stand/lua: Rename bootserial for clarity r329578: stand/lua: Menu style.lua(9) nits r329580: stand/lua: Remove some unused local declarations r329583: stand/lua: Store menu entries in an "entries" table r329585: stand/lua: Add core.isSingleUserBoot r329586: stand/lua: Call menu_entries if it's a function r329587: stand/lua: Swap single-/multi- user boot entries as needed r329588: stand/lua: Re-wrap menu.lua now that I've added indentation... r329589: stand/lua: Track env changes that come in via loader.conf(5) r329590: stand/lua: Restore environment upon config reload r329592: stand/lua: Remove inaccurate comment after r329590 r329593: stand/lua: Change boot menu items' names when swapped r329594: stand/lua: Round up some more style.lua(9) concerns r329595: stand/lua: Re-order locals after copyright notice; require first r329596: stand/lua: Add copyright notice in places r329609: stand/lua: Cache swapped menu, and don't create locals for swapping r329610: style.lua(9): Note that wrapping at 80-columns is not rigid r329611: stand/lua: Wrap tuple assignment earlier for readability r329614: stand/lua: Don't set ACPI off just because we can't detect it. r329619: stand/lua: Extract menu handlers out into menu.handlers table r329621: stand/lua: Add and use drawer.menu_name_handlers r329622: stand/lua: Move drawer.menu_name_handlers further up r329624: stand/lua: Reduce exposure of the drawer module r329626: stand/lua: Refactor logos into drawer.logodefs table r329627: stand/lua: Refactor brands into drawer.branddefs r329629: stand/lua: Use 'graphic' instead of 'logo' for depicting graphics r329630: stand/lua: Stick a copyright notice on drawer.lua r329631: stand/lua: Insert helpful comment for drawer.branddefs r329632: style.lua(9): Clarify local variable guideline r329640: stand/lua: Consistently declare local functions at module scope r329641: stand/lua: Consistently organize modules r329643: Implement loader.command r329644: lualoader: Add ability to intercept cli commands r329645: lualoader: Move carousel storage out into config r329646: lualoader: Eliminate global namespace pollution in loader.lua r329649: Lua lfs.attributes: Provide a more consistent error return r329650: liblua: Add loader.machine and loader.machine_arch properties r329654: lualoader: Ignore ACPI bits on !i386 r329656: loader.lua: Expose errno table to lua r329662: lualoader: Replace invalid construct with valid construct r329669: lualoader: Prefer selected kernel to currently loaded r329670: lualoader: Don't try so hard to load a kernel r329671: lualoader: Prepare for interception of "boot" CLI cmd r329673: lualoader: Intercept boot cli command r329674: lualoader: Intercept the 'autoboot' cli command r329680: lualoader: When restoring environment, only restore unchanged vars r329684: lualoader: Drop terminating semicolons r329685: lualoader: Drop excessive parenthesizing r329686: style.lua(9): Drop notes about semicolons r329687: lualoader: Drop explicit boolean tests; b or not b r329688: lualoader: Don't return false for failure to open config on silent r329689: lualoader: Output "Failed to parse" messages r329692: lualoader: Bring in local.lua module if it exists r329693: lualoader: Return only argstr if with_kernel not requested r329696: lualoader: Add "menu.default", initialized to menu.welcome r329697: lualoader: Drop name requirement for menu separators r329698: lualoader: Directly reference submenu definition with submenu key r329699: lualoader: Simplify menu definitions a little further r329700: lualoader: Allow carousel 'items' to be a table as well r329709: lualoader: Don't autodetect kernels if 'kernels' is explicitly set r329716: lualoader: Use the key that interrupts autoboot as a menu choice r329731: lualoader: Add boot environment support r329733: lualoader: Make kernel autodetect. contingent on loader.conf(5) var r329734: lualoader: Don't execute menu.autoboot() for every opened menu r329747: lualoader: Replace 8-space indentation with a single tab r329748: lualoader: Drop password length restrictions r329756: lualoader: Remove nasty hack for not printing out ".0" r329779: lualoader: Split cli bits out into a cli module r329782: lualoader: Unbreak 'boot [kernel]' by including config r329784: lualoader: Pull argument extraction for cli funcs to cli.arguments r329786: lualoader: Attach cli command functions to cli module r329804: lualoader: Eliminate some unused locals r329806: lualoader: Consistently use double quotes r329809: lualoader: Address some 'luacheck' concerns r329811: lualoader: Clear up an empty conditional branch r329836: lualoader: Attend to some 80-col issues, pointed out by luacheck r329850: lualoader: Drop unused return values; we'll only use the first r329851: Add SPDX tags to lua files r329852: Add copyright notice to core.lua r329854: lualoader: shallowCopyTable => deepCopyTable r329856: lualoader: Use "local function x()" instead "local x = function()" r329857: Centralize lua defines r329858: When the LUA_FLOAT_TYPE != LUA_FLOAT_INT64, we can't ref. float r329861: lualoader: Track effective line number, use it for drawing r329895: liblua: Implement write support r329897: lualoader: Add nextboot support r329898: lualoader: Plug file handle not properly closed r329899: lualoader: Correct test and name r329901: lualoader: Add comment on trailing space, don't operate on nil r329902: lualoader: Remove unused variable; we now use effective line number r329903: lualoader: Explain nextboot stuff a little bit more r329922: lualoader: Split config file I/O out into a separate function r329923: lualoader: Strip config.parse of its I/O privileges r329924: lualoader: throw out nextboot's usage of standard config processing r329927: lualoader: Clean up naming conventions a little bit r329928: lualoader: Remove inaccurate part of comment r329944: lualoader: Don't explicitly index tables without reason r329945: lualoader: menu: Terminate final values in tables with a comma r329946: lualoader: Clean up menu handling a little bit r329947: lualoader: Pull menu redrawing specifics out of menu.process r329948: lualoader: Pull autoboot handling out into menu.run() r329949: lualoader: Explain deviation from naming guidelines r329986: lualoader: Invalidate the screen from menu perspective mnu exit r329987: lualoader: Track the menu currently drawn, instead of validity r330008: lualoader: A little more general menu cleanup r330009: lualoader: More argument name expansion, part 2 r330010: lualoader: screen argument fixes r330012: style.lua(9): Add some additional notes about naming and commas r330020: lualoader: Re-work menu skipping bits r330082: lualoader: Add a twiddle at password prompt r330083: lualoader: Remove remnants of testing... r330084: lualoader: Replace instances of \027 with KEYSTR_ESCAPE r330087: lualoader: Convert instances of KEYSTR_ESCAPE .. "[" -> KEYSTR_CSI r330088: lualoader: Correct test sense, comments, and add some more comments r330098: lualoader: Re-do twiddle r330099: lualoader: Further screen cleanup r330100: lualoader: Remove debug function r330101: lualoader: Add note that \027 is a decimal representation r330138: lualoader: Dedup these "Return to main menu" entries r330139: lualoader: config: Pull some messages out into constants r330261: lualoader: Fix some lint-mentioned errors r330262: lualoader: Use #str instead of tracking length with 'n' r330263: lualoader: Use string literal \xNN instead of string.char() r330267: Add core.lua(8), but do not add to distribution r330268: Add menu.lua(8), but do not add to distribution r330269: core.lua(8): Add missing note about core.KEYSTR_CSI r330281: lualoader: Steamroll the box-drawing r330282: lualoader: Register loader.printc as global printc r330283: lualoader: Use global printc instead of loader.printc r330284: liblua: Use putc instead of printf for printc r330287: lualoader: Reset the cursor position after the menu is drawn r330339: liblua: Add loader.interpret r330340: lualoader: Execute menu_timeout_command at the end of menu autoboot r330341: lualoader: Respect loader_menu_title, prepare for align r330342: lualoader: Respect loader_menu_title_align r330345: lualoader: Tweak positioning and fix an off-by-one r330346: lualoader: Shift menu+brand even for logo=none with customized pos r330369: lualoader: Return meaningful value in cli_execute r330370: lualoader: logdef -> logodef typo r330434: lualoader: Add note about importance of including cli module early r330435: lualoader: Use FILESDIR instead of BINDIR r330564: lualoader: Only loadelf before boot/autoboot if no kernel loaded r330616: lualoader: Expose loader.parse and add cli_execute_unparsed r330617: lualoader: Fix name, cli.execute_unparsed -> cli_execute_unparsed r330618: lualoader: Use cli_execute_unparsed instead of loader.interpret r330620: lualoader: Use cli_execute_unparsed for commands via loader.conf r330625: lualoader: Return status in cli_execute_unparsed properly r330690: stand: Fix copy-paste-o, unbreaks libi386 lualoader build r330701: lualoader: Don't redraw the autoboot message every .05s r330703: lualoader: Cache kernel list r330825: lualoader: Sprinkle some verbose_loading salt r331211: lualoader: Setup default color scheme if we're using colors r331257: lualoader: Reset attributes and color scheme with color.highlight() r331259: lualoader: Use less atomic options for resetting colors/attributes r331281: lualoader: Add primitive hook module to untangle bogus reference r331282: core.lua(8): Update to reflect recently added function r331304: lualoader: Clear up some possible naming confusion r331314: lualoader: Use printc when we expect ANSI escape sequences r331476: lualoader: Make config env-related bits private API r331477: lualoader: Privatize some more config.lua bits r331563: lualoader: Implement try_include and use it for including local r331564: lualoader: Actually re-raise error in try_include r331854: lualoader: Do case-insensitive comparison of "yes" r331855: lualoader: Don't assume that {module}_load is set r331856: lualoader: revert whitespace change that snuck in r331857: lualoader: Simplify some expressions r331859: lualoader: Split logodefs out into logo-* files r331860: lualoader: Don't try to lookup a nil logo r332106: lualoader: Fix menu skipping with loader.conf(5) vars r334723: lualoader: Add a loaded hook for others to execute upon config load r334879: lualoader: Add hook.lua(8) to tree r334891: lualoader: Add cli.lua(8) to the tree r334907: lualoader: Process loader_conf_files properly r334912: lualoader: Support variable substitution in env var settings r334939: lualoader: Allow brand-*.lua for adding new brands r334986: lualoader: More black-on-white fixes r335009: lualoader: Match Forth module-loading behavior w.r.t flags r335371: lualoader: Correct kernel_options handling r336759: lualoader: "nextboot_file" should be spelled "nextboot_conf" r337711: lualoader: Fix parsing of negative number loader.conf(5) variables r337807: Prevent a wanring about checkdp being unused. r337808: When the LUA floating point model is INT64, we don't need to do the r337809: For our INT64 implementation, we can compare integers and numbers r337810: MFV r337586: lua: Update to 5.3.5 r338054: Add config.lua(8) to the tree r338063: lualoader: Stop exporting drawer.draw r338065: lualoader: Hide most of the internal drawing functions r338066: lualoader: Hide the rest of the private interfaces r338067: lualoader: Add drawer-exported variables for default logodefs r338083: Add drawer.lua(8) r338085: Add color.lua(8), password.lua(8), and screen.lua(8) r338086: lualoader: Install all manpages r338108: Serial console menus for lua. r338167: lualoader: Just compare expression directly r338168: lualoader: Refactor config line expressions r338173: lualoader: Fix loader.conf(5) EOL validation for 'exec' lines r338203: Turn off LOADER_GELI and LOADER_LUA for sparc64, until functional r338255: lualoader: Fix (add) Xen support r338259: lualoader: Accept that people use unquoted values in loader.conf r338309: lualoader: Fix override of module_path on loader prompt r338394: lualoader: fix color usage r338438: lualoader: Handle comma-separated kernels as well r338886: Improve loader passwords: r338893: Set the default loader for powerpc(32- and 64-bit) back to to forth r339173: Set the default loader for powerpc64 back to to forth too. r339200: lualoader: Don't draw loader menu with autoboot_delay=-1 r339218: lualoader: Create a module blacklist, add DRM modules to it r339222: lualoader: Honor boot_* variables at lua init r339301: Loader GELI support, like lua loader, seems to be broken on PowerPC r339307: lualoader: Provide a 'menu' command to redraw the menu at prompt r339677: lualoader: unload upon kernel change if a kernel was loaded r339678: menu.lua: Abort autoboot sequence on failed command r339702: lualoader: Improve module loading diagnostics r339805: lualoader: Always return a proper dictionary for blacklist r339831: Move LUA_ROOT to /boot/lua r339849: lualoader: Fix try_include error handling r340040: lualoader: Implement boot-conf r340152: lualoader: Add chainload menu entry
Relnotes: yes ("lualoader has been merged to stable/11, off by default, to facilitate testing")
|
#
342804 |
|
06-Jan-2019 |
kib |
MFC r342628, r342670 (by cem): Fix linux_destroy_dev() behaviour when there are still files open from the destroying cdev.
Also bump __FreeBSD_version since struct linux_cdev size on i386 increased (this is unmergeable r342629 on HEAD).
|
#
340309 |
|
09-Nov-2018 |
emaste |
Fix objcopy for little-endian MIPS64 objects.
MFC r338478 (jhb): Fix objcopy for little-endian MIPS64 objects.
MIPS64 does not store the 'r_info' field of a relocation table entry as a 64-bit value consisting of a 32-bit symbol index in the high 32 bits and a 32-bit type in the low 32 bits as on other architectures. Instead, the 64-bit 'r_info' field is really a 32-bit symbol index followed by four individual byte type fields. For big-endian MIPS64, treating this as a 64-bit integer happens to be compatible with the layout expected by other architectures (symbol index in upper 32-bits of resulting "native" 64-bit integer). However, for little-endian MIPS64 the parsed 64-bit integer contains the symbol index in the low 32 bits and the 4 individual byte type fields in the upper 32-bits (but as if the upper 32-bits were byte-swapped).
To cope, add two helper routines in gelf_getrel.c to translate between the correct native 'r_info' value and the value obtained after the normal byte-swap translation. Use these routines in gelf_getrel(), gelf_getrela(), gelf_update_rel(), and gelf_update_rela(). This fixes 'readelf -r' on little-endian MIPS64 objects which was previously decoding incorrect relocations as well as 'objcopy: invalid symbox index' warnings from objcopy when extracting debug symbols from kernel modules.
Even with this fixed, objcopy was still crashing when trying to extract debug symbols from little-endian MIPS64 modules. The workaround in gelf_*rel*() depends on the current ELF object having a valid ELF header so that the 'e_machine' field can be compared against EM_MIPS. objcopy was parsing the relocation entries to possibly rewrite the 'r_info' fields in the update_relocs() function before writing the initial ELF header to the destination object file. Move the initial write of the ELF header earlier before copy_contents() so that update_relocs() uses the correct symbol index values.
Note that this change should really go upstream. The binutils readelf source has a similar hack for MIPS64EL though I implemented this version from scratch using the MIPS64 ABI PDF as a reference.
MFC r339083 (emaste): libelf: correct mips64el test to use ELF header
libelf maintains two views of endianness: e_byteorder, and e_ident[EI_DATA] in the ELF header itself. e_byteorder is not always kept in sync, so use the ELF header endianness to test for mips64el.
MFC r339473 (emaste): libelf: also test for 64-bit ELF in _libelf_is_mips64el
Although _libelf_is_mips64el is only called in contexts where we've already checked that e_class is ELFCLASS64 but this may change in the future. Add a safety belt so that we don't access an invalid e_ehdr64 union member if it does.
PR: 231790
|
#
338931 |
|
25-Sep-2018 |
erj |
Bump __FreeBSD_version after r338871 introduced new media types and a TCP checksum fix for ixl(4)
This is a direct commit.
Sponsored by: Intel Corporation
|
#
338617 |
|
12-Sep-2018 |
sobomax |
MFC r312296 and r323254, which is new a socket option SO_TS_CLOCK to pick from several different clock sources to return timestamps when SO_TIMESTAMP is enabled and two new nanosecond-precision timestamp types. This also fixes recvmsg32() system call to properly down-convert layout of the 64-bit structures to match what 32-bit app(s) expect.
Bump __FreeBSD_version to indicate presence of a new functionality.
Differential Revision: https://reviews.freebsd.org/D9171
|
#
335436 |
|
20-Jun-2018 |
hselasky |
Bump the __FreeBSD_version after recent LinuxKPI updates to force recompilation of external kernel modules.
This is a direct commit.
Sponsored by: Mellanox Technologies
|
#
334461 |
|
01-Jun-2018 |
gjb |
Fix __FreeBSD_version on stable/11, following r334460.
Pointyhat: gjb (myself) Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
|
#
334460 |
|
01-Jun-2018 |
gjb |
Rename stable/11 back to -PRERELEASE for the duration of the 11.2-RELEASE cycle, now that releng/11.2 had branched.
Bump __FreeBSD_version.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
|
#
334392 |
|
30-May-2018 |
dteske |
MFC SVN r334261-334262,334359: dwatch(1) touch-ups
r334261: Guard against error when given -t "*..." r334262: Eliminate ANSI dimming in developer mode r334359: Fix "-t test" for post-processing profiles
Bump FreeBSD_version directly in stable/11 for ports IGNORE (as in r334290)
Reviewed by: gjb Approved by: re (gjb) Sponsored by: Smule, Inc.
|
#
332363 |
|
10-Apr-2018 |
kevans |
Revert r331880, MFC of r328331 and bump FreeBSD_version
There are logistics issues that weren't considered when this was originally MFC'd. All rc scripts in ports need audited (this is in progress) for usage of ${name}_limits that doesn't line up with the new interpretation, and individual rc.conf(5)'s need to be scrubbed of usage that doesn't line up.
It's since been decided that it should be left for a feature in 12.
1101514 introduced interpretation of ${name}_limits for rc scripts; this feature no longer exists as of 1101515.
|
#
332089 |
|
06-Apr-2018 |
kevans |
stable/11: Bump FreeBSD_Version for recent rc ${name}_limits bits
Some ports had their own interpretation of _limits that conflicted with the new definition as of r328331. r331880 was an MFC of this commit to stable/11. Bump FreeBSD_Version in stable/11 following r331880 so that ports can do the right thing.
This is a direct commit to stable/11
Reported by: 0mp
|
#
331838 |
|
31-Mar-2018 |
dim |
Merge clang, llvm, lld, lldb, compiler-rt and libc++ 6.0.0 release, and several follow-up fixes.
MFC r327952:
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 6.0.0 (branches/release_60 r321788). Upstream has branched for the 6.0.0 release, which should be in about 6 weeks. Please report bugs and regressions, so we can get them into the release.
Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11 support to build; see UPDATING for more information.
MFC r328010:
Pull in r322473 from upstream llvm trunk (by Andrei Elovikov):
[LV] Don't call recordVectorLoopValueForInductionCast for newly-created IV from a trunc.
Summary: This method is supposed to be called for IVs that have casts in their use-def chains that are completely ignored after vectorization under PSE. However, for truncates of such IVs the same InductionDescriptor is used during creation/widening of both original IV based on PHINode and new IV based on TruncInst.
This leads to unintended second call to recordVectorLoopValueForInductionCast with a VectorLoopVal set to the newly created IV for a trunc and causes an assert due to attempt to store new information for already existing entry in the map. This is wrong and should not be done.
Fixes PR35773.
Reviewers: dorit, Ayal, mssimpso
Reviewed By: dorit
Subscribers: RKSimon, dim, dcaballe, hsaito, llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D41913
This should fix "Vector value already set for part" assertions when building the net/iodine and sysutils/daa2iso ports.
Reported by: jbeich PR: 224867, 224868
MFC r328090:
Pull in r322623 from upstream llvm trunk (by Andrew V. Tischenko):
Allow usage of X86-prefixes as separate instrs. Differential Revision: https://reviews.llvm.org/D42102
This should fix parse errors when x86 prefixes (such as 'lock' and 'rep') are followed by various non-mnemonic tokens, e.g. comments, .byte directives and labels.
PR: 224669, 225054
MFC r328091:
Revert r327340, as the workaround for rep prefixes followed by .byte directives is no longer needed after r328090.
MFC r328141 (by emaste):
lld: Fix for ld.lld does not accept "AT" syntax for declaring LMA region
AT> lma_region expression allows to specify the memory region for section load address.
Should fix [upstream LLVM] PR35684.
LLVM review: https://reviews.llvm.org/D41397
Obtained from: LLVM r322359 by George Rimar
MFC r328143 (by emaste):
lld: Handle parsing AT(ADDR(.foo-bar)).
The problem we had with it is that anything inside an AT is an expression, so we failed to parse the section name because of the - in it.
Requested by: royger Obtained from: LLVM r322801 by Rafael Espindola
MFC r328144 (by emaste):
lld: Fix incorrect physical address on self-referencing AT command.
When a section placement (AT) command references the section itself, the physical address of the section in the ELF header was calculated incorrectly due to alignment happening right after the location pointer's value was captured.
The problem was diagnosed and the first version of the patch written by Erick Reyes.
Obtained from: LLVM r322421 by Rafael Espindola
MFC r328145:
Pull in r322016 from upstream llvm trunk (by Sanjay Patel):
[ValueTracking] remove overzealous assert
The test is derived from a failing fuzz test: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=5008
Credit to @rksimon for pointing out the problem.
This should fix "Bad flavor while matching min/max" errors when building the graphics/libsixel and science/kst2 ports.
Reported by: jbeich PR: 225268, 225269
MFC r328146:
Pull in r322106 from upstream llvm trunk (by Alexey Bataev):
[COST]Fix PR35865: Fix cost model evaluation for shuffle on X86.
Summary: If the vector type is transformed to non-vector single type, the compile may crash trying to get vector information about non-vector type.
Reviewers: RKSimon, spatel, mkuper, hfinkel
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D41862
This should fix "Not a vector MVT!" errors when building the games/dhewm3 port.
Reported by: jbeich PR: 225271
MFC r328286 (by emaste):
lld: Don't mark a shared library as needed because of a lazy symbol.
Obtained from: LLVM r323221 by Rafael Esp?ndola
MFC r328381:
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 6.0.0 (branches/release_60 r323338).
PR: 224669
MFC r328513:
Pull in r322245 from upstream clang trunk (by Craig Topper):
[X86] Make -mavx512f imply -mfma and -mf16c in the frontend like it does in the backend.
Similarly, make -mno-fma and -mno-f16c imply -mno-avx512f.
Withou this "-mno-sse -mavx512f" ends up with avx512f being enabled in the frontend but disabled in the backend.
Reported by: pawel PR: 225488
MFC r328542 (by emaste):
lld: Use lookup instead of find. NFC, just simpler.
Obtained from: LLVM r323395 by Rafael Espindola
MFC r328543 (by emaste):
lld: Only lookup LMARegion once. NFC.
This is similar to how we handle MemRegion.
Obtained from: LLVM r323396 by Rafael Espindola
MFC r328544 (by emaste):
lld: Remove MemRegionOffset. NFC.
We can just use a member variable in MemoryRegion.
Obtained from: LLVM r323399 by Rafael Espindola
MFC r328545 (by emaste):
lld: Simplify. NFC.
Obtained from: LLVM r323440 by Rafael Espindola
MFC r328546 (by emaste):
lld: Improve LMARegion handling.
This fixes the crash reported at [LLVM] PR36083.
The issue is that we were trying to put all the sections in the same PT_LOAD and crashing trying to write past the end of the file.
This also adds accounting for used space in LMARegion, without it all 3 PT_LOADs would have the same physical address.
Obtained from: LLVM r323449 by Rafael Espindola
MFC r328547 (by emaste):
lld: Move LMAOffset from the OutputSection to the PhdrEntry. NFC.
If two sections are in the same PT_LOAD, their relatives offsets, virtual address and physical addresses are all the same.
[Rafael] initially wanted to have a single global LMAOffset, on the assumption that every ELF file was in practiced loaded contiguously in both physical and virtual memory.
Unfortunately that is not the case. The linux kernel has:
LOAD 0x200000 0xffffffff81000000 0x0000000001000000 0xced000 0xced000 R E 0x200000 LOAD 0x1000000 0xffffffff81e00000 0x0000000001e00000 0x15f000 0x15f000 RW 0x200000 LOAD 0x1200000 0x0000000000000000 0x0000000001f5f000 0x01b198 0x01b198 RW 0x200000 LOAD 0x137b000 0xffffffff81f7b000 0x0000000001f7b000 0x116000 0x1ec000 RWE 0x200000
The delta for all but the third PT_LOAD is the same: 0xffffffff80000000. [Rafael] thinks the 3rd one is a hack for implementing per cpu data, but we can't break that.
Obtained from: LLVM r323456 by Rafael Espindola
MFC r328548 (by emaste):
lld: Put the header in the first PT_LOAD even if that PT_LOAD has a LMAExpr
The root problem is that we were creating a PT_LOAD just for the header. That was technically valid, but inconvenient: we should not be making the ELF discontinuous.
The solution is to allow a section with LMAExpr to be added to a PT_LOAD if that PT_LOAD doesn't already have a LMAExpr.
LLVM PR: 36017 Obtained from: LLVM r323625 by Rafael Espindola
MFC r328594 (by emaste):
Pull in r322108 from upstream llvm trunk (by Rafael Esp?ndola):
Make one of the emitFill methods non virtual. NFC.
This is just preparatory work to fix [LLVM] PR35858.
MFC r328595 (by emaste):
Pull in r322123 from upstream llvm trunk (by Rafael Esp?ndola):
Don't create MCFillFragment directly.
Instead use higher level APIs that take care of most bookkeeping.
MFC r328596 (by emaste):
Pull in r322131 from upstream llvm trunk (by Rafael Esp?ndola):
Use a MCExpr for the size of MCFillFragment.
This allows the size to be found during ralaxation. This fixes [LLVM] pr35858.
Requested by: royger
MFC r328753:
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 6.0.0 (branches/release_60 r323948).
PR: 224669
MFC r328817:
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 6.0.0 (branches/release_60 r324090).
This introduces retpoline support, with the -mretpoline flag. The upstream initial commit message (r323155 by Chandler Carruth) contains quite a bit of explanation. Quoting:
Introduce the "retpoline" x86 mitigation technique for variant #2 of the speculative execution vulnerabilities disclosed today, specifically identified by CVE-2017-5715, "Branch Target Injection", and is one of the two halves to Spectre.
Summary: First, we need to explain the core of the vulnerability. Note that this is a very incomplete description, please see the Project Zero blog post for details: https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
The basis for branch target injection is to direct speculative execution of the processor to some "gadget" of executable code by poisoning the prediction of indirect branches with the address of that gadget. The gadget in turn contains an operation that provides a side channel for reading data. Most commonly, this will look like a load of secret data followed by a branch on the loaded value and then a load of some predictable cache line. The attacker then uses timing of the processors cache to determine which direction the branch took *in the speculative execution*, and in turn what one bit of the loaded value was. Due to the nature of these timing side channels and the branch predictor on Intel processors, this allows an attacker to leak data only accessible to a privileged domain (like the kernel) back into an unprivileged domain.
The goal is simple: avoid generating code which contains an indirect branch that could have its prediction poisoned by an attacker. In many cases, the compiler can simply use directed conditional branches and a small search tree. LLVM already has support for lowering switches in this way and the first step of this patch is to disable jump-table lowering of switches and introduce a pass to rewrite explicit indirectbr sequences into a switch over integers.
However, there is no fully general alternative to indirect calls. We introduce a new construct we call a "retpoline" to implement indirect calls in a non-speculatable way. It can be thought of loosely as a trampoline for indirect calls which uses the RET instruction on x86. Further, we arrange for a specific call->ret sequence which ensures the processor predicts the return to go to a controlled, known location. The retpoline then "smashes" the return address pushed onto the stack by the call with the desired target of the original indirect call. The result is a predicted return to the next instruction after a call (which can be used to trap speculative execution within an infinite loop) and an actual indirect branch to an arbitrary address.
On 64-bit x86 ABIs, this is especially easily done in the compiler by using a guaranteed scratch register to pass the target into this device. For 32-bit ABIs there isn't a guaranteed scratch register and so several different retpoline variants are introduced to use a scratch register if one is available in the calling convention and to otherwise use direct stack push/pop sequences to pass the target address.
This "retpoline" mitigation is fully described in the following blog post: https://support.google.com/faqs/answer/7625886
We also support a target feature that disables emission of the retpoline thunk by the compiler to allow for custom thunks if users want them. These are particularly useful in environments like kernels that routinely do hot-patching on boot and want to hot-patch their thunk to different code sequences. They can write this custom thunk and use `-mretpoline-external-thunk` *in addition* to `-mretpoline`. In this case, on x86-64 thu thunk names must be: ``` __llvm_external_retpoline_r11 ``` or on 32-bit: ``` __llvm_external_retpoline_eax __llvm_external_retpoline_ecx __llvm_external_retpoline_edx __llvm_external_retpoline_push ``` And the target of the retpoline is passed in the named register, or in the case of the `push` suffix on the top of the stack via a `pushl` instruction.
There is one other important source of indirect branches in x86 ELF binaries: the PLT. These patches also include support for LLD to generate PLT entries that perform a retpoline-style indirection.
The only other indirect branches remaining that we are aware of are from precompiled runtimes (such as crt0.o and similar). The ones we have found are not really attackable, and so we have not focused on them here, but eventually these runtimes should also be replicated for retpoline-ed configurations for completeness.
For kernels or other freestanding or fully static executables, the compiler switch `-mretpoline` is sufficient to fully mitigate this particular attack. For dynamic executables, you must compile *all* libraries with `-mretpoline` and additionally link the dynamic executable and all shared libraries with LLD and pass `-z retpolineplt` (or use similar functionality from some other linker). We strongly recommend also using `-z now` as non-lazy binding allows the retpoline-mitigated PLT to be substantially smaller.
When manually apply similar transformations to `-mretpoline` to the Linux kernel we observed very small performance hits to applications running typic al workloads, and relatively minor hits (approximately 2%) even for extremely syscall-heavy applications. This is largely due to the small number of indirect branches that occur in performance sensitive paths of the kernel.
When using these patches on statically linked applications, especially C++ applications, you should expect to see a much more dramatic performance hit. For microbenchmarks that are switch, indirect-, or virtual-call heavy we have seen overheads ranging from 10% to 50%.
However, real-world workloads exhibit substantially lower performance impact. Notably, techniques such as PGO and ThinLTO dramatically reduce the impact of hot indirect calls (by speculatively promoting them to direct calls) and allow optimized search trees to be used to lower switches. If you need to deploy these techniques in C++ applications, we *strongly* recommend that you ensure all hot call targets are statically linked (avoiding PLT indirection) and use both PGO and ThinLTO. Well tuned servers using all of these techniques saw 5% - 10% overhead from the use of retpoline.
We will add detailed documentation covering these components in subsequent patches, but wanted to make the core functionality available as soon as possible. Happy for more code review, but we'd really like to get these patches landed and backported ASAP for obvious reasons. We're planning to backport this to both 6.0 and 5.0 release streams and get a 5.0 release with just this cherry picked ASAP for distros and vendors.
This patch is the work of a number of people over the past month: Eric, Reid, Rui, and myself. I'm mailing it out as a single commit due to the time sensitive nature of landing this and the need to backport it. Huge thanks to everyone who helped out here, and everyone at Intel who helped out in discussions about how to craft this. Also, credit goes to Paul Turner (at Google, but not an LLVM contributor) for much of the underlying retpoline design.
Reviewers: echristo, rnk, ruiu, craig.topper, DavidKreitzer
Subscribers: sanjoy, emaste, mcrosier, mgorny, mehdi_amini, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D41723
PR: 224669
MFC r329033:
Pull in r324594 from upstream clang trunk (by Alexander Ivchenko):
Fix for #31362 - ms_abi is implemented incorrectly for values >=16 bytes.
Summary: This patch is a fix for following issue: https://bugs.llvm.org/show_bug.cgi?id=31362 The problem was caused by front end lowering C calling conventions without taking into account calling conventions enforced by attribute. In this case win64cc was no correctly lowered on targets other than Windows.
Reviewed By: rnk (Reid Kleckner)
Differential Revision: https://reviews.llvm.org/D43016
Author: belickim <mateusz.belicki@intel.com>
This fixes clang 6.0.0 assertions when building the emulators/wine and emulators/wine-devel ports, and should also make it use the correct Windows calling conventions. Bump __FreeBSD_version to make the fix easy to detect.
PR: 224863
MFC r329223:
Pull in r323998 from upstream clang trunk (by Richard Smith):
PR36157: When injecting an implicit function declaration in C89, find the right DeclContext rather than injecting it wherever we happen to be.
This avoids creating functions whose DeclContext is a struct or similar.
This fixes assertion failures when parsing certain not-completely-valid struct declarations.
Reported by: ae PR: 225862
MFC r329410:
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 6.0.0 (branches/release_60 r325330).
PR: 224669
MFC r329983:
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 6.0.0 (branches/release_60 r325932). This corresponds to 6.0.0 rc3.
PR: 224669
MFC r330384:
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 6.0.0 release (upstream r326565).
Release notes for llvm, clang and lld will be available here soon: <http://releases.llvm.org/6.0.0/docs/ReleaseNotes.html> <http://releases.llvm.org/6.0.0/tools/clang/docs/ReleaseNotes.html> <http://releases.llvm.org/6.0.0/tools/lld/docs/ReleaseNotes.html>
Relnotes: yes PR: 224669
MFC r330686:
Pull in r326882 from upstream llvm trunk (by Sjoerd Meijer):
[ARM] Fix for PR36577
Don't PerformSHLSimplify if the given node is used by a node that also uses a constant because we may get stuck in an infinite combine loop.
bugzilla: https://bugs.llvm.org/show_bug.cgi?id=36577
Patch by Sam Parker.
Differential Revision: https://reviews.llvm.org/D44097
This fixes a hang when compiling one particular file in java/openjdk8 for armv6 and armv7.
Reported by: swills PR: 226388
MFC r331065:
Pull in r327638 from upstream llvm trunk (by Matthew Simpson):
[ConstantFolding, InstSimplify] Handle more vector GEPs
This patch addresses some additional cases where the compiler crashes upon encountering vector GEPs. This should fix PR36116.
Differential Revision: https://reviews.llvm.org/D44219 Reference: https://bugs.llvm.org/show_bug.cgi?id=36116
This fixes an assertion when building the emulators/snes9x port.
Reported by: jbeich PR: 225471
MFC r331066:
Pull in r321999 from upstream clang trunk (by Ivan A. Kosarev):
[CodeGen] Fix TBAA info for accesses to members of base classes
Resolves: Bug 35724 - regression (r315984): fatal error: error in backend: Broken function found (Did not see access type in access path!) https://bugs.llvm.org/show_bug.cgi?id=35724
Differential Revision: https://reviews.llvm.org/D41547
This fixes "Did not see access type in access path" fatal errors when building the devel/gdb port (version 8.1).
Reported by: jbeich PR: 226658
MFC r331366:
Pull in r327101 from upstream llvm trunk (by Rafael Espindola):
Don't treat .symver as a regular alias definition.
This patch starts simplifying the handling of .symver.
For now it just moves the responsibility for creating an alias down to the streamer. With that the asm streamer can pass a .symver unchanged, which is nice since gas cannot parse "foo@bar = zed".
In a followup I hope to move the handling down to the writer so that we don't need special hacks for avoiding breaking names with @@@ on windows.
Pull in r327160 from upstream llvm trunk (by Rafael Espindola):
Delay creating an alias for @@@.
With this we only create an alias for @@@ once we know if it should use @ or @@. This avoids last minutes renames and hacks to handle MS names.
This only handles the ELF writer. LTO still has issues with @@@ aliases.
Pull in r327928 from upstream llvm trunk (by Vitaly Buka):
Object: Move attribute calculation into RecordStreamer. NFC
Summary: Preparation for D44274
Reviewers: pcc, espindola
Subscribers: hiraditya
Differential Revision: https://reviews.llvm.org/D44276
Pull in r327930 from upstream llvm trunk (by Vitaly Buka):
Object: Fix handling of @@@ in .symver directive
Summary: name@@@nodename is going to be replaced with name@@nodename if symbols is defined in the assembled file, or name@nodename if undefined. https://sourceware.org/binutils/docs/as/Symver.html
Fixes PR36623
Reviewers: pcc, espindola
Subscribers: mehdi_amini, hiraditya
Differential Revision: https://reviews.llvm.org/D44274
Together, these changes fix handling of @@@ in .symver directives when doing Link Time Optimization.
Reported by: Shawn Webb <shawn.webb@hardenedbsd.org>
MFC r331731:
Pull in r328738 from upstream lld trunk (by Rafael Espindola):
Strip @VER suffices from the LTO output.
This fixes pr36623.
The problem is that we have to parse versions out of names before LTO so that LTO can use that information.
When we get the LTO produced .o files, we replace the previous symbols with the LTO produced ones, but they still have @ in their names.
We could just trim the name directly, but calling parseSymbolVersion to do it is simpler.
This is a follow-up to r331366, since we discovered that lld could append version strings to symbols twice, when using Link Time Optimization.
|
#
331722 |
|
29-Mar-2018 |
eadler |
Revert r330897:
This was intended to be a non-functional change. It wasn't. The commit message was thus wrong. In addition it broke arm, and merged crypto related code.
Revert with prejudice.
This revert skips files touched in r316370 since that commit was since MFCed. This revert also skips files that require $FreeBSD$ property changes.
Thank you to those who helped me get out of this mess including but not limited to gonzo, kevans, rgrimes.
Requested by: gjb (re)
|
#
331219 |
|
19-Mar-2018 |
dim |
Merge retpoline support from the upstream llvm, clang and lld 5.0 branches. Upstream merge revisions:
r324007: merging r323155 for llvm r324009: merging r323915 for llvm r324012: merging r323155 for clang r324025: merging r323155 for lld, with modifications to handle int3 fill r324026: merging r323288 for lld r325088: merging r324449 for llvm r325089: merging r324645 for llvm r325090: merging r325049 for llvm r325091: merging r325085 for llvm
Original commit messages:
r323155 (by Chandler Carruth):
Introduce the "retpoline" x86 mitigation technique for variant #2 of the speculative execution vulnerabilities disclosed today, specifically identified by CVE-2017-5715, "Branch Target Injection", and is one of the two halves to Spectre.
Summary: First, we need to explain the core of the vulnerability. Note that this is a very incomplete description, please see the Project Zero blog post for details: https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
The basis for branch target injection is to direct speculative execution of the processor to some "gadget" of executable code by poisoning the prediction of indirect branches with the address of that gadget. The gadget in turn contains an operation that provides a side channel for reading data. Most commonly, this will look like a load of secret data followed by a branch on the loaded value and then a load of some predictable cache line. The attacker then uses timing of the processors cache to determine which direction the branch took *in the speculative execution*, and in turn what one bit of the loaded value was. Due to the nature of these timing side channels and the branch predictor on Intel processors, this allows an attacker to leak data only accessible to a privileged domain (like the kernel) back into an unprivileged domain.
The goal is simple: avoid generating code which contains an indirect branch that could have its prediction poisoned by an attacker. In many cases, the compiler can simply use directed conditional branches and a small search tree. LLVM already has support for lowering switches in this way and the first step of this patch is to disable jump-table lowering of switches and introduce a pass to rewrite explicit indirectbr sequences into a switch over integers.
However, there is no fully general alternative to indirect calls. We introduce a new construct we call a "retpoline" to implement indirect calls in a non-speculatable way. It can be thought of loosely as a trampoline for indirect calls which uses the RET instruction on x86. Further, we arrange for a specific call->ret sequence which ensures the processor predicts the return to go to a controlled, known location. The retpoline then "smashes" the return address pushed onto the stack by the call with the desired target of the original indirect call. The result is a predicted return to the next instruction after a call (which can be used to trap speculative execution within an infinite loop) and an actual indirect branch to an arbitrary address.
On 64-bit x86 ABIs, this is especially easily done in the compiler by using a guaranteed scratch register to pass the target into this device. For 32-bit ABIs there isn't a guaranteed scratch register and so several different retpoline variants are introduced to use a scratch register if one is available in the calling convention and to otherwise use direct stack push/pop sequences to pass the target address.
This "retpoline" mitigation is fully described in the following blog post: https://support.google.com/faqs/answer/7625886
We also support a target feature that disables emission of the retpoline thunk by the compiler to allow for custom thunks if users want them. These are particularly useful in environments like kernels that routinely do hot-patching on boot and want to hot-patch their thunk to different code sequences. They can write this custom thunk and use `-mretpoline-external-thunk` *in addition* to `-mretpoline`. In this case, on x86-64 thu thunk names must be: ``` __llvm_external_retpoline_r11 ``` or on 32-bit: ``` __llvm_external_retpoline_eax __llvm_external_retpoline_ecx __llvm_external_retpoline_edx __llvm_external_retpoline_push ```
And the target of the retpoline is passed in the named register, or in the case of the `push` suffix on the top of the stack via a `pushl` instruction.
There is one other important source of indirect branches in x86 ELF binaries: the PLT. These patches also include support for LLD to generate PLT entries that perform a retpoline-style indirection.
The only other indirect branches remaining that we are aware of are from precompiled runtimes (such as crt0.o and similar). The ones we have found are not really attackable, and so we have not focused on them here, but eventually these runtimes should also be replicated for retpoline-ed configurations for completeness.
For kernels or other freestanding or fully static executables, the compiler switch `-mretpoline` is sufficient to fully mitigate this particular attack. For dynamic executables, you must compile *all* libraries with `-mretpoline` and additionally link the dynamic executable and all shared libraries with LLD and pass `-z retpolineplt` (or use similar functionality from some other linker). We strongly recommend also using `-z now` as non-lazy binding allows the retpoline-mitigated PLT to be substantially smaller.
When manually apply similar transformations to `-mretpoline` to the Linux kernel we observed very small performance hits to applications running typical workloads, and relatively minor hits (approximately 2%) even for extremely syscall-heavy applications. This is largely due to the small number of indirect branches that occur in performance sensitive paths of the kernel.
When using these patches on statically linked applications, especially C++ applications, you should expect to see a much more dramatic performance hit. For microbenchmarks that are switch, indirect-, or virtual-call heavy we have seen overheads ranging from 10% to 50%.
However, real-world workloads exhibit substantially lower performance impact. Notably, techniques such as PGO and ThinLTO dramatically reduce the impact of hot indirect calls (by speculatively promoting them to direct calls) and allow optimized search trees to be used to lower switches. If you need to deploy these techniques in C++ applications, we *strongly* recommend that you ensure all hot call targets are statically linked (avoiding PLT indirection) and use both PGO and ThinLTO. Well tuned servers using all of these techniques saw 5% - 10% overhead from the use of retpoline.
We will add detailed documentation covering these components in subsequent patches, but wanted to make the core functionality available as soon as possible. Happy for more code review, but we'd really like to get these patches landed and backported ASAP for obvious reasons. We're planning to backport this to both 6.0 and 5.0 release streams and get a 5.0 release with just this cherry picked ASAP for distros and vendors.
This patch is the work of a number of people over the past month: Eric, Reid, Rui, and myself. I'm mailing it out as a single commit due to the time sensitive nature of landing this and the need to backport it. Huge thanks to everyone who helped out here, and everyone at Intel who helped out in discussions about how to craft this. Also, credit goes to Paul Turner (at Google, but not an LLVM contributor) for much of the underlying retpoline design.
Reviewers: echristo, rnk, ruiu, craig.topper, DavidKreitzer
Subscribers: sanjoy, emaste, mcrosier, mgorny, mehdi_amini, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D41723
r323915 (by Chandler Carruth):
[x86] Make the retpoline thunk insertion a machine function pass.
Summary: This removes the need for a machine module pass using some deeply questionable hacks. This should address PR36123 which is a case where in full LTO the memory usage of a machine module pass actually ended up being significant.
We should revert this on trunk as soon as we understand and fix the memory usage issue, but we should include this in any backports of retpolines themselves.
Reviewers: echristo, MatzeB
Subscribers: sanjoy, mcrosier, mehdi_amini, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D42726
r323288 (by Rui Ueyama):
Fix retpoline PLT header size for i386.
Differential Revision: https://reviews.llvm.org/D42397
r324449 (by Chandler Carruth):
[x86/retpoline] Make the external thunk names exactly match the names that happened to end up in GCC.
This is really unfortunate, as the names don't have much rhyme or reason to them. Originally in the discussions it seemed fine to rely on aliases to map different names to whatever external thunk code developers wished to use but there are practical problems with that in the kernel it turns out. And since we're discovering this practical problems late and since GCC has already shipped a release with one set of names, we are forced, yet again, to blindly match what is there.
Somewhat rushing this patch out for the Linux kernel folks to test and so we can get it patched into our releases.
Differential Revision: https://reviews.llvm.org/D42998
r324645 (by David Woodhouse):
[X86] Support 'V' register operand modifier
This allows the register name to be printed without the leading '%'. This can be used for emitting calls to the retpoline thunks from inline asm.
r325049 (by Reid Kleckner):
[X86] Use EDI for retpoline when no scratch regs are left
Summary: Instead of solving the hard problem of how to pass the callee to the indirect jump thunk without a register, just use a CSR. At a call boundary, there's nothing stopping us from using a CSR to hold the callee as long as we save and restore it in the prologue.
Also, add tests for this mregparm=3 case. I wrote execution tests for __llvm_retpoline_push, but they never got committed as lit tests, either because I never rewrote them or because they got lost in merge conflicts.
Reviewers: chandlerc, dwmw2
Subscribers: javed.absar, kristof.beyls, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D43214
r325085 (by Reid Kleckner):
[X86] Remove dead code from retpoline thunk generation
Differential Revision: https://reviews.freebsd.org/D14720
|
#
330897 |
|
14-Mar-2018 |
eadler |
Partial merge of the SPDX changes
These changes are incomplete but are making it difficult to determine what other changes can/should be merged.
No objections from: pfg
|
#
329981 |
|
25-Feb-2018 |
hselasky |
Bump the FreeBSD version to conclude the recent LinuxKPI related updates.
This is a direct commit.
Sponsored by: Mellanox Technologies
|
#
329450 |
|
17-Feb-2018 |
hselasky |
Bump the FreeBSD version after r329383 to indicate that the cmpxchg() macro is now fully functional in the LinuxKPI.
This is a direct commit.
Sponsored by: Mellanox Technologies
|
#
328653 |
|
01-Feb-2018 |
hselasky |
MFC r310014-r327788: This is an overwrite merge backport of the LinuxKPI from FreeBSD-head. Following is a complete list of MFC'ed revisions and also partially MFC'ed revisions in the end. The MFC'ed revision are listed in incremental order.
Bump the __FreeBSD_version to force recompilation of any external kernel modules.
Sponsored by: Mellanox Technologies
MFC r310014: Remove the only user of sysctl_add_oid().
My plan is to change this function's prototype at some point in the future to add a new label argument, which can be used to export all of sysctl as metrics that can be scraped by Prometheus. Switch over this caller to use the macro wrapper counterpart.
MFC r310031: linuxkpi: Fix not-found case of linux_pci_find_irq_dev
Linux list_for_each_entry() does not neccessarily end with the iterator NULL (it may be an offset from NULL if the list member is not the first element of the member struct).
Reported by: Coverity CID: 1366940 Reviewed by: hselasky@ Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D8780
MFC r313806: Whitespace fix.
Obtained from: kmacy @ Sponsored by: Mellanox Technologies
MFC r313807: Allow passing a constant atomic_t to atomic_read().
Obtained from: kmacy @ Sponsored by: Mellanox Technologies
MFC r313808: Implement more LinuxKPI atomic functions and macros.
Obtained from: kmacy @ Sponsored by: Mellanox Technologies
MFC r313810: Allow container_of() to be used with constant data pointers.
Obtained from: kmacy @ Sponsored by: Mellanox Technologies
MFC r313872: Implement GFP_DMA32 flag in the LinuxKPI. Define all FreeBSD native GFP bits as GFP_NATIVE_MASK.
Obtained from: kmacy @ Sponsored by: Mellanox Technologies
MFC r314040: Make the LinuxKPI task struct persistent accross system calls.
A set of helper functions have been added to manage the life of the LinuxKPI task struct. When an external system call or task is invoked, a check is made to create the task struct by demand. A thread destructor callback is registered to free the task struct when a thread exits to avoid memory leaks.
This change lays the ground for emulating the Linux kernel more closely which is a dependency by the code using the LinuxKPI APIs.
Add new dedicated td_lkpi_task field has been added to struct thread instead of abusing td_retval[1].
Fix some header file inclusions to make LINT kernel build properly after this change.
Bump the __FreeBSD_version to force a rebuild of all kernel modules.
Sponsored by: Mellanox Technologies
MFC r314043: Add support for LinuxKPI tasklets.
Tasklets are implemented using a taskqueue and a small statemachine on top. The additional statemachine is required to ensure all LinuxKPI tasklets get serialized. FreeBSD taskqueues do not guarantee serialisation of its tasks, except when there is only one worker thread configured.
Sponsored by: Mellanox Technologies
MFC r314044: Streamline the LinuxKPI spinlock wrappers.
1) Add better spinlock debug names when WITNESS_ALL is defined.
2) Make sure that the calling thread gets bound to the current CPU while a spinlock is locked. Some Linux kernel code depends on that the CPU ID doesn't change while a spinlock is locked.
3) Add support for using LinuxKPI spinlocks during a panic().
Sponsored by: Mellanox Technologies
MFC r314050: Replace dummy implementation of RCU in the LinuxKPI with one based on the in-kernel concurrency kit's ck_epoch API. Factor RCU hlist_xxx() functions into own rculist.h header file.
Obtained from: kmacy @ Sponsored by: Mellanox Technologies
MFC r314105: Improve LinuxKPI scatter list support.
The i915kms driver in Linux 4.9 reimplement parts of the scatter list functions with regards to performance. In other words there is not so much room for changing structure layouts and functionality if the i915kms should be built AS-IS. This patch aligns the scatter list support to what is expected by the i915kms driver. Remove some comments not needed while at it.
Obtained from: kmacy @ Sponsored by: Mellanox Technologies
MFC r314106: Optimise unmapped LinuxKPI page allocations.
When allocating unmapped pages, take advantage of the direct map on AMD64 to get the virtual address corresponding to a page. Else all pages allocated must be mapped because sometimes the virtual address of a page is requested.
Move all page allocation and deallocation code into an own C-file.
Add support for GFP_DMA32, GFP_KERNEL, GFP_ATOMIC and __GFP_ZERO allocation flags.
Make a clear separation between mapped and unmapped allocations.
Obtained from: kmacy @ Sponsored by: Mellanox Technologies
MFC r314109: Convert magic values into macros in the LinuxKPI scatterlist implementation.
Suggested by: cem @ Sponsored by: Mellanox Technologies
MFC r314136: Implement __test_and_clear_bit() and __test_and_set_bit() in the LinuxKPI.
The clang compiler will optimise these functions down to three AMD64 instructions if the bit argument is a constant during compilation.
Sponsored by: Mellanox Technologies
MFC r314205: Implement BIT_ULL() macro in the LinuxKPI.
Sponsored by: Mellanox Technologies
MFC r314207: Implement srcu_dereference() macro in the LinuxKPI.
Sponsored by: Mellanox Technologies
MFC r314214: Prototype device structure to ensure LinuxKPI header file can be included standalone.
Sponsored by: Mellanox Technologies
MFC r314215: Implement more string functions in the LinuxKPI.
Sponsored by: Mellanox Technologies
MFC r314336: Define __sum16 type in the LinuxKPI.
Sponsored by: Mellanox Technologies
MFC r314337: Implement more bit operation functions in the LinuxKPI. Some minor whitespace nits while at it.
Obtained from: kmacy @ Sponsored by: Mellanox Technologies
MFC r314604: Update the LinuxKPI RCU and SRCU wrappers for the concurrency kit, CK.
- Optimise the RCU implementation to not allocate and free ck_epoch_records during runtime. Instead allocate two sets of ck_epoch_records per CPU for general purpose use. The first set is only used for reader locks and the second set is only used for synchronization and barriers and is protected with a regular mutex to prevent simultaneous issues.
- Move the task structure away from the rcu_head structure and into the per-CPU structures. This allows the size of the rcu_head structure to be reduced down to the size of two pointers.
- Fix a bug where the linux_rcu_barrier() function only waited for one per-CPU epoch record to be completed instead of all.
- Use a critical section or a mutex to protect ck_epoch_begin() and ck_epoch_end() depending on RCU or SRCU type. All the ck_epoch_xxx() functions, except ck_epoch_register(), ck_epoch_unregister() and ck_epoch_recycle() are not re-entrant and needs a critical section or a mutex to operate in the LinuxKPI, after inspecting the CK implementation of the above mentioned functions. The simultaneous issues arise from per-CPU epoch records being shared between multiple threads depending on the amount of taskswitching and how many threads are involved with the RCU and SRCU operations.
- Properly free all epoch records by using safe list traversal at LinuxKPI module unload. It turns out the ck_epoch_recycle() always have the records on an internal list and use a flag in the epoch record to track allocated and free entries. This would lead to use after free during module unload.
- Remove redundant synchronize_rcu() call from the linux_compat_uninit() function. Let the linux_rcu_runtime_uninit() function do the final rcu_barrier() instead.
Sponsored by: Mellanox Technologies
MFC r314675: Remove duplicate prototype in the LinuxKPI to fix compilation warning.
Reported by: emaste @ Sponsored by: Mellanox Technologies
MFC r314771: Give LinuxKPI Read-Write semaphores better debug names when WITNESS_ALL is defined. The lock name is based on the filename and line number where the initialisation happens.
Sponsored by: Mellanox Technologies
MFC r314772: Implement DECLARE_RWSEM() macro in the LinuxKPI to initialize a Read-Write semaphore during module init time.
Sponsored by: Mellanox Technologies
MFC r314774: Implement add_timer_on() function in the LinuxKPI.
Obtained from: kmacy @ Sponsored by: Mellanox Technologies
MFC r314843: LinuxKPI workqueue cleanup.
This change makes the workqueue implementation behave more like in Linux, both functionality wise and structure wise.
All workqueue code has been moved to linux_work.c
Add an atomic based statemachine to the work_struct to ensure proper operation. Prior to this change struct_work was directly mapped to a FreeBSD task. When a taskqueue has multiple threads the same task may end up being executed on more than one worker thread simultaneously. This might cause problems with code coming from Linux, which expects serial behaviour, similar to Linux tasklets.
Move all global workqueue function names into the linux_xxx domain to avoid symbol name clashes in the future.
Implement a few more workqueue related functions and macros.
Create two multithreaded taskqueues for the LinuxKPI during module load, one for time-consuming callbacks and one for non-time consuming callbacks.
Sponsored by: Mellanox Technologies
MFC r314853: Use grouptaskqueue for tasklets in the LinuxKPI.
This avoids creating own per-CPU threads and also ensures the tasklet execution happens on the same CPU core invoking the tasklet.
Sponsored by: Mellanox Technologies
MFC r314859: Make sure jiffies value is cast to an integer in the LinuxKPI before doing millisecond conversion. Under FreeBSD jiffies are 32-bit.
Sponsored by: Mellanox Technologies
MFC r314861: Implement time_is_after_eq_jiffies() function in the LinuxKPI.
Sponsored by: Mellanox Technologies
MFC r314904: Implement eth_zero_addr() in the LinuxKPI.
Sponsored by: Mellanox Technologies
MFC r314905: Cleanup the LinuxKPI slab implementation.
Put large functions into linux_slab.c instead of declaring them static inline.
Add support for more memory allocation wrappers like kmalloc_array() and __vmalloc().
Make sure either the M_WAITOK or the M_NOWAIT flag is set and mask away unused memory allocation flags before calling FreeBSD's malloc() routine.
Move kmalloc_node() definition to slab.h where it belongs.
Implement support for the SLAB_DESTROY_BY_RCU feature when creating a kmem_cache which basically means kmem_cache memory is freed using call_rcu().
Sponsored by: Mellanox Technologies
MFC r314920: Fix compilation warning for powerpc64 by not using const keyword in return types:
Type qualifiers ignored on function return type [-Wreturn-type]
Reported by: andreast @ Sponsored by: Mellanox Technologies
MFC r314953: Don't create any threads before SI_SUB_INIT_IF in the LinuxKPI. Else kthread_add() will assert it is called too soon. This fixes a startup issue when COMPAT_LINUXKPI is in enabled the kernel configuration file.
Reported by: Michael Butler <imb@protected-networks.net> Sponsored by: Mellanox Technologies
MFC r314965: Cleanup the LinuxKPI mutex wrappers.
Add support for using mutexes during KDB and shutdown. This is also required for doing mode-switching during panic for drm-next.
Add new mutex functions mutex_init_witness() and mutex_destroy() allowing LinuxKPI mutexes to be tracked by witness.
Declare mutex_is_locked() and mutex_is_owned() like inline functions to get cleaner warnings. These functions are used inside WARN_ON() statements which might look a bit odd if these functions get fully expanded.
Give mutexes better debug names through the mutex_name() macro when WITNESS_ALL is defined. The mutex_name() macro can prefix parts of the filename and line number before the mutex name.
Sponsored by: Mellanox Technologies
MFC r314970: Implement support for mutexes with deadlock avoidance in the LinuxKPI.
When locking a mutex and deadlock is detected the first mutex lock call that sees the deadlock will return -EDEADLK .
Sponsored by: Mellanox Technologies
MFC r314971: Fix implementation of the DECLARE_WORK() macro in the LinuxKPI to fully initialize the declared work structure and not only the function callback pointer.
Sponsored by: Mellanox Technologies
MFC r315244: Set "current" pointer for LinuxKPI interrupts and timer callbacks.
Sponsored by: Mellanox Technologies
MFC r315410: Define some more LinuxKPI task related macros.
Obtained from: kmacy @ Sponsored by: Mellanox Technologies
MFC r315419: Implement more userspace memory access functions in the LinuxKPI.
Obtained from: kmacy @ Sponsored by: Mellanox Technologies
MFC r315420: The LinuxKPI pagefault disable and enable functions can only be used pairwise to support the FreeBSD way of pushing and popping the page fault flags. Ensure this by requiring every occurrence of pagefault disable function call to have a corresponding pagefault enable call.
Obtained from: kmacy @ Sponsored by: Mellanox Technologies
MFC r315422: Use __LP64__ to detect presence of suword64() to fix linking and loading of the LinuxKPI on 32-bit platforms.
Reported by: lwhsu @ Sponsored by: Mellanox Technologies
MFC r315442: Add comment describing the use of pagefault_disable() and pagefault_enable() in the LinuxKPI.
Suggested by: rpokala@ Sponsored by: Mellanox Technologies
MFC r315443: Implement minimalistic memory mapping structure, struct mm_struct, and some associated helper functions in the LinuxKPI. Let the existing linux_alloc_current() function allocate and initialize the new structure and let linux_free_current() drop the refcount on the memory mapping structure. When the mm_struct's refcount reaches zero, the structure is freed.
Obtained from: kmacy @ Sponsored by: Mellanox Technologies
MFC r315457: Implement get_pid_task(), pid_task() and some other PID helper functions in the LinuxKPI. Add a usage atomic to the task_struct structure to facilitate refcounting the task structure when returned from get_pid_task(). The get_task_struct() and put_task_struct() function is used to manage atomic refcounting. After this change the task_struct should only be freed through put_task_struct().
Obtained from: kmacy @ Sponsored by: Mellanox Technologies
MFC r315713: Add support for more IPv4 and IPv6 related macros in the LinuxKPI.
Sponsored by: Mellanox Technologies
MFC r315714: Add full VNET support to the inet_get_local_port_range() function in the LinuxKPI.
Sponsored by: Mellanox Technologies
MFC r315719: Extend cmpxchg() to support 8- and 16-bit values, and add xchg().
These are needed to support updated revisions of the DRM code.
Reviewed by: hselasky (previous version)
MFC r315856: Add support for ratelimited printouts in the LinuxKPI.
Sponsored by: Mellanox Technologies
MFC r315859: Function macros are preferred in the LinuxKPI.
Sponsored by: Mellanox Technologies
MFC r315863: Add proper error checking for the string to number conversion functions in the LinuxKPI.
Sponsored by: Mellanox Technologies
MFC r315864: Use ppsratecheck() for ratelimiting in the LinuxKPI.
Suggested by: cem @ Sponsored by: Mellanox Technologies
MFC r316033: Implement a series of physical page management related functions in the LinuxKPI for accessing user-space memory in the kernel.
Add functions to hold and wire physical page(s) based on a given range of user-space virtual addresses.
Add functions to get and put a reference on, wire, hold, mark accessed, copy and dirty a physical page.
Add new VM related structures and defines as a preparation step for advancing the memory map capabilities of the LinuxKPI.
Add function to figure out if a virtual address was allocated using malloc().
Add function to convert a virtual kernel address into its physical page pointer.
Obtained from: kmacy @ Sponsored by: Mellanox Technologies
MFC r316034: Add more platforms supporting the direct map feature in the LinuxKPI.
Sponsored by: Mellanox Technologies
MFC r316035: Implement vmalloc_32() in the LinuxKPI.
Obtained from: kmacy @ Sponsored by: Mellanox Technologies
MFC r316521: Implement down_write_killable() in the LinuxKPI.
Sponsored by: Mellanox Technologies
MFC r316522: Unify error handling when si_drv1 is NULL in the LinuxKPI.
Make sure the character device poll callback function does not return an error code, but a POLLXXX value, in case of failure.
Sponsored by: Mellanox Technologies
MFC r316561: Before registering a new mm_struct in the LinuxKPI check if other tasks in the belonging procedure already have a valid mm_struct and reference that instead.
The mm_struct in the LinuxKPI should be shared among all tasks belonging to the same procedure. This has to do with with the mmap_sem semaphore which should serialize all VM operations inside a given procedure. Linux based drivers depend on this behaviour.
Sponsored by: Mellanox Technologies
MFC r316562: Implement proper support for memory map operations in the LinuxKPI, like open, close and fault using the character device pager.
Some notes about the implementation:
1) Linux drivers set the vm_ops and vm_private_data fields during a mmap() call to indicate that the driver wants to use the LinuxKPI VM operations. Else these operations are not used.
2) The vm_private_data pointer is associated with a VM area structure and inserted into an internal LinuxKPI list. If the vm_private_data pointer already exists, the existing VM area structure is used instead of the allocated one which gets freed.
3) The LinuxKPI's vm_private_data pointer is used as the callback handle for the FreeBSD VM object. The VM subsystem in FreeBSD has a similar list to identify equal handles and will only call the character device pager's close function once.
4) All LinuxKPI VM operations are serialized through the mmap_sem sempaphore, which is per procedure, which prevents simultaneous access to the shared VM area structure when receiving page faults.
Obtained from: kmacy @ Sponsored by: Mellanox Technologies
MFC r316563: Fix implementation of task_pid_group_leader() in the LinuxKPI.
In FreeBSD thread IDs and procedure IDs have distinct number spaces. When asking for the group leader task ID in the LinuxKPI, return the procedure ID and let this resolve to the first task in the procedure having a valid LinuxKPI task structure pointer.
Sponsored by: Mellanox Technologies
MFC r316564: Implement need_resched() in the LinuxKPI.
Obtained from: kmacy @ Sponsored by: Mellanox Technologies
MFC r316565: Define VM_READ, VM_WRITE and VM_EXEC in the LinuxKPI.
Sponsored by: Mellanox Technologies
MFC r316568: Cleanup the bitmap_xxx() functions in the LinuxKPI:
- Move all bitmap related functions from bitops.h to bitmap.h, similar to what Linux does.
- Apply some minor code cleanup and simplifications to optimize the generated code when using static inline functions.
- Implement the following list of bitmap functions which are needed by drm-next and ibcore: - bitmap_find_next_zero_area_off() - bitmap_find_next_zero_area() - bitmap_or() - bitmap_and() - bitmap_xor()
- Add missing include directives to the qlnxe driver (davidcs@ has been notified)
Sponsored by: Mellanox Technologies
MFC r316606: The __stringify() macro in the LinuxKPI should expand any macros before stringifying.
Sponsored by: Mellanox Technologies
MFC r316609: Create the LinuxKPI current task structure on the fly if it doesn't exist when the current macro is used.
Sponsored by: Mellanox Technologies
MFC r316656: Fix compilation of LinuxKPI for PowerPC.
Found by: emaste @ Sponsored by: Mellanox Technologies
MFC r317135: Zero number of CPUs should be translated into the default number of CPUs when allocating a LinuxKPI workqueue. This also ensures that the created taskqueue always have a non-zero number of worker threads.
Sponsored by: Mellanox Technologies
MFC r317137: Fix problem regarding priority inversion when using the concurrency kit, CK, in the LinuxKPI.
When threads are pinned to a CPU core or when there is only one CPU, it can happen that a higher priority thread can call the CK synchronize function while a lower priority thread holds the read lock. Because the CK's synchronize is a simple wait loop this can lead to a deadlock situation. To solve this problem use the recently introduced CK's wait callback function.
When detecting a CK blocking condition figure out the lowest priority among the blockers and update the calling thread's priority and yield. If another CPU core is holding the read lock, pin the thread to the blocked CPU core and update the priority. The calling threads priority and CPU bindings are restored before return.
If a thread holding a CK read lock is detected to be sleeping, pause() will be used instead of yield().
Sponsored by: Mellanox Technologies
MFC r317138: Use __typeof() instead of typeof() in some RCU related macros in the LinuxKPI.
Sponsored by: Mellanox Technologies
MFC r317504: Prefer to use real virtual address over direct map address in the linux_page_address() function in the LinuxKPI. This solves an issue where the return value from linux_page_address() is passed to kmem_free().
Sponsored by: Mellanox Technologies
MFC r317651: Add on_each_cpu() and wbinvd_on_all_cpus().
Reviewed by: hselasky Differential Revision: https://reviews.freebsd.org/D10550
MFC r317828: Fix for use after free in the LinuxKPI.
Background: The same VM object might be shared by multiple processes and the mm_struct is usually freed when a process exits.
Grab a reference on the mm_struct while the vmap is in the linux_vma_head list in case the first process which inserted a VM object has exited.
Tested by: kwm @ Sponsored by: Mellanox Technologies
MFC r317839: Use pmap_invalidate_cache() to implement wbinvd_on_all_cpus().
Suggested by: jhb X-MFC with: r317651
MFC r318026: Fix init order in the LinuxKPI for RCU support.
CPU_FOREACH() is not available until SI_SUB_CPU at SI_ORDER_ANY when the LinuxKPI is loaded as part of the kernel.
Sponsored by: Mellanox Technologies
MFC r318590: Add get_cpu() and put_cpu().
MFC r319229: Add some miscellaneous definitions to support DRM drivers.
Reviewed by: hselasky Differential Revision: https://reviews.freebsd.org/D10985
MFC r319312: Make sure the thread's priority is restored for all three cases inside linux_synchronize_rcu_cb() in the LinuxKPI.
Sponsored by: Mellanox Technologies
MFC r319316: Fixes for refcounting "struct linux_file" in the LinuxKPI.
- Allow "struct linux_file" to be refcounted when its "_file" member is NULL by using its "f_count" field. The reference counts are transferred to the file structure when the file descriptor is installed.
- Add missing vdrop() calls for error cases during open().
- Set the "_file" member of "struct linux_file" during open. This allows use of refcounting through get_file() and fput() with LinuxKPI character devices.
Sponsored by: Mellanox Technologies
MFC r319317: Fix a reference count leak in the LinuxKPI due to calling VM open when it shouldn't be called.
Background: The Linux VM open operation is called when a new VMA is created on top of the current VMA. This is done through either mremap flow or split_vma, usually due to mlock, madvise, munmap and so on. This is currently not supported by the LinuxKPI.
Sponsored by: Mellanox Technologies
MFC r319318: Don't acquire a reference on the VM-space when allocating the LinuxKPI task structure to avoid deadlock when tearing down the VM object during a process exit.
Found by: markj @ Sponsored by: Mellanox Technologies
MFC r319319: Remove the VMA handle from its list before calling the LinuxKPI VMA close operation to prevent other threads from reusing the VM object handle pointer.
Sponsored by: Mellanox Technologies
MFC r319320: Make sure the VMAP's "vm_file" field is referenced in a Linux compatible way by the linux_dev_mmap_single() function in the LinuxKPI.
Sponsored by: Mellanox Technologies
MFC r319321: Properly set the .d_name field in the cdevsw structure for the LinuxKPI.
Obtained from: kmacy @ Sponsored by: Mellanox Technologies
MFC r319338: Implement in_atomic() function in the LinuxKPI.
Obtained from: kmacy @ Sponsored by: Mellanox Technologies
MFC r319340: Properly implement idr_preload() and idr_preload_end() in the LinuxKPI.
Sponsored by: Mellanox Technologies
MFC r319341: Implement print_hex_dump(), print_hex_dump_bytes() and printk_ratelimited() in the LinuxKPI.
While at it fix the inclusion guard of printk.h to be similar to the rest of the LinuxKPI header files.
Sponsored by: Mellanox Technologies
MFC r319409: Add generic kqueue() and kevent() support to the LinuxKPI character devices. The implementation allows read and write filters to be created and piggybacks on the poll() file operation to determine when a filter should trigger. The piggyback mechanism is simply to check for the EWOULDBLOCK or EAGAIN return code from read(), write() or ioctl() system calls and then update the kqueue() polling state bits. The implementation is similar to the one found in the cuse(3) module. Refer to sys/fs/cuse/*.[ch] for more details.
Sponsored by: Mellanox Technologies
MFC r319410: Translate the ERESTARTSYS error code into ERESTART in the LinuxKPI ioctl(), read() and write() system call handlers. This error code is internal to the kernel and should not be seen by user-space programs according to Linux.
Submitted by: Yanko Yankulov <yanko.yankulov@gmail.com> Sponsored by: Mellanox Technologies
MFC r319444: Make sure the selrecord() function is only called from within system polling contexts in the LinuxKPI.
After the kqueue() support was added to the LinuxKPI in r319409 the Linux poll file operation will be used outside the system file polling callback function, which can cause a NULL-pointer panic inside selrecord() because curthread->td_sel is set to NULL. This patch moves the selrecord() call away from poll_wait() and to the system file poll callback function in the LinuxKPI, which essentially wraps the Linux one. This is similar to what the cuse(3) module is currently doing. Refer to sys/fs/cuse/*.[ch] for more details.
Sponsored by: Mellanox Technologies
MFC r319500: Add support for setting the non-blocking I/O flag for LinuxKPI character devices. In Linux the FIONBIO IOCTL is handled by the kernel and not the drivers. Also need return success for the FIOASYNC ioctl due to existing logic in kern_fcntl() even though it is not supported currently.
Sponsored by: Mellanox Technologies
MFC r319501: Improve kqueue() support in the LinuxKPI. Some applications using the kqueue() does not set non-blocking I/O mode for event driven read of file descriptors. This means the LinuxKPI internal kqueue read and write event flags must be updated before the next read and/or write system call. Else the read and/or write system call may block. This can happen when there is no more data to read following a previous read event. Then the application also gets blocked from processing other events. This situation can also be solved by the applications setting and using non-blocking I/O mode.
Sponsored by: Mellanox Technologies
MFC r319620: Fix init order in the LinuxKPI for IDR support after recent changes.
CPU_FOREACH() is not available until SI_SUB_CPU at SI_ORDER_ANY when the LinuxKPI is loaded as part of the kernel.
Sponsored by: Mellanox Technologies
MFC r319656: Add more #ifdef arch checks to the linuxkpi
arm, mips, and powerpc all implement pmap_mapdev_attr() and pmap_unmapdev(), so add those archs to the checks. powerpc also includes the atomic_swap_*() functions, so add that to the supported list as well. Not tested except by compiling powerpc.
Reviewed by: markj
MFC r319675: Remove ARM and MIPS from linuxkpi ioremap_attr definition
ARM and MIPS fail universe builds.
ARM and MIPS are missing the following: * VM_MEMATTR_WRITE_THROUGH * VM_MEMATTR_WRITE_COMBINING
Pointy-hat to: jhibbits
MFC r319757: Augment wait queue support in the LinuxKPI.
In particular: - Don't evaluate event conditions with a sleepqueue lock held, since such code may attempt to acquire arbitrary locks. - Fix the return value for wait_event_interruptible() in the case that the wait is interrupted by a signal. - Implement wait_on_bit_timeout() and wait_on_atomic_t(). - Implement some functions used to test for pending signals. - Implement a number of wait_event_*() variants and unify the existing implementations. - Unify the mechanism used by wait_event_*() and schedule() to put the calling thread to sleep.
This is required to support updated DRM drivers. Thanks to hselasky for finding and fixing a number of bugs in the original revision.
Reviewed by: hselasky Differential Revision: https://reviews.freebsd.org/D10986
MFC r319758: Implement pci_disable_device() in the LinuxKPI.
Submitted by: kmacy
MFC r320063: Remove prototypes for unimplemented LinuxKPI functions.
MFC r320072: Avoid including list.h in LinuxKPI headers.
list.h includes a number of FreeBSD headers as a workaround for the LIST_HEAD name collision. To reduce pollution, avoid including list.h in commonly used headers when it is not explicitly needed.
Reviewed by: hselasky Differential Revision: https://reviews.freebsd.org/D11249
MFC r320078: Add kthread parking support to the LinuxKPI.
Submitted by: kmacy (original version) Reviewed by: hselasky Differential Revision: https://reviews.freebsd.org/D11264
MFC r320189: Allow the VM fault handler to be NULL in the LinuxKPI when handling a memory map request. When the VM fault handler is NULL a return code of VM_PAGER_BAD is returned from the character device's pager populate handler. This fixes compatibility with Linux.
Sponsored by: Mellanox Technologies
MFC r320192: Add a lockdep macro to the LinuxKPI.
Also fix some nearby style issues.
MFC r320193: Include kmod.h from the LinuxKPI's module.h.
MFC r320194: Add missing lock destructor invocations to the LinuxKPI unload handler.
MFC r320196: Update io-mapping.h in the LinuxKPI.
Add io_mapping_init_wc() and add a third (unused) parameter to io_mapping_map_wc().
Reviewed by: hselasky Differential Revision: https://reviews.freebsd.org/D11286
MFC r320333: Add noop_lseek() to the LinuxKPI.
MFC r320334: Add the thaw_early method to struct dev_pm_ops in the LinuxKPI.
MFC r320335: Add a couple of macros to lockdep.h in the LinuxKPI.
MFC r320336: Add ns_to_ktime() to the LinuxKPI.
MFC r320337: Add u64_to_user_ptr() to the LinuxKPI.
MFC r320364: Implement parts of the hrtimer API in the LinuxKPI.
Reviewed by: hselasky Differential Revision: https://reviews.freebsd.org/D11359
MFC r320580: Let io_mapping_init_wc() fall back to an uncacheable mapping.
This allows usage of the function on architectures that don't support write-combining.
Reported by: bz, emaste X-MFC With: r320196
MFC r320627: Hold the PCI device list lock when removing an element.
MFC r320633: Rename the "driver" field to "bsddriver" to avoid a name collision.
MFC r320634: Add some PCI class definitions.
MFC r320635: Add a field for the class code to struct pci_driver.
Fill out some previously uninitialized fields as well.
MFC r320636: Add some auxiliary types for device driver support.
MFC r320656: Invoke suspend/resume methods from the driver pmops if available.
Obtained from: kmacy (original version)
MFC r320774: Fix a bug in synchronize RCU when the calling thread is bound to a CPU.
Set "td_pinned" to zero after "sched_unbind()" to prevent "td_pinned" from temporarily becoming negative during "sched_bind()". This can happen if "sched_bind()" uses "sched_pin()" and "sched_unpin()".
Sponsored by: Mellanox Technologies
MFC r320775: Complete r320189 which allows a NULL VM fault handler in the LinuxKPI. Instead of mapping a dummy page upon a page fault, map the page pointed to by the physical address given by IDX_TO_OFF(vmap->vm_pfn). To simplify the implementation use OBJT_DEVICE to implement our own linux_cdev_pager_fault() instead of using the existing linux_cdev_pager_populate().
Some minor code factoring while at it.
Reviewed by: markj @ Sponsored by: Mellanox Technologies
MFC r320810: Add TASK_COMM_LEN to the LinuxKPI.
MFC r320811: Add device_is_registered() to the LinuxKPI.
MFC r320812: Fix the definitions of pgprot_{noncached,writecombine} after r316562.
MFC r320813: Add some helper definitions to fs.h in the LinuxKPI.
Add a field to struct linux_file to allow the creation of anonymous shmem objects.
MFC r320852: Free existing per-thread task structs when unloading linuxkpi.ko.
They are otherwise leaked.
Reported and tested by: ae
MFC r320853: Add a few functions to ktime.h in the LinuxKPI, and fix nearby style.
Reviewed by: hselasky Differential Revision: https://reviews.freebsd.org/D11534
MFC r320854: Add some functions to math64.h in the LinuxKPI, and fix nearby style.
Reviewed by: hselasky Differential Revision: https://reviews.freebsd.org/D11535
MFC r320956: Add some functions to jiffies.h.
Also add some checks for overflow to existing functions.
Reviewed by: hselasky Differential Revision: https://reviews.freebsd.org/D11533
MFC r321773: Remove cycle_t type from the LinuxKPI similar to Linux upstream.
Sponsored by: Mellanox Technologies
MFC r321926: Fix LinuxKPI regression after r321920. The mda_unit and si_drv0 fields are not wide enough to hold the full 64-bit dev_t. Instead use the "dev" field in the "linux_cdev" structure to store and lookup this value.
While at it remove superfluous use of parenthesis inside the MAJOR(), MINOR() and MKDEV() macros in the LinuxKPI.
Sponsored by: Mellanox Technologies
MFC r322028: Add subsystem vendor and device ID fields to struct pci_dev.
MFC r322169: Fix hrtimer_active() in case of cancellation.
While there, switch to FreeBSD internal callout active status.
Reviewed by: markj, hselasky Sponsored by: iXsystems, Inc. Differential Revision: https://reviews.freebsd.org/D11900
MFC r322212: Add macros for defining attribute groups and for WO and RW attributes.
Reviewed by: hselasky Differential Revision: https://reviews.freebsd.org/D11872
MFC r322213: Add round_jiffies_up(), local_clock() and __setup_timer() to the LinuxKPI.
Reviewed by: hselasky Differential Revision: https://reviews.freebsd.org/D11871
MFC r322272: Fix few issues of LinuxKPI workqueue.
LinuxKPI workqueue wrappers reported "successful" cancellation for works already completed in normal way. This change brings reported status and real cancellation fact into sync. This required for drm-next operation.
Reviewed by: hselasky (earlier version) Sponsored by: iXsystems, Inc. Differential Revision: https://reviews.freebsd.org/D11904
MFC r322354: Make sure the linux_wait_event_common() function in the LinuxKPI properly handles a timeout value of MAX_SCHEDULE_TIMEOUT which basically means there is no timeout. This is a regression issue after r319757.
While at it change the type of returned variable from "long" to "int" to match the actual return type.
Sponsored by: Mellanox Technologies
MFC r322355: Fixes for wait event in the LinuxKPI. These are regression issues after r319757.
1) Correct the return value from __wait_event_common() from 1 to 0 in case the timeout is specified as MAX_SCHEDULE_TIMEOUT. In the other case __ret is zero and will be substituted in the last part of the macro with the appropriate value before return.
2) Make sure the "timeout" argument is casted to "int" before evaluating negativity. Else the signedness of a "long" might be checked instead of the signedness of an integer.
3) The wait_event() function should not have a return value.
Found by: KrishnamRaju ErapaRaju <Krishna2@chelsio.com> Sponsored by: Mellanox Technologies
MFC r322357: Use integer type to pass around jiffies and/or ticks values in the LinuxKPI because in FreeBSD ticks are 32-bit.
Sponsored by: Mellanox Technologies
MFC r322392: Add a specialized function for DRM drivers to register themselves.
Such drivers attach to a vgapci bus rather than directly to a pci bus. For the rest of the LinuxKPI to work correctly in this case, we override the vgapci bus' ivars with those of the grandparent.
Reviewed by: hselasky Differential Revision: https://reviews.freebsd.org/D11932
MFC r322397: Make sure the "vm_flags" and "vm_page_prot" fields get set correctly in the VM area structure in the LinuxKPI when doing mmap() and that unsupported bits are masked away.
While at it fix some redundant use of parenthesing inside some related macros.
Found by: KrishnamRaju ErapaRaju <Krishna2@chelsio.com> Sponsored by: Mellanox Technologies
MFC r322567: Add device resource management fields to struct device.
MFC r322713: Add a couple of trivial headers to the LinuxKPI.
MFC r322714: Define prefetch() only if it hasn't already been defined.
MFC r322746: Fix for deadlock situation in the LinuxKPI's RCU synchronize API.
Deadlock condition: The return value of TDQ_LOCKPTR(td) is the same for two threads.
1) The first thread signals a wakeup while keeping the rcu_read_lock(). This invokes sched_add() which in turn will try to lock TDQ_LOCK().
2) The second thread is calling synchronize_rcu() calling mi_switch() over and over again trying to yield(). This prevents the first thread from running and releasing the RCU reader lock.
Solution: Release the thread lock while yielding to allow other threads to acquire the lock pointed to by TDQ_LOCKPTR(td).
Found by: KrishnamRaju ErapaRaju <Krishna2@chelsio.com> Sponsored by: Mellanox Technologies
MFC r322795: Add some miscellaneous definitions to support the DRM drivers.
MFC r322816: Set the bus number field when attaching a PCI device.
MFC r323347: Add more sanity checks to linux_fget() in the LinuxKPI. This prevents returning pointers to file descriptors which were not created by the LinuxKPI.
Sponsored by: Mellanox Technologies
MFC r323349: Properly implement poll_wait() in the LinuxKPI. This prevents direct use of the linux_poll_wakeup() function from unsafe contexts, which can lead to use-after-free issues.
Instead of calling linux_poll_wakeup() directly use the wake_up() family of functions in the LinuxKPI to do this.
Bump the FreeBSD version to force recompilation of external kernel modules.
Sponsored by: Mellanox Technologies
MFC r323703: Add support for shared memory functions to the LinuxKPI.
Obtained from: kmacy @ Sponsored by: Mellanox Technologies
MFC r323704: Only wire pages in the LinuxKPI instead of holding and wiring them. This prevents the page daemon from regularly scanning the held pages.
Suggested by: kib @ Sponsored by: Mellanox Technologies
MFC r323705: The LinuxKPI atomics do not have acquire nor release semantics unless specified. Fix code to use READ_ONCE() and WRITE_ONCE() where appropriate.
Suggested by: kib @ Sponsored by: Mellanox Technologies
MFC r323910: Add support for 32-bit compatibility IOCTLs in the LinuxKPI.
Bump the FreeBSD version to force recompilation of external kernel modules due to structure change.
PR: 222504 Submitted by: Greg V <greg@unrelenting.technology> Sponsored by: Mellanox Technologies
MFC r324278: Make sure the timer belonging to the delayed work in the LinuxKPI gets drained before invoking the work function. Else the timer mutex may still be in use which can lead to use-after-free situations, because the work function might free the work structure before returning.
Sponsored by: Mellanox Technologies
MFC r324285: Add get_random_{int,long} to the LinuxKPI.
Fix some whitespace bugs while here.
Reviewed by: hselasky Differential Revision: https://reviews.freebsd.org/D12588
MFC r324597: Don't call selrecord() outside the select system call in the LinuxKPI, because then td->td_sel is NULL and this will result in a segfault inside selrecord(). This happens when only using kqueue() to poll for read and write events. If select() and kqueue() is mixed there won't be a segfault.
Reported by: Johannes Lundberg Sponsored by: Mellanox Technologies
MFC r324606: Make the PHOLD in linux_wait_event_common() unconditional.
After some in-progress work is committed, this would otherwise be the only instance of #if(n)def NO_SWAPPING in the tree. Moreover, the requisite opt_vm.h include was missing, so the PHOLD/PRELE calls were always being compiled in anyway.
MFC r325279: Implement ioread16be() in the LinuxKPI.
Sponsored by: Mellanox Technologies
MFC r325360: Remove redundant dev->si_drv1 NULL checks in the LinuxKPI. This pointer is checked during the linux_dev_open() callback and does not need to be NULL checked again. It should always be set for character devices belonging to the "linuxcdevsw" and technically there is no need to NULL check this pointer at all.
Suggested by: kib @ Sponsored by: Mellanox Technologies
MFC r325635: Remove some not needed comments in the LinuxKPI. Use the Linux source tree to lookup documentation for the functions implemented in the LinuxKPI instead.
Sponsored by: Mellanox Technologies
MFC r325707: Mask away return codes from del_timer() and del_timer_sync() because they are not the same like in Linux.
Sponsored by: Mellanox Technologies
MFC r325708: Remove release and acquire semantics when accessing the "state" field of the LinuxKPI task struct. Change type of "state" variable from "int" to "atomic_t" to simplify code and avoid unneccessary casting.
Sponsored by: Mellanox Technologies
MFC r325767: Properly handle the case where the linux_cdev_handle_insert() function in the LinuxKPI returns NULL. This happens when the VM area's private data handle already exists and could cause a so-called NULL pointer dereferencing issue prior to this fix.
Found by: greg@unrelenting.technology Sponsored by: Mellanox Technologies
MFC r327676: linuxkpi: Implement kcalloc() based on mallocarray()
This means we now get integer overflow protection, which Linux code might expect as it is also provided by kcalloc() in Linux.
MFC r327788: linuxkpi: Simplify kmalloc_array.
kmalloc_array seems what we call mallocarray(9).
MFC r312926: (partial, no mergeinfo) Revert r312923 a better approach will be taken later
MFC r312927: (partial, no mergeinfo) Revert crap accidentally committed
MFC r316665: (partial, no mergeinfo) Import CK as of commit 6b141c0bdd21ce8b3e14147af8f87f22b20ecf32 This brings us changes we needed in ck_epoch.
MFC r317053: (partial, no mergeinfo) Remove unneeded include of vm_phys.h.
MFC r317055: (partial, no mergeinfo) All these files need sys/vmmeter.h, but now they got it implicitly included via sys/pcpu.h.
MFC r322168: (partial, no mergeinfo) o Replace __riscv__ with __riscv o Replace __riscv64 with (__riscv && __riscv_xlen == 64)
This is required to support new GCC 7.1 compiler. This is compatible with current GCC 6.1 compiler.
RISC-V is extensible ISA and the idea here is to have built-in define per each extension, so together with __riscv we will have some subset of these as well (depending on -march string passed to compiler):
__riscv_compressed __riscv_atomic __riscv_mul __riscv_div __riscv_muldiv __riscv_fdiv __riscv_fsqrt __riscv_float_abi_soft __riscv_float_abi_single __riscv_float_abi_double __riscv_cmodel_medlow __riscv_cmodel_medany __riscv_cmodel_pic __riscv_xlen
Reviewed by: ngie Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D11901
MFC r322672: (partial, no mergeinfo) Move some other SI_SUB_INIT_IF initializations to SI_SUB_TASKQ
Drop the EARLY_AP_STARTUP gtaskqueue code, as gtaskqueues are now initialized before APs are started.
Reviewed by: hselasky@, jhb@ Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D12054
MFC r326984: (partial, no mergeinfo) Update Matthew Macy contact info
Email address has changed, uses consistent name (Matthew, not Matt)
Reported by: Matthew Macy <mmacy@mattmacy.io> Differential Revision: https://reviews.freebsd.org/D13537
|
#
328386 |
|
25-Jan-2018 |
pkelsey |
MFC r316648:
Corrected misspelled versions of rendezvous.
The MFC maintains smp_no_rendevous_barrier() as a symbol alias of smp_no_rendezvous_barrier().
__FreeBSD_version bumped to indicate presence of the new name smp_no_rendezvous_barrier().
Reviewed by: gnn, jhb (email), kib Differential Revision: https://reviews.freebsd.org/D10313
|
#
328379 |
|
24-Jan-2018 |
jhb |
MFC 325028,328344: Discard the correct thread event reported for a ptrace stop.
325028: Discard the correct thread event reported for a ptrace stop.
When multiple threads wish to report a tracing event to a debugger, both threads call ptracestop() and one thread will win the race to be the reporting thread (p->p_xthread). The debugger uses PT_LWPINFO with the process ID to determine which thread / LWP is reporting an event and the details of that event. This event is cleared as a side effect of the subsequent ptrace event that resumed the process (PT_CONTINUE, PT_STEP, etc.). However, ptrace() was clearing the event identified by the LWP ID passed to the resume request even if that wasn't the 'p_xthread'. This could result in clearing an event that had not yet been observed by the debugger and leaving the existing event for 'p_thread' pending so that it was reported a second time.
Specifically, if the debugger stopped due to a software breakpoint in one thread, but then switched to another thread that was used to resume (e.g. if the user switched to a different thread and issued a step), the resume request (PT_STEP) cleared a pending event (if any) for the thread being stepped. However, the process immediately stopped and the first thread reported it's breakpoint event a second time. The debugger decremented the PC for "both" breakpoint events which resulted in the PC now pointing into the middle of an instruction (on x86) and a SIGILL fault when the process was resumed a second time.
To fix, always clear the pending event for 'p_xthread' when resuming a process. ptrace() still honors the requested LWP ID when enabling single-stepping (PT_STEP) or setting a different PC (PT_CONTINUE).
328344: Mark the unused argument to continue_thread() as such.
clang in HEAD and 11 does not warn about this, but clang in 10 does.
|
#
325003 |
|
25-Oct-2017 |
asomers |
MFC r324281:
Display rotation rate and TRIM/UNMAP support in diskinfo(8)
Bump __FreeBSD_version due to the expansion of struct diocgattr_arg.
Reviewed by: mav, allanjude, imp Relnotes: yes Sponsored by: Spectra Logic Corp Differential Revision: https://reviews.freebsd.org/D12578
|
#
324023 |
|
26-Sep-2017 |
dim |
Merge clang, llvm, lld, lldb, compiler-rt and libc++ 5.0.0 release.
MFC r309126 (by emaste):
Correct lld llvm-tblgen dependency file name
MFC r309169:
Get rid of separate Subversion mergeinfo properties for llvm-dwarfdump and llvm-lto. The mergeinfo confuses Subversion enormously, and these directories will just use the mergeinfo for llvm itself.
MFC r312765:
Pull in r276136 from upstream llvm trunk (by Wei Mi):
Use ValueOffsetPair to enhance value reuse during SCEV expansion.
In D12090, the ExprValueMap was added to reuse existing value during SCEV expansion. However, const folding and sext/zext distribution can make the reuse still difficult.
A simplified case is: suppose we know S1 expands to V1 in ExprValueMap, and S1 = S2 + C_a S3 = S2 + C_b where C_a and C_b are different SCEVConstants. Then we'd like to expand S3 as V1 - C_a + C_b instead of expanding S2 literally. It is helpful when S2 is a complex SCEV expr and S2 has no entry in ExprValueMap, which is usually caused by the fact that S3 is generated from S1 after const folding.
In order to do that, we represent ExprValueMap as a mapping from SCEV to ValueOffsetPair. We will save both S1->{V1, 0} and S2->{V1, C_a} into the ExprValueMap when we create SCEV for V1. When S3 is expanded, it will first expand S2 to V1 - C_a because of S2->{V1, C_a} in the map, then expand S3 to V1 - C_a + C_b.
Differential Revision: https://reviews.llvm.org/D21313
This should fix assertion failures when building OpenCV >= 3.1.
PR: 215649
MFC r312831:
Revert r312765 for now, since it causes assertions when building lang/spidermonkey24.
Reported by: antoine PR: 215649
MFC r316511 (by jhb):
Add an implementation of __ffssi2() derived from __ffsdi2().
Newer versions of GCC include an __ffssi2() symbol in libgcc and the compiler can emit calls to it in generated code. This is true for at least GCC 6.2 when compiling world for mips and mips64.
Reviewed by: jmallett, dim Sponsored by: DARPA / AFRL Differential Revision: https://reviews.freebsd.org/D10086
MFC r318601 (by adrian):
[libcompiler-rt] add bswapdi2/bswapsi2
This is required for mips gcc 6.3 userland to build/run.
Reviewed by: emaste, dim Approved by: emaste Differential Revision: https://reviews.freebsd.org/D10838
MFC r318884 (by emaste):
lldb: map TRAP_CAP to a trace trap
In the absense of a more specific handler for TRAP_CAP (generated by ENOTCAPABLE or ECAPMODE while in capability mode) treat it as a trace trap.
Example usage (testing the bug in PR219173):
% proccontrol -m trapcap lldb usr.bin/hexdump/obj/hexdump -- -Cv -s 1 /bin/ls ... (lldb) run Process 12980 launching Process 12980 launched: '.../usr.bin/hexdump/obj/hexdump' (x86_64) Process 12980 stopped * thread #1, stop reason = trace frame #0: 0x0000004b80c65f1a libc.so.7`__sys_lseek + 10 ...
In the future we should have LLDB control the trapcap procctl itself (as it does with ASLR), as well as report a specific stop reason. This change eliminates an assertion failure from LLDB for now.
MFC r319796:
Remove a few unneeded files from libllvm, libclang and liblldb.
MFC r319885 (by emaste):
lld: ELF: Fix ICF crash on absolute symbol relocations.
If two sections contained relocations to absolute symbols with the same value we would crash when trying to access their sections. Add a check that both symbols point to sections before accessing their sections, and treat absolute symbols as equal if their values are equal.
Obtained from: LLD commit r292578
MFC r319918:
Revert r319796 for now, it can cause undefined references when linking in some circumstances.
Reported by: Shawn Webb <shawn.webb@hardenedbsd.org>
MFC r319957 (by emaste):
lld: Add armelf emulation mode
Obtained from: LLD r305375
MFC r321369:
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 5.0.0 (trunk r308421). Upstream has branched for the 5.0.0 release, which should be in about a month. Please report bugs and regressions, so we can get them into the release.
Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11 support to build; see UPDATING for more information.
MFC r321420:
Add a few more object files to liblldb, which should solve errors when linking the lldb executable in some cases. In particular, when the -ffunction-sections -fdata-sections options are turned off, or ineffective.
Reported by: Shawn Webb, Mark Millard
MFC r321433:
Cleanup stale Options.inc files from the previous libllvm build for clang 4.0.0. Otherwise, these can get included before the two newly generated ones (which are different) for clang 5.0.0.
Reported by: Mark Millard
MFC r321439 (by bdrewery):
Move llvm Options.inc hack from r321433 for NO_CLEAN to lib/clang/libllvm.
The files are only ever generated to .OBJDIR, not to WORLDTMP (as a sysroot) and are only ever included from a compilation. So using a beforebuild target here removes the file before the compilation tries to include it.
MFC r321664:
Pull in r308891 from upstream llvm trunk (by Benjamin Kramer):
[CodeGenPrepare] Cut off FindAllMemoryUses if there are too many uses.
This avoids excessive compile time. The case I'm looking at is Function.cpp from an old version of LLVM that still had the giant memcmp string matcher in it. Before r308322 this compiled in about 2 minutes, after it, clang takes infinite* time to compile it. With this patch we're at 5 min, which is still bad but this is a pathological case.
The cut off at 20 uses was chosen by looking at other cut-offs in LLVM for user scanning. It's probably too high, but does the job and is very unlikely to regress anything.
Fixes PR33900.
* I'm impatient and aborted after 15 minutes, on the bug report it was killed after 2h.
Pull in r308986 from upstream llvm trunk (by Simon Pilgrim):
[X86][CGP] Reduce memcmp() expansion to 2 load pairs (PR33914)
D35067/rL308322 attempted to support up to 4 load pairs for memcmp inlining which resulted in regressions for some optimized libc memcmp implementations (PR33914).
Until we can match these more optimal cases, this patch reduces the memcmp expansion to a maximum of 2 load pairs (which matches what we do for -Os).
This patch should be considered for the 5.0.0 release branch as well
Differential Revision: https://reviews.llvm.org/D35830
These fix a hang (or extremely long compile time) when building older LLVM ports.
Reported by: antoine PR: 219139
MFC r321719:
Pull in r309503 from upstream clang trunk (by Richard Smith):
PR33902: Invalidate line number cache when adding more text to existing buffer.
This led to crashes as the line number cache would report a bogus line number for a line of code, and we'd try to find a nonexistent column within the line when printing diagnostics.
This fixes an assertion when building the graphics/champlain port.
Reported by: antoine, kwm PR: 219139
MFC r321723:
Upgrade our copies of clang, llvm, lld and lldb to r309439 from the upstream release_50 branch. This is just after upstream's 5.0.0-rc1.
MFC r322320:
Upgrade our copies of clang, llvm and libc++ to r310316 from the upstream release_50 branch.
MFC r322326 (by emaste):
lldb: Make i386-*-freebsd expression work on JIT path
* Enable i386 ABI creation for freebsd * Added an extra argument in ABISysV_i386::PrepareTrivialCall for mmap syscall * Unlike linux, the last argument of mmap is actually 64-bit(off_t). This requires us to push an additional word for the higher order bits. * Prior to this change, ktrace dump will show mmap failures due to invalid argument coming from the 6th mmap argument.
Submitted by: Karnajit Wangkhem Differential Revision: https://reviews.llvm.org/D34776
MFC r322360 (by emaste):
lldb: Report inferior signals as signals, not exceptions, on FreeBSD
This is the FreeBSD equivalent of LLVM r238549.
This serves 2 purposes:
* LLDB should handle inferior process signals SIGSEGV/SIGILL/SIGBUS/ SIGFPE the way it is suppose to be handled. Prior to this fix these signals will neither create a coredump, nor exit from the debugger or work for signal handling scenario. * eInvalidCrashReason need not report "unknown crash reason" if we have a valid si_signo
llvm.org/pr23699
Patch by Karnajit Wangkhem
Differential Revision: https://reviews.llvm.org/D35223
Submitted by: Karnajit Wangkhem Obtained from: LLVM r310591
MFC r322474 (by emaste):
lld: Add `-z muldefs` option.
Obtained from: LLVM r310757
MFC r322740:
Upgrade our copies of clang, llvm, lld and libc++ to r311219 from the upstream release_50 branch.
MFC r322855:
Upgrade our copies of clang, llvm, lldb and compiler-rt to r311606 from the upstream release_50 branch.
As of this version, lib/msun's trig test should also work correctly again (see bug 220989 for more information).
PR: 220989
MFC r323112:
Upgrade our copies of clang, llvm, lldb and compiler-rt to r312293 from the upstream release_50 branch. This corresponds to 5.0.0 rc4.
As of this version, the cad/stepcode port should now compile in a more reasonable time on i386 (see bug 221836 for more information).
PR: 221836
MFC r323245:
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 5.0.0 release (upstream r312559).
Release notes for llvm, clang and lld will be available here soon: <http://releases.llvm.org/5.0.0/docs/ReleaseNotes.html> <http://releases.llvm.org/5.0.0/tools/clang/docs/ReleaseNotes.html> <http://releases.llvm.org/5.0.0/tools/lld/docs/ReleaseNotes.html>
Relnotes: yes
|
#
324006 |
|
26-Sep-2017 |
dim |
Synchronize most of libm with head as of r323004. This excludes a few arch-specific updates for powerpcspe, mips and riscv, for which support has not been merged yet.
Bump __FreeBSD_version for the addition of cacoshl, cacosl, casinhl, casinl, catanl, catanhl, sincos, sincosf, and sincosl.
MFC r305382 (by bde):
Add asm versions of fmod(), fmodf() and fmodl() on amd64. Add asm versions of fmodf() amd fmodl() on i387.
fmod is similar to remainder, and the C versions are 3 to 9 times slower than the asm versions on x86 for both, but we had the strange mixture of all 6 variants of remainder in asm and only 1 of 6 variants of fmod in asm.
MFC r305384 (by bde):
Disconnect the "optimized" asm variants of cos(), sin() and tan() from the build on i386. Leave them in the source tree for regression tests.
The asm functions were always much less accurate (by a factor of more than 10**18 in the worst case). They were faster on old CPUs. But with each new generation of CPUs they get relatively slower. The double precision C version's average advantage is about a factor of 2 on Haswell.
The asm functions were already intentionally avoided in float and long double precision on i386 and in all precisions on amd64. Float precision and amd64 give larger advantages to the C version. The long double precision C code and compilers' understanding of long double precision are not so good, so the i387 is still slightly faster for long double precision, except for the unimportant subcase of huge args where the sub-optimal C code now somehow beats the i387 by about a factor of 2.
MFC r305385 (by bde):
Oops, the previous i386 version of e_fmodf.S and e_fmodl.S was actually the amd64 version.
MFC r306409 (by emaste):
libm: fix some unused variable (rcsid) and dangling else warnings
s_{fabs,fmax,logb,scalb}{,f,l}.c may be built elsewhere with a higher WARNS setting.
Reviewed by: ed Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D8061
MFC r306410 (by emaste):
libm: simplify i387 subdir logic with make's :S substitution
MFC r306527 (by emaste):
libm: remove unused variables for LDBL_MANT_DIG != 113
Sponsored by: The FreeBSD Foundation
MFC r306709 (by emaste):
libm: remove unused variables
Sponsored by: The FreeBSD Foundation
MFC r307066 (by br):
Don't use fmaxl/fminl on platforms with no long double support, use fmax/fmin instead.
This fixes fmaxmin test failure on MIPS64.
Reviewed by: emaste Sponsored by: DARPA, AFRL Sponsored by: HEIF5 Differential Revision: https://reviews.freebsd.org/D8216
MFC r308172 (by emaste):
libm: add braces around initialization of subobjects
This cleans up a warning when building libm at higher WARNS levels and makes the intent more clear. By the C standard the values are assigned to subobject members in order so this change introduces no functional change. (6.7.9 20)
Reviewed by: kib Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D8333
MFC r313761 (by mmokhi):
Add casinl() cacosl() catanl() casinhl() cacoshl() catanhl() APIs to msun to improve C11 conformance.
PR: 216850 216851 216852 216856 216857 216858 Submitted by: mmokhi Reported by: sgk@troutmask.apl.washington.edu Reviewed by: bde, mat, theraven Approved by: bde (src committer), mat (mentor) Differential Revision: https://reviews.freebsd.org/D9491
MFC r313863 (by mmokhi):
Fix building of r313761 on platforms that `long double` is alias of `double` (MIPS, etc)
PR: 216850 216851 216852 216856 216857 216858 Reported by: emsate Reviewed by: bde emaste hselasky Approved by: bde emaste hselasky Differential Revision: https://reviews.freebsd.org/D9491
MFC r313864 (by mmokhi):
Add documentations related to new APIs of r313761
PR: 216850 216851 216852 216856 216857 216858 Submitted by: sgk@troutmask.apl.washington.edu Reported by: sgk@troutmask.apl.washington.edu Reviewed by: bde emaste hselasky Approved by: bde emaste hselasky Differential Revision: https://reviews.freebsd.org/D9491
MFC r314950 (by ngie):
Don't expect :test_large_inputs to fail with i386 anymore
Recent changes (maybe a side-effect of the ATF-ification in r314649) invalidate the failure expectation.
PR: 205446 Sponsored by: Dell EMC Isilon
MFC r317349 (by pfg):
msun: Remove trailing space in Sunsoft copyright statement.
Submittedby: kargl
MFC r319047 (by mmel):
Implement sincos, sincosf, and sincosl. The primary benefit of these functions is that argument reduction is done once instead of twice in independent calls to sin() and cos().
* lib/msun/Makefile: . Add s_sincos[fl].c to the build. . Add sincos.3 documentation. . Add appropriate MLINKS.
* lib/msun/Symbol.map: . Expose sincos[fl] symbols in dynamic libm.so.
* lib/msun/man/sincos.3: . Documentation for sincos[fl].
* lib/msun/src/k_sincos.h: . Kernel for sincos() function. This merges the individual kernels for sin() and cos(). The merger offered an opportunity to re-arrange the individual kernels for better performance.
* lib/msun/src/k_sincosf.h: . Kernel for sincosf() function. This merges the individual kernels for sinf() and cosf(). The merger offered an opportunity to re-arrange the individual kernels for better performance.
* lib/msun/src/k_sincosl.h: . Kernel for sincosl() function. This merges the individual kernels for sinl() and cosl(). The merger offered an opportunity to re-arrange the individual kernels for better performance.
* lib/msun/src/math.h: . Add prototytpes for sincos[fl]().
* lib/msun/src/math_private.h: . Add RETURNV macros. This is needed to reset fpsetprec on I386 hardware for a function with type void.
* lib/msun/src/s_sincos.c: . Implementation of sincos() where sin() and cos() were merged into one routine and possibly re-arranged for better performance.
* lib/msun/src/s_sincosf.c: . Implementation of sincosf() where sinf() and cosf() were merged into one routine and possibly re-arranged for better performance.
* lib/msun/src/s_sincosl.c: . Implementation of sincosl() where sinl() and cosl() were merged into one routine and possibly re-arranged for better performance.
PR: 215977, 218300 Submitted by: Steven G. Kargl <sgk@troutmask.apl.washington.edu> Differential Revision: https://reviews.freebsd.org/D10765
MFC r321457 (by ngie):
Mark :reduction as an expected failure
It fails with clang 5.0+.
PR: 220989 Reported by: Jenkins
MFC r322418 (by rlibby):
lib/msun: avoid referring to broken LDBL_MAX
LDBL_MAX is broken on i386: https://lists.freebsd.org/pipermail/freebsd-numerics/2012-September/000288.html
Gcc has produced +Infinity for LDBL_MAX on i386 and amd64 with -m32 for some time, and newer versions of gcc are now warning that the "floating constant exceeds range of 'long double'". Avoid this by referring to half the value of LDBL_MAX instead.
Reviewed by: bde Approved by: markj (mentor) Sponsored by: Dell EMC Isilon
MFC r322435 (by rlibby):
Revert r322418, LDBL_MAX_EXP unsuitable for macro pasting on some arches
Either need a different way to spell HALF_LDBL_MAX, or a different way to spell LDBL_MAX_EXP, or a different approach.
Reported by: ian
MFC r322921 (by ngie):
Revert r321457
It doesn't fail after ^/head@r322855 (the releng_50 clang merge).
PR: 220989
|
#
323431 |
|
11-Sep-2017 |
kib |
MFC r322762, r322799, r322832, r322833: Make WRFSBASE and WRGSBASE instructions functional.
Bump stable/11 __FreeBSD_version.
|
#
322909 |
|
25-Aug-2017 |
rmacklem |
MFC: r321688 Add kernel support for the NFS client forced dismount "umount -N" option.
When an NFS mount is hung against an unresponsive NFS server, the "umount -f" option can be used to dismount the mount. Unfortunately, "umount -f" gets hung as well if a "umount" without "-f" has already been done. Usually, this is because of a vnode lock being held by the "umount" for the mounted-on vnode. This patch adds kernel code so that a new "-N" option can be added to "umount", allowing it to avoid getting hung for this case. It adds two flags. One indicates that a forced dismount is about to happen and the other is used, along with setting mnt_data == NULL, to handshake with the nfs_unmount() VFS call. It includes a slight change to the interface used between the client and common NFS modules, so I bumped __FreeBSD_version to ensure both modules are rebuilt.
|
#
320666 |
|
05-Jul-2017 |
kib |
Add MAP_GUARD and use it for stack grow area protection. Bump __FreeBSD_version.
MFC r320317: Implement address space guards.
MFC r320338: Remove stale part of the comment.
MFC r320339: Correctly handle small MAP_STACK requests.
MFC r320344: For now, allow mprotect(2) over the guards to succeed regardless of the requested protection.
MFC r320430: Treat the addr argument for mmap(2) request without MAP_FIXED flag as a hint.
MFC r320560 (by alc): Modify vm_map_growstack() to protect itself from the possibility of the gap entry in the vm map being smaller than the sysctl-derived stack guard size.
|
#
320615 |
|
03-Jul-2017 |
rmacklem |
MFC: r319882, r320062, r320070, r320126 Make MAXBCACHEBUF a tunable called vfs.maxbcachebuf.
By making MAXBCACHEBUF a tunable, it can be increased to allow for larger read/write data sizes for the NFS client. The tunable is limited to MAXPHYS, which is currently 128K. Making MAXPHYS a tunable or increasing its value is being discussed, since it would be nice to support a read/write data size of 1Mbyte for the NFS client when mounting the AmazonEFS file service.
Also, define NFS_MAXXDR as the upper bound on XDR overhead in an NFS RPC.
|
#
320596 |
|
03-Jul-2017 |
gjb |
MFC r320488: Correct the branch naming convention in param.h. While here, consistently use upper-case 'X' to represent the version number.
Sponsored by: The FreeBSD Foundation
|
#
320487 |
|
30-Jun-2017 |
gjb |
- Update stable/11 to 11.1-PRERELEASE for the duration of the 11.1-RELEASE cycle. - Reset __FreeBSD_version for 11.1-STABLE.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
|
#
319279 |
|
31-May-2017 |
delphij |
MFC r313695, r313760, r314769, r314863, r314865, r316125
r313695: MFV r313676: libpcap 1.8.1
r313760: MFV r313759: license change for a few headers (4 clause BSD to 3 clause BSD).
X-MFC-with: r313695
r314769: Remove compatibility with old libpcap.
Differential Revision: https://reviews.freebsd.org/D9606
r314863: Stop installing pcap-int.h, which is the internal interface for libpcap.
Reference: https://github.com/the-tcpdump-group/libpcap/issues/560 PR: 217221
r314865: Bump __FreeBSD_version for removal of pcap-int.h.
PR: 217221
r316125: MFV r316124: Fix build when WITHOUT_INET6.
Reported by: Randy Westlund <rwestlun gmail com>
|
#
318197 |
|
11-May-2017 |
marius |
MFC: r312939, r313250, r314811 (partial), r314887 (partial), r315760, r315845, 315430, r317981, r315466
o Fix some overly long lines, whitespace and other bugs according to style(9) as well as spelling etc. in mmc(4), mmcsd(4) and sdhci(4).
o In the mmc(4) bridges and sdhci(4) (bus) front-ends: - Remove redundant assignments of the default bus_generic_print_child device method, - use DEVMETHOD_END, - use NULL instead of 0 for pointers.
o Trim/adjust includes.
o Add and use a MMC_DECLARE_BRIDGE macro for declaring mmc(4) bridges as kernel drivers and their dependency onto mmc(4).
o Add support for eMMC "partitions". Besides the user data area, i. e. the default partition, eMMC v4.41 and later devices can additionally provide up to: 1 enhanced user data area partition 2 boot partitions 1 RPMB (Replay Protected Memory Block) partition 4 general purpose partitions (optionally with a enhanced or extended attribute)
Besides simply subdividing eMMC devices, some Intel NUCs having UEFI code in the boot partitions etc., another use case for the partition support is the activation of pseudo-SLC mode, which manufacturers of eMMC chips typically associate with the enhanced user data area and/ or the enhanced attribute of general purpose partitions.
CAVEAT EMPTOR: Partitioning eMMC devices is a one-time operation.
o Now that properly issuing CMD6 is crucial (so data isn't written to the wrong partition for example), make a step into the direction of correctly handling the timeout for these commands in the MMC layer. Also, do a SEND_STATUS when CMD6 is invoked with an R1B response as recommended by relevant specifications.
o Add an IOCTL interface to mmcsd(4); this is sufficiently compatible with Linux so that the GNU mmc-utils can be ported to and used with FreeBSD (note that due to the remaining deficiencies outlined above SANITIZE operations issued by/with `mmc` currently most likely will fail). These latter have been added to ports as sysutils/mmc-utils. Among others, the `mmc` tool of mmc-utils allows for partitioning eMMC devices (tested working).
o For devices following the eMMC specification v4.41 or later, year 0 is 2013 rather than 1997; so correct this for assembling the device ID string properly.
o Let mmcsd.ko depend on mmc.ko. Additionally, bump MMC_VERSION as at least for some of the above a matching pair is required.
o In the ACPI front-end of sdhci(4) describe the Intel eMMC and SDXC controllers as such in order to match the PCI one. Additionally, in the entry for the 80860F14 SDXC controller remove the eMMC-only SDHCI_QUIRK_INTEL_POWER_UP_RESET.
|
#
316498 |
|
04-Apr-2017 |
mav |
MFC r315673, r315674: Make CAM SIM lock optional.
For three years now CAM does not use SIM lock, but still enforces SIM to use it. Remove this requirement, allowing SIMs to have any locking they prefer, if they pass no mutex to cam_sim_alloc().
|
#
316423 |
|
02-Apr-2017 |
dim |
Update clang, llvm, lld, lldb, compiler-rt and libc++ to 4.0.0 release:
MFC r309142 (by emaste):
Add WITH_LLD_AS_LD build knob
If set it installs LLD as /usr/bin/ld. LLD (as of version 3.9) is not capable of linking the world and kernel, but can self-host and link many substantial applications. GNU ld continues to be used for the world and kernel build, regardless of how this knob is set.
It is on by default for arm64, and off for all other CPU architectures.
Sponsored by: The FreeBSD Foundation
MFC r310840:
Reapply 310775, now it also builds correctly if lldb is disabled:
Move llvm-objdump from CLANG_EXTRAS to installed by default
We currently install three tools from binutils 2.17.50: as, ld, and objdump. Work is underway to migrate to a permissively-licensed tool-chain, with one goal being the retirement of binutils 2.17.50.
LLVM's llvm-objdump is intended to be compatible with GNU objdump although it is currently missing some options and may have formatting differences. Enable it by default for testing and further investigation. It may later be changed to install as /usr/bin/objdump, it becomes a fully viable replacement.
Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D8879
MFC r312855 (by emaste):
Rename LLD_AS_LD to LLD_IS_LD, for consistency with CLANG_IS_CC
Reported by: Dan McGregor <dan.mcgregor usask.ca>
MFC r313559 | glebius | 2017-02-10 18:34:48 +0100 (Fri, 10 Feb 2017) | 5 lines
Don't check struct rtentry on FreeBSD, it is an internal kernel structure. On other systems it may be API structure for SIOCADDRT/SIOCDELRT.
Reviewed by: emaste, dim
MFC r314152 (by jkim):
Remove an assembler flag, which is redundant since r309124. The upstream took care of it by introducing a macro NO_EXEC_STACK_DIRECTIVE.
http://llvm.org/viewvc/llvm-project?rev=273500&view=rev
Reviewed by: dim
MFC r314564:
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 4.0.0 (branches/release_40 296509). The release will follow soon.
Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11 support to build; see UPDATING for more information.
Also note that as of 4.0.0, lld should be able to link the base system on amd64 and aarch64. See the WITH_LLD_IS_LLD setting in src.conf(5). Though please be aware that this is work in progress.
Release notes for llvm, clang and lld will be available here: <http://releases.llvm.org/4.0.0/docs/ReleaseNotes.html> <http://releases.llvm.org/4.0.0/tools/clang/docs/ReleaseNotes.html> <http://releases.llvm.org/4.0.0/tools/lld/docs/ReleaseNotes.html>
Thanks to Ed Maste, Jan Beich, Antoine Brodin and Eric Fiselier for their help.
Relnotes: yes Exp-run: antoine PR: 215969, 216008
MFC r314708:
For now, revert r287232 from upstream llvm trunk (by Daniil Fukalov):
[SCEV] limit recursion depth of CompareSCEVComplexity
Summary: CompareSCEVComplexity goes too deep (50+ on a quite a big unrolled loop) and runs almost infinite time.
Added cache of "equal" SCEV pairs to earlier cutoff of further estimation. Recursion depth limit was also introduced as a parameter.
Reviewers: sanjoy
Subscribers: mzolotukhin, tstellarAMD, llvm-commits
Differential Revision: https://reviews.llvm.org/D26389
This commit is the cause of excessive compile times on skein_block.c (and possibly other files) during kernel builds on amd64.
We never saw the problematic behavior described in this upstream commit, so for now it is better to revert it. An upstream bug has been filed here: https://bugs.llvm.org/show_bug.cgi?id=32142
Reported by: mjg
MFC r314795:
Reapply r287232 from upstream llvm trunk (by Daniil Fukalov):
[SCEV] limit recursion depth of CompareSCEVComplexity
Summary: CompareSCEVComplexity goes too deep (50+ on a quite a big unrolled loop) and runs almost infinite time.
Added cache of "equal" SCEV pairs to earlier cutoff of further estimation. Recursion depth limit was also introduced as a parameter.
Reviewers: sanjoy
Subscribers: mzolotukhin, tstellarAMD, llvm-commits
Differential Revision: https://reviews.llvm.org/D26389
Pull in r296992 from upstream llvm trunk (by Sanjoy Das):
[SCEV] Decrease the recursion threshold for CompareValueComplexity
Fixes PR32142.
r287232 accidentally increased the recursion threshold for CompareValueComplexity from 2 to 32. This change reverses that change by introducing a separate flag for CompareValueComplexity's threshold.
The latter revision fixes the excessive compile times for skein_block.c.
MFC r314907 | mmel | 2017-03-08 12:40:27 +0100 (Wed, 08 Mar 2017) | 7 lines
Unbreak ARMv6 world.
The new compiler_rt library imported with clang 4.0.0 have several fatal issues (non-functional __udivsi3 for example) with ARM specific instrict functions. As temporary workaround, until upstream solve these problems, disable all thumb[1][2] related feature.
MFC r315016:
Update clang, llvm, lld, lldb, compiler-rt and libc++ to 4.0.0 release. We were already very close to the last release candidate, so this is a pretty minor update.
Relnotes: yes
MFC r316005:
Revert r314907, and pull in r298713 from upstream compiler-rt trunk (by Weiming Zhao):
builtins: Select correct code fragments when compiling for Thumb1/Thum2/ARM ISA.
Summary: Value of __ARM_ARCH_ISA_THUMB isn't based on the actual compilation mode (-mthumb, -marm), it reflect's capability of given CPU.
Due to this: - use __tbumb__ and __thumb2__ insteand of __ARM_ARCH_ISA_THUMB - use '.thumb' directive consistently in all affected files - decorate all thumb functions using DEFINE_COMPILERRT_THUMB_FUNCTION()
--------- Note: This patch doesn't fix broken Thumb1 variant of __udivsi3 !
Reviewers: weimingz, rengolin, compnerd
Subscribers: aemerson, dim
Differential Revision: https://reviews.llvm.org/D30938
Discussed with: mmel
|
#
315312 |
|
15-Mar-2017 |
dchagin |
MFC r305093 (by mjg@):
fd: add fdeget_locked and use in kern_descrip
MFC r305756 (by oshogbo@):
fd: add fget_cap and fget_cap_locked primitives. They can be used to obtain capabilities along with a referenced fp.
MFC r306174 (by oshogbo@):
capsicum: propagate rights on accept(2)
Descriptor returned by accept(2) should inherits capabilities rights from the listening socket.
PR: 201052
MFC r306184 (by oshogbo@):
fd: simplify fgetvp_rights by using fget_cap_locked.
MFC r306225 (by mjg@):
fd: fix up fgetvp_rights after r306184
fget_cap_locked returns a referenced file, but the fgetvp_rights does not need it. Instead, due to the filedesc lock being held, it can ref the vnode after the file was looked up.
Fix up fget_cap_locked to be consistent with other _locked helpers and not ref the file.
This plugs a leak introduced in r306184.
MFC r306232 (by oshogbo@):
fd: fix up fget_cap
If the kernel is not compiled with the CAPABILITIES kernel options fget_unlocked doesn't return the sequence number so fd_modify will always report modification, in that case we got infinity loop.
MFC r311474 (by glebius@):
Use getsock_cap() instead of fgetsock().
MFC r312079 (by glebius@):
Use getsock_cap() instead of deprecated fgetsock().
MFC r312081 (by glebius@):
Use getsock_cap() instead of deprecated fgetsock().
MFC r312087 (by glebius@):
Remove deprecated fgetsock() and fputsock().
Bump __FreeBSD_version as getsock_cap changed and fgetsock/fputsock pair removed.
|
#
311186 |
|
03-Jan-2017 |
bdrewery |
MFC r305256:
Bump __FreeBSD_version for crunchgen META_MODE fix in r311185.
|
#
310618 |
|
26-Dec-2016 |
dim |
MFC r309124:
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
|
#
310120 |
|
15-Dec-2016 |
vangyzen |
MFC r309676
Export the whole thread name in kinfo_proc
kinfo_proc::ki_tdname is three characters shorter than thread::td_name. Add a ki_moretdname field for these three extra characters. Add the new field to kinfo_proc32, as well. Update all in-tree consumers to read the new field and assemble the full name, except for lldb's HostThreadFreeBSD.cpp, which I will handle separately. Bump __FreeBSD_version.
Sponsored by: Dell EMC
|
#
308048 |
|
28-Oct-2016 |
avg |
bump __FreeBSD_version for libzfs_core.h
Direct commit.
|
#
308045 |
|
28-Oct-2016 |
avg |
MFC r307141: remove a few stray spaces from sys/param.h
|
#
307590 |
|
18-Oct-2016 |
gonzo |
Bump __FreeBSD_version for struct fb_info change in r307589
|
#
307330 |
|
14-Oct-2016 |
mav |
Bump __FreeBSD_version for todays ZFS merges.
|
#
305733 |
|
12-Sep-2016 |
hselasky |
MFC r305421: Resolve deadlock between device_detach() and usbd_do_request_flags() by reviving the SX control request lock and refining which lock protects the common scratch area in "struct usb_device".
The SX control request lock was removed by r246759 because it caused a lock order reversal with the USB enumeration lock inside usbd_transfer_setup() as a function of r246616. It was thought that reducing the number of locks would resolve the LOR, but because some USB device drivers use usbd_do_request_flags() inside callback functions, like in taskqueues, a deadlock may occur when these are drained from device_detach(). By restoring the SX control request lock usbd_do_request_flags() is allowed to complete its execution when a USB device driver is detaching. By using the SX control request lock to protect the scratch area, the LOR introduced by r246616 is also resolved.
Bump the FreeBSD version while at it to force recompilation of all USB kernel modules.
Found by: avos@
|
#
304865 |
|
26-Aug-2016 |
ache |
Bump __FreeBSD_version after LC_*_MASK fix
|
#
304609 |
|
22-Aug-2016 |
bdrewery |
MFC r304608:
Bump __FreeBSD_version for C++11 thread_local support in r303795.
PR: 192320
|
#
303979 |
|
11-Aug-2016 |
gjb |
Fix still incorrect __FreeBSD_version values for stable/11 and releng/11.0
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
|
#
303977 |
|
11-Aug-2016 |
gjb |
Fix __FreeBSD_version for stable/11.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
|
#
303976 |
|
11-Aug-2016 |
gjb |
Update stable/11 to 11.0-PRERELEASE. Reset __FreeBSD_version for 11.0-STABLE.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
|