#
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
|
#
360785 |
|
07-May-2020 |
dim |
Adjust UPDATING and ObsoleteFiles.inc dates to match reality.
|
#
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.
|
#
360661 |
|
05-May-2020 |
dim |
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 9.0.1 final release c1a0a213378a458fbea1a5c77b315c7dce08fd05, and a number of follow-ups.
MFC r355948:
Bootstrap mergeinfo for contrib/llvm-project
Merge (record-only) the following paths to contrib/llvm-project: * ^/vendor/llvm-project/master * ^/vendor/llvm-project/release-8.x * ^/vendor/llvm-project/release-9.x
MFC r355951:
Merge empty dir updates from r355950 in vendor/llvm-project.
MFC r355957:
Merge diff elimination updates from r355953 into vendor/llvm-project.
MFC r355959:
Consolidate FREEBSD-Xlist files of different llvm sub-projects into one.
MFC r356004:
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 9.0.1 final release c1a0a213378a458fbea1a5c77b315c7dce08fd05.
Release notes for llvm, clang, lld and libc++ 9.0.1 will become available here:
https://releases.llvm.org/9.0.1/docs/ReleaseNotes.html https://releases.llvm.org/9.0.1/tools/clang/docs/ReleaseNotes.html https://releases.llvm.org/9.0.1/tools/lld/docs/ReleaseNotes.html https://releases.llvm.org/9.0.1/projects/libcxx/docs/ReleaseNotes.html
PR: 240629
MFC r356005:
Merge commit f97936fab from llvm git (by Eric Fiselier):
[libc++] Cleanup and enable multiple warnings.
Too many warnings are being disabled too quickly. Warnings are important to keeping libc++ correct. This patch re-enables two warnings: -Wconstant-evaluated and -Wdeprecated-copy.
In future, all warnings disabled for the test suite should require an attached bug. The bug should state the plan for re-enabling that warning, or a strong case why it should remain disabled.
This should fix a number of new g++ 9 warnings.
Requested by: rlibby
MFC r356100:
Merge commit d3aeac8e2 from llvm git (by Justin Hibbits)
[PowerPC] Only use PLT annotations if using PIC relocation model
Summary: The default static (non-PIC, non-PIE) model for 32-bit powerpc does not use @PLT annotations and relocations in GCC. LLVM shouldn't use @PLT annotations either, because it breaks secure-PLT linking with (some versions of?) GNU LD.
Update the available-externally.ll test to reflect that default mode should be the same as the static relocation, by using the same check prefix.
Reviewed by: sfertile Differential Revision: https://reviews.llvm.org/D70570
Reviewed by: jhibbits Differential Revision: https://reviews.freebsd.org/D22913
MFC r356104 (by jhibbits):
[PowerPC] enable atomic.c in compiler_rt and do not check and forces lock/lock_free decisions in compiled time
Summary: Enables atomic.c in compiler_rt and forces clang to not emit a call for runtime decision about lock/lock_free. At compiling time, if clang can't decide if atomic operation can be lock free, it emits calls to external functions like `__atomic_is_lock_free`, `__c11_atomic_is_lock_free` and `__atomic_always_lock_free`, postponing decision to a runtime check. According to LLVM code documentation, the mechanism exists due to differences between x86_64 processors that can't be decided at runtime.
On PowerPC and PowerPCSPE (32 bits), we already know in advance it can't be lock free, so we force the decision at compile time and avoid having to implement it in an external library.
This patch was made after 32 bit users testing the PowePC32 bit ISO reported llvm could not be compiled with in-base llvm due to `__atomic_load8` not implemented.
Submitted by: alfredo.junior_eldorado.org.br Reviewed by: jhibbits, dim
Differential Revision: https://reviews.freebsd.org/D22549
MFC r356112 (by jhibbits):
[PowerPC64] Starting from FreeBSD 13.0, default to ELFv2 ABI
This changes the LLVM default powerpc64 ABI to ELFv2, if target OS is FreeBSD >= 13.0
This will also be sent upstream.
Submitted by: alfredo.junior_eldorado.org.br Reviewed by: dim, luporl Relnotes: YES Differential Revision: https://reviews.freebsd.org/D20383
MFC r356256:
Merge commit 468a0cb5f from llvm git (by Craig Topper):
[X86] Add X87 FCMOV support to X86FlagsCopyLowering.
Fixes PR44396
Merge commit 86f48999f from llvm git (by Craig Topper):
[X86] Fix typo in getCMovOpcode.
The 64-bit HasMemoryOperand line was using CMOV32rm instead of CMOV64rm. Not sure how to test this. We have no test coverage that passes true for HasMemoryOperand.
This fixes 'Assertion failed: (MI.findRegisterDefOperand(X86::EFLAGS) && "Expected a def of EFLAGS for this instruction!"), function runOnMachineFunction' when compiling the misc/gpsim port for i386.
Reported by: yuri Upstream PR: https://bugs.llvm.org/show_bug.cgi?id=44396
MFC r356329:
Merge commit 41449c58c from llvm git (by Roger Ferrer Ibanez):
[RISCV] Fix evaluation of %pcrel_lo
The following testcase
function: .Lpcrel_label1: auipc a0, %pcrel_hi(other_function) addi a1, a0, %pcrel_lo(.Lpcrel_label1) .p2align 2 # Causes a new fragment to be emitted
.type other_function,@function other_function: ret
exposes an odd behaviour in which only the %pcrel_hi relocation is evaluated but not the %pcrel_lo.
$ llvm-mc -triple riscv64 -filetype obj t.s | llvm-objdump -d -r -
<stdin>: file format ELF64-riscv
Disassembly of section .text: 0000000000000000 function: 0: 17 05 00 00 auipc a0, 0 4: 93 05 05 00 mv a1, a0 0000000000000004: R_RISCV_PCREL_LO12_I other_function+4
0000000000000008 other_function: 8: 67 80 00 00 ret
The reason seems to be that in RISCVAsmBackend::shouldForceRelocation we only consider the fragment but in RISCVMCExpr::evaluatePCRelLo we consider the section. This usually works but there are cases where the section may still be the same but the fragment may be another one. In that case we end forcing a %pcrel_lo relocation without any %pcrel_hi.
This patch makes RISCVAsmBackend::shouldForceRelocation use the section, if any, to determine if the relocation must be forced or not.
Differential Revision: https://reviews.llvm.org/D60657
This is a prerequisite for building and linking hard- and soft-float riscv worlds with clang and lld.
Requested by: jhb
MFC r356330:
Merge commit da7b129b1 from llvm git (by James Clarke):
[RISCV] Don't force Local Exec TLS for non-PIC
Summary:
Forcing Local Exec TLS requires the use of copy relocations. Copy relocations need special handling in the runtime linker when being used against TLS symbols, which is present in glibc, but not in FreeBSD nor musl, and so cannot be relied upon. Moreover, copy relocations are a hack that embed the size of an object in the ABI when it otherwise wouldn't be, and break protected symbols (which are expected to be DSO local), whilst also wasting space, thus they should be avoided whenever possible. As discussed in D70398, RISC-V should move away from forcing Local Exec, and instead use Initial Exec like other targets, with possible linker relaxation to follow. The RISC-V GCC maintainers also intend to adopt this more-conventional behaviour (see https://github.com/riscv/riscv-elf-psabi-doc/issues/122).
Reviewers: asb, MaskRay
Reviewed By: MaskRay
Subscribers: emaste, krytarowski, hiraditya, rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, lenary, s.egerton, pzheng, sameer.abuasal, apazos, llvm-commits, bsdjhb
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70649
This is a prerequisite for building and linking hard- and soft-float riscv worlds with clang and lld.
Requested by: jhb
MFC r356331:
?Merge commit c6b09bff5 from llvm git (by Lu?s Marques):
[RISCV] Fix wrong CFI directives
Summary: Removes CFI CFA directives that could incorrectly propagate beyond the basic block they were inteded for. Specifically it removes the epilogue CFI directives. See the branch_and_tail_call test for an example of the issue. Should fix the stack unwinding issues caused by the incorrect directives.
Reviewers: asb, lenary, shiva0217 Reviewed By: lenary Tags: #llvm Differential Revision: https://reviews.llvm.org/D69723
This is a prerequisite for building and linking hard- and soft-float riscv worlds with clang and lld.
Requested by: jhb
MFC r356332:
?Merge commit d7be3eab5 from llvm git (by Lu?s Marques):
[RISCV] Handle fcopysign(f32, f64) and fcopysign(f64, f32)
Summary: Adds tablegen patterns to explicitly handle fcopysign where the magnitude and sign arguments have different types, due to the sign value casts being removed the by DAGCombiner. Support for RV32IF follows in a separate commit. Adds tests for all relevant scenarios except RV32IF.
Reviewers: lenary Reviewed By: lenary Tags: #llvm Differential Revision: https://reviews.llvm.org/D70678
This is a prerequisite for building and linking hard- and soft-float riscv worlds with clang and lld.
Requested by: jhb
MFC r356333:
?Merge commit 189b7393d from llvm git (by John Baldwin):
[lld][RISCV] Use an e_flags of 0 if there are only binary input files.
Summary: If none of the input files are ELF object files (for example, when generating an object file from a single binary input file via "-b binary"), use a fallback value for the ELF header flags instead of crashing with an assertion failure.
Reviewers: MaskRay, ruiu, espindola
Reviewed By: MaskRay, ruiu
Subscribers: kevans, grimar, emaste, arichardson, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, llvm-commits, jrtc27
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71101
This is a prerequisite for building and linking hard- and soft-float riscv worlds with clang and lld.
Requested by: jhb
MFC r356701:
Merge commit f46ba4f07 from llvm git (by Simon Atanasyan):
[mips] Use less registers to load address of TargetExternalSymbol
There is no pattern matched `add hi, (MipsLo texternalsym)`. As a result, loading an address of 32-bit symbol requires two registers and one more additional instruction: ``` addiu $1, $zero, %lo(foo) lui $2, %hi(foo) addu $25, $2, $1 ```
This patch adds the missed pattern and enables generation more effective set of instructions: ``` lui $1, %hi(foo) addiu $25, $1, %lo(foo) ```
Differential Revision: https://reviews.llvm.org/D66771
llvm-svn: 370196
Merge commit 59bb3609f from llvm git (by Simon Atanasyan):
[mips] Fix 64-bit address loading in case of applying 32-bit mask to the result
If result of 64-bit address loading combines with 32-bit mask, LLVM tries to optimize the code and remove "redundant" loading of upper 32-bits of the address. It leads to incorrect code on MIPS64 targets.
MIPS backend creates the following chain of commands to load 64-bit address in the `MipsTargetLowering::getAddrNonPICSym64` method: ``` (add (shl (add (shl (add %highest(sym), %higher(sym)), 16), %hi(sym)), 16), %lo(%sym)) ```
If the mask presents, LLVM decides to optimize the chain of commands. It really does not make sense to load upper 32-bits because the 0x0fffffff mask anyway clears them. After removing redundant commands we get this chain: ``` (add (shl (%hi(sym), 16), %lo(%sym)) ```
There is no patterns matched `(MipsHi (i64 symbol))`. Due a bug in `SYM_32` predicate definition, backend incorrectly selects a pattern for a 32-bit symbols and uses the `lui` instruction for loading `%hi(sym)`.
As a result we get incorrect set of instructions with unnecessary 16-bit left shifting: ``` lui at,0x0 R_MIPS_HI16 foo dsll at,at,0x10 daddiu at,at,0 R_MIPS_LO16 foo ```
This patch resolves two problems: - Fix `SYM_32/SYM_64` predicates to prevent selection of patterns dedicated to 32-bit symbols in case of using N64 ABI. - Add missed patterns for 64-bit symbols for `%hi/%lo`.
Fix PR42736.
Differential Revision: https://reviews.llvm.org/D66228
llvm-svn: 370268
These two commits fix a miscompilation of the kernel for mips64, and should allow clang to be used as the default compiler for mips64.
Requested by: arichards
MFC r356789 (by arichardson):
Merge commit 894f742acb from llvm git (by me):
[MIPS][ELF] Use PC-relative relocations in .eh_frame when possible
When compiling position-independent executables, we now use DW_EH_PE_pcrel | DW_EH_PE_sdata4. However, the MIPS ABI does not define a 64-bit PC-relative ELF relocation so we cannot use sdata8 for the large code model case. When using the large code model, we fall back to the previous behaviour of generating absolute relocations.
With this change clang-generated .o files can be linked by LLD without having to pass -Wl,-z,notext (which creates text relocations). This is simpler than the approach used by ld.bfd, which rewrites the .eh_frame section to convert absolute relocations into relative references.
I saw in D13104 that apparently ld.bfd did not accept pc-relative relocations for MIPS ouput at some point. However, I also checked that recent ld.bfd can process the clang-generated .o files so this no longer seems true.
Reviewed By: atanasyan Differential Revision: https://reviews.llvm.org/D72228
Merge commit 8e8ccf47 from llvm git (by me)
[MIPS] Don't emit R_(MICRO)MIPS_JALR relocations against data symbols
The R_(MICRO)MIPS_JALR optimization only works when used against functions. Using the relocation against a data symbol (e.g. function pointer) will cause some linkers that don't ignore the hint in this case (e.g. LLD prior to commit 5bab291) to generate a relative branch to the data symbol which crashes at run time. Before this patch, LLVM was erroneously emitting these relocations against local-dynamic TLS function pointers and global function pointers with internal visibility.
Reviewers: atanasyan, jrtc27, vstefanovic Reviewed By: atanasyan Differential Revision: https://reviews.llvm.org/D72571
These two changes should allow using lld for MIPS64 (and maybe also MIPS32) by default. The second commit is not strictly necessary for clang+lld since LLD9 will not perform the R_MIPS_JALR optimization (it was only added for 10) but it is probably required in order to use recent ld.bfd.
Reviewed By: dim, emaste Differential Revision: https://reviews.freebsd.org/D23203
MFC r356929:
Merge commit bc4bc5aa0 from llvm git (by Justin Hibbits):
Add 8548 CPU definition and attributes
8548 CPU is GCC's name for the e500v2, so accept this in clang. The e500v2 doesn't support lwsync, so define __NO_LWSYNC__ for this as well, as GCC does.
Differential Revision: https://reviews.llvm.org/D67787
Merge commit ff0311c4b from llvm git (by Justin Hibbits):
[PowerPC]: Add powerpcspe target triple subarch component
Summary: This allows the use of '-target powerpcspe-unknown-linux-gnu' or 'powerpcspe-unknown-freebsd' to be used, instead of '-target powerpc-unknown-linux-gnu -mspe'.
Reviewed By: dim Differential Revision: https://reviews.llvm.org/D72014
Merge commit ba91dffaf from llvm git (by Fangrui Song):
[Driver][PowerPC] Move powerpcspe logic from cc1 to Driver
Follow-up of D72014. It is more appropriate to use a target feature instead of a SubTypeArch to express the difference.
Reviewed By: #powerpc, jhibbits
Differential Revision: https://reviews.llvm.org/D72433
commit 36eedfcb3 from llvm git (by Justin Hibbits):
[PowerPC] Fix powerpcspe subtarget enablement in llvm backend
Summary:
As currently written, -target powerpcspe will enable SPE regardless of disabling the feature later on in the command line. Instead, change this to just set a default CPU to 'e500' instead of a generic CPU.
As part of this, add FeatureSPE to the e500 definition.
Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D72673
These are needed to unbreak the build for powerpcspe.
Requested by: jhibbits
MFC r358711:
Merge commit f75939599 from llvm git (by Erich Keane):
Reland r374450 with Richard Smith's comments and test fixed.
The behavior from the original patch has changed, since we're no longer allowing LLVM to just ignore the alignment. Instead, we're just assuming the maximum possible alignment.
Differential Revision: https://reviews.llvm.org/D68824
llvm-svn: 374562
This fixes 'Assertion failed: (Alignment != 0 && "Invalid Alignment"), function CreateAlignmentAssumption', when building recent versions of v8, which invoke __builtin_assume_aligned() with its alignment argument set to 4GiB or more.
Clang will now report a warning, and show the maximum possible alignment instead, e.g.:
huge-align.cpp:1:27: warning: requested alignment must be 536870912 bytes or smaller; maximum alignment assumed [-Wbuiltin-assume-aligned-alignment] void *f(void *g) { return __builtin_assume_aligned(g, 4294967296); } ^ ~~~~~~~~~~
Upstream PR: https://bugs.llvm.org/show_bug.cgi?id=43839 Reported by: cem
|
#
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
|
#
360593 |
|
03-May-2020 |
asomers |
MFC r360087:
libbsm: fix some MLINKS
Add missing MLINKS entries for a few functions. Remove some old typo entries.
Reported by: phk Reviewed by: cem
|
#
360327 |
|
25-Apr-2020 |
delphij |
MFC rr359961 (jkim): Do not attempt to remove backward compatibility timezones.
|
#
356775 |
|
16-Jan-2020 |
kevans |
MFC r356356, r356358, r356422: replace gcclibs' libssp
r356356: Provide libssp based on libc
For libssp.so, rebuild stack_protector.c with FORTIFY_SOURCE stubs that just abort built into it.
For libssp_nonshared.a, steal stack_protector_compat.c from ^/lib/libc/secure and massage it to maintain that __stack_chk_fail_local is a hidden symbol.
libssp is now built unconditionally regardless of {WITH,WITHOUT}_SSP in the build environment, and the gcclibs version has been disconnected from the build in favor of this one.
r356358: libssp: fix FORTIFY_SOURCE stub declarations
The LSB 4.1 that I referenced omitted the varargs, and I failed to catch it. The __vsnprintf_chk error was from just downright misreading the page. GCC6 caught all of these, but I had only tested GCC4.2.
r356422: Update libssp paths in various Makefile.depend* files
I've been advised that the model that uses these are fairly resilient, but we do know the proper path to use (or remove, in the case of ^/targets/...), so go ahead and update them to reflect that.
|
#
356345 |
|
04-Jan-2020 |
cy |
MFC r333552,333558-333568,333573,338568-338569,339275,339278,339294,340037, r349720,356228:
r333552 (des):
Upgrade Unbound to 1.6.0. More to follow.
r333558 (des):
Upgrade Unbound to 1.6.1. More to follow.
r333559 (des):
Upgrade Unbound to 1.6.2. More to follow.
r333560 (des):
Upgrade Unbound to 1.6.3. More to follow.
r333561 (des):
Upgrade Unbound to 1.6.4. More to follow.
r333562 (des):
Upgrade Unbound to 1.6.5. More to follow.
r333563 (des):
Upgrade Unbound to 1.6.6. More to follow.
r333564 (des):
Upgrade Unbound to 1.6.7. More to follow.
r333565 (des):
No reason to keep this around.
r333566 (des):
Upgrade Unbound to 1.6.8. More to follow.
r333567 (des):
Upgrade Unbound to 1.7.0. More to follow.
r333568 (des):
Upgrade Unbound to 1.7.1.
r333573 (des):
Rename all Unbound binaries and man pages from unbound* to local-unbound*.
PR: 222902
r338568 (des):
Upgrade Unbound to 1.7.2. More to follow.
r338569 (des):
Upgrade Unbound to 1.7.3. More to follow.
r339275 (des):
Upgrade Unbound to 1.8.0. More to follow.
r339278 (des):
Upgrade to 1.8.1.
r339294 (des):
Try harder to sanitize the environment before running configure. Remove a workaround for older Unbound versions that used sbrk.
r340037 (des):
Merge upstream r4932: turn so-reuseport option off by default.
r349720 (des):
Upgrade Unbound to 1.9.2.
MFC r356228 (cy): MFV r356143:
Update unbound 1.9.2 --> 1.9.6.
Security: CVE-2017-15105 (fixed by 1.6.7) CVE-2019-18934 (fixed by 1.9.5)
|
#
355768 |
|
15-Dec-2019 |
emaste |
MFC r355638: ObsoleteFiles.inc: chase libpcap update in r334277
libpcap 1.9.0 (pre-release) update removed the export-defs.h header.
PR: 242559 Submitted by: John Hein
|
#
355131 |
|
27-Nov-2019 |
cy |
MFC r315223, r325182:
Disconnect ipftest and ipresend from the build until it can be verified that they still work. These utilities have become out of sync with the code in the kernel and need work to bring them back into shape. Most people test on real systems or VMs on real networks.
Suggested by: glebius
|
#
350259 |
|
23-Jul-2019 |
dim |
MFC r348504 (by kevans):
llvm-symbolizer: Move out of CLANG_EXTRAS, into CLANG
ASAN reports become a lot more useful with llvm-symbolizer in $PATH, and the build is not much more time-consuming. The added benefit is that the resulting reports will actually include symbol information; without, thread trace information includes a bunch of addresses that immediately resolve to an inline function in ^/contrib/compiler-rt/lib/sanitizer_common/sanitizer_common.h and take a little more effort to examine.
Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D20484
MFC r348689 (by emaste):
Use CLANG knob to remove llvm-symbolizer man page
r348504 moved llvm-symbolizer from the CLANG_EXTRAS knob to CLANG, but the man page was still in the CLANG_EXTRAS section in OptionalObsoleteFiles.inc.
Reported by: jhb
MFC r349004:
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt, libc++, libunwind and openmp to the upstream release_80 branch r363030 (effectively, 8.0.1 rc2). The 8.0.1 release should follow this within a week or so.
MFC r349351 (by jhibbits, partially):
powerpc: Transition to Secure-PLT, like most other OSs (Toolchain part)
Summary: Toolchain follow-up to r349350. LLVM patches will be submitted upstream for 9.0 as well.
The bsd.cpu.mk change is required because GNU ld assumes BSS-PLT if it cannot determine for certain that it needs Secure-PLT, and some binaries do not compile in such a way to make it know to use Secure-PLT.
Reviewed By: nwhitehorn, bdragon, pfg Differential Revision: https://reviews.freebsd.org/D20598
MFC r349793:
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt, libc++, libunwind and openmp to the upstream release_80 branch r364487 (effectively, 8.0.1 rc3). The 8.0.1 release will most likely have no further changes.
MFC r350177:
Merge llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and openmp 8.0.1 final release r366581. The only functional change is a fix for a mismerge of upstream r360816, which properly restores the r2 register when unwinding on PowerPC64 (See https://reviews.freebsd.org/D20337).
Relnotes: yes PR: 236062
|
#
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
|
#
344213 |
|
16-Feb-2019 |
dim |
Merge clang 7.0.1 and several follow-up changes
MFC r318594:
Add libc++experimental.a for std::experimental support
This adds a separate library for supporting std::experimental features. It is purposefully static, and must be explicitly linked into programs using -lc++experimental.
PLEASE NOTE: there is NO WARRANTY as to any stability or continuing existence of the features in the std::experimental parts of the C++ library!
Reviewed by: ed Differential Revision: https://reviews.freebsd.org/D10840
MFC r318598:
Add PICFLAG to build libc++experimental.a, so it can be used in all situations.
Noticed by: kib
r336969 | emaste | 2018-07-31 16:12:09 +0200 (Tue, 31 Jul 2018) | 13 lines
llvm: [ELF][ARM] Add Arm ABI names for float ABI ELF Header flags
The ELF for the Arm architecture document defines, for EF_ARM_EABI_VER5 and above, the flags EF_ARM_ABI_FLOAT_HARD and EF_ARM_ABI_FLOAT_SOFT. These have been defined to be compatible with the existing EF_ARM_VFP_FLOAT and EF_ARM_SOFT_FLOAT used by gcc for EF_ARM_EABI_UNKNOWN.
This patch adds the flags in addition to the existing ones so that any code depending on the old names will still work.
Obtained from: llvm r338370 by Peter Smith
r336970 | emaste | 2018-07-31 16:14:41 +0200 (Tue, 31 Jul 2018) | 9 lines
llvm: [ARM] Complete enumeration values for Tag_ABI_VFP_args
The LLD implementation of Tag_ABI_VFP_args needs to check the rarely seen values of 3 (toolchain specific) and 4 compatible with both Base and VFP. Add the missing enumeration values so that LLD can refer to them without having to use the raw numbers.
Obtained from: llvm r338373 by Peter Smith
r336972 | emaste | 2018-07-31 17:25:03 +0200 (Tue, 31 Jul 2018) | 37 lines
lld: [ELF][ARM] Implement support for Tag_ABI_VFP_args
The Tag_ABI_VFP_args build attribute controls the procedure call standard used for floating point parameters on ARM. The values are:
0 - Base AAPCS (FP Parameters passed in Core (Integer) registers 1 - VFP AAPCS (FP Parameters passed in FP registers) 2 - Toolchain specific (Neither Base or VFP) 3 - Compatible with all (No use of floating point parameters)
If the Tag_ABI_VFP_args build attribute is missing it has an implicit value of 0.
We use the attribute in two ways:
* Detect a clash in calling convention between Base, VFP and Toolchain.
we follow ld.bfd's lead and do not error if there is a clash between an implicit Base AAPCS caused by a missing attribute. Many projects including the hard-float (VFP AAPCS) version of glibc contain assembler files that do not use floating point but do not have Tag_ABI_VFP_args.
* Set the EF_ARM_ABI_FLOAT_SOFT or EF_ARM_ABI_FLOAT_HARD ELF header flag
for Base or VFP AAPCS respectively. This flag is used by some ELF loaders.
References: * Addenda to, and Errata in, the ABI for the ARM Architecture for Tag_ABI_VFP_args * Elf for the ARM Architecture for ELF header flags
Fixes LLVM PR36009
PR: 229050 Obtained from: llvm r338377 by Peter Smith
r337282 | alc | 2018-08-04 04:30:51 +0200 (Sat, 04 Aug 2018) | 7 lines
Set the default image base on arm64 and i386 to a superpage-aligned address.
Reviewed by: emaste, markj Discussed with: dim Differential Revision: https://reviews.freebsd.org/D16385
r339304 | emaste | 2018-10-11 15:19:17 +0200 (Thu, 11 Oct 2018) | 13 lines
lld: set sh_link and sh_info for .rela.plt sections
ELF spec says that for SHT_REL and SHT_RELA sh_link should reference the associated string table and sh_info should reference the "section to which the relocation applies." ELF Tool Chain's elfcopy / strip use this (in part) to control whether or not the relocation entry is copied to the output.
LLVM PR 37538 https://bugs.llvm.org/show_bug.cgi?id=37538
Approved by: re (kib) Obtained from: llvm r344226 (backported for 6.0)
MFC r341825:
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to the upstream release_70 branch r348686 (effectively, 7.0.1 rc3). The release will follow very soon, but no more functional changes are expected.
Release notes for llvm, clang and lld 7.0.0 are available here: <http://releases.llvm.org/7.0.0/docs/ReleaseNotes.html> <http://releases.llvm.org/7.0.0/tools/clang/docs/ReleaseNotes.html> <http://releases.llvm.org/7.0.0/tools/lld/docs/ReleaseNotes.html>
PR: 230240, 230355 Relnotes: yes
MFC r342123:
Update clang, llvm, lld, lldb, compiler-rt and libc++ version number to 7.0.1 release r349250. There were no functional changes since the 7.0.1 rc3 import.
PR: 230240, 230355 Relnotes: yes
r343429 | emaste | 2019-01-25 15:46:13 +0100 (Fri, 25 Jan 2019) | 16 lines
clang: default to DWARF 4 as of FreeBSD 13
FreeBSD previously defaulted to DWARF 2 because several tools (gdb, ctfconvert, etc.) did not support later versions. These have either been fixed or are deprecated.
Note that gdb 6 still exists but has been moved out of $PATH into /usr/libexec and is intended only for use by crashinfo(8). The kernel build sets the DWARF version explicitly via -gdwarf2, so this should have no effect there.
PR: 234887 [exp-run] Reviewed by: markj Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D17930
MFC r343916:
Pull in r352607 from upstream llvm trunk (by Craig Topper):
[X86] Add FPSW as a Def on some FP instructions that were missing it.
Pull in r353141 from upstream llvm trunk (by Craig Topper):
[X86] Connect the default fpsr and dirflag clobbers in inline assembly to the registers we have defined for them.
Summary: We don't currently map these constraints to physical register numbers so they don't make it to the MachineIR representation of inline assembly.
This could have problems for proper dependency tracking in the machine schedulers though I don't have a test case that shows that.
Reviewers: rnk
Reviewed By: rnk
Subscribers: eraman, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D57641
Pull in r353489 from upstream llvm trunk (by Craig Topper):
[X86] Add FPCW as a register and start using it as an implicit use on floating point instructions.
Summary: FPCW contains the rounding mode control which we manipulate to implement fp to integer conversion by changing the roudning mode, storing the value to the stack, and then changing the rounding mode back. Because we didn't model FPCW and its dependency chain, other instructions could be scheduled into the middle of the sequence.
This patch introduces the register and adds it as an implciit def of FLDCW and implicit use of the FP binary arithmetic instructions and store instructions. There are more instructions that need to be updated, but this is a good start. I believe this fixes at least the reduced test case from PR40529.
Reviewers: RKSimon, spatel, rnk, efriedma, andrew.w.kaylor
Subscribers: dim, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D57735
These should fix a problem in clang 7.0 where it would sometimes emit long double floating point instructions in a slightly wrong order, leading to failures in our libm tests. In particular, the cbrt_test test case 'cbrtl_powl' and the trig_test test case 'reduction'.
Also bump __FreeBSD_cc_version, to be able to detect this in our test suite.
Reported by: lwhsu PR: 234040 Upstream PR: https://bugs.llvm.org/show_bug.cgi?id=40206
MFC r344056:
Pull in r339734 from upstream llvm trunk (by Eli Friedman):
[ARM] Make PerformSHLSimplify add nodes to the DAG worklist correctly.
Intentionally excluding nodes from the DAGCombine worklist is likely to lead to weird optimizations and infinite loops, so it's generally a bad idea.
To avoid the infinite loops, fix DAGCombine to use the isDesirableToCommuteWithShift target hook before performing the transforms in question, and implement the target hook in the ARM backend disable the transforms in question.
Fixes https://bugs.llvm.org/show_bug.cgi?id=38530 . (I don't have a reduced testcase for that bug. But we should have sufficient test coverage for PerformSHLSimplify given that we're not playing weird tricks with the worklist. I can try to bugpoint it if necessary, though.)
Differential Revision: https://reviews.llvm.org/D50667
This should fix a possible hang when compiling sys/dev/nxge/if_nxge.c (which exists now only in the stable/11 branch) for arm.
|
#
342808 |
|
06-Jan-2019 |
kevans |
Revert r342807, mistakenly including libbe(3)/bectl(8) MFC
|
#
342807 |
|
06-Jan-2019 |
kevans |
MFC r342362-r342363: config(8) duplicate option handling
r342362: config(8): Allow duplicate options to be specified
config(8)'s option handling has been written to allow duplicate options; if the value changes, then the latest value is used and an informative message is printed to stderr like so:
/usr/src/sys/amd64/conf/TEST: option "VERBOSE_SYSINIT" redefined from 0 to 1
Currently, this is only a possibility for cpu types, MAXUSERS, and MACHINE_ARCH. Anything else duplicated in a config file will use the first value set and error about duplicated options on subsequent appearances, which is arguably unfriendly since one could specify:
include GENERIC nooptions VERBOSE_SYSINIT options VERBOSE_SYSINIT
to redefine the value later anyways.
Reported by: mmacy
r342363: config(8): Remove all instances of an option when opting out
Quick follow-up to r342362: options can appear multiple times now, so clean up all of them as needed. For non-OPTIONS options, this has no effect since they're already de-duplicated.
|
#
337681 |
|
12-Aug-2018 |
kib |
MFC r336568: Move OFED libraries libmlx5.so.1 and libibverbs.so.1 to /lib.
|
#
336278 |
|
14-Jul-2018 |
dim |
MFC r335799:
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 6.0.1 release (upstream r335540).
Relnotes: yes
MFC r335813:
Follow-up to r335799 (llvm/clang 6.0.1 update), by regenerating various headers with new version information defines.
MFC r335819:
More follow-up to r335799 (llvm/clang 6.0.1 update), where I forgot to update mtree files, ObsoleteFiles and a number of other paths. Sorry about all the breakage.
Pointy hat to: me
|
#
335088 |
|
13-Jun-2018 |
dim |
MFC r334886:
Add missed libc++ entries to (Optional)ObsoleteFiles.inc
Some of these were removed during the libc++ 5.0.0 import, others were added in the libc++ 6.0.0 import.
|
#
333617 |
|
15-May-2018 |
dteske |
MFC SVN r329188,329334,329353,329914,329995-329996: DTrace Enhancements
r329188: Use tabs in io.d, fix alignment issues, remove extra newlines r329334: Add errno definitions to /usr/lib/dtrace/errno.d r329353: Add inline to errno.d for translating int to string r329914: Updates and enhancements to io.d to aid DTrace scripting r329995: Updates and enhancements to signal.d to aid DTrace scripting r329996: Consistent casing for fallback SIGCHLD (s/Unknown/unknown/)
MFC SVN r330559-330560,330672,332865-332867,333513-333519: dwatch(1)
r330559: Introduce dwatch(1) as a tool for making DTrace more useful r330560: Bump dwatch(1) internal version from 1.0-beta-91 to 1.0 r330672: Fix display of wrong pid from dtrace_sched(4) r332865: Add `-dev' option to aid debugging of profiles r332866: Add profile for send(2)/recv(2) syscalls r332867: Remove the line used to demonstrate `-dev' option r333513: Bugfix, usage displayed with `-1Q' r333514: Separate default values so `-[BK] num' don't affect usage r333515: Simplify info message test r333516: Export ARGV to profiles loaded via load_profile() r333517: Allow `-E code' to override profile EVENT_DETAILS r333518: Expose process for ip/tcp/udp r333519: Refactor sendrecv profile
Reviewed by: markj, gnn, bdrewery (head; earlier version) Approved by: re (gjb) Relnotes: yes Sponsored by: Smule, Inc. Differential Revision: https://reviews.freebsd.org/D15418
|
#
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.
|
#
329242 |
|
13-Feb-2018 |
jkim |
MFC: r329024
Remove c_rehash(1) to not confuse users.
|
#
329183 |
|
12-Feb-2018 |
kevans |
MFC Loader Fixes Final: r327612,r327703,r327704,r327878,r327879,r327881, r328007,r328029,r328030,r328031,r328061,r328156,r328169,r328288,r328289, r328290,r328291,r328292,r328411,r328536,r328603,r328614,r328642,r328769, r328779,r328780,r328781,r328782,r328783,r328806,r328808,r328826,r328835, r328911,r328986,r328987,r328990,r328999,r329000,r329019,r329050,r329054, r329060
r327612: Invent new #defines for the biospci_{read,write}_config function
r327703: Define __dmadat after #include'ing ufsread.c.
r327704: Fix printf missing format variables warnings.
r327878: Add GUID for UEFI boot manager variables.
r327879: Report the boot order and where we are in that boot order.
r327881: Allow this file to be included
r328007: Fix booting on some arm64 systems after r327879 by fixing the call to utf8_to_ucs2
r328029: When returning an error and freeing allocated memory from ucs2_to_utf8, NULL the return pointer.
r328030: Check the return value from utf8_to_ucs2 instead of whether or not uv is NULL.
r328031: Need to free uv after we're done using it.
r328061: utf8_to_ucs2() should check for malloc failure
r328156: stand: Move sections around to fix stand/ build with ld.lld on armv7
r328169: Remove extra copy of bootinfo.c. It's a bit rotted copy of the one in efi/loader.
r328288: Fix some resource leaks.
r328289: Don't leak memory when displaying help.
r328290: On malloc failure, be sure to close the include file that triggered it.
r328291: getenv does not return tainted data in the boot loader. Attempt to clue Coverity into that fact.
r328292: There's no tainted data here, tag it as such to avoid false positives.
r328411: loader.efi: add missing EFI GUIDs
r328536: loader: support for mixed-endianness ELF/loader and POWER8
r328603: Add missing non-POWERPC case to give the scr value something non-zero.
r328614: Move libstand.3 to libsa.3. Update libsa.3 to include functions
r328642: Break out the interpreters (simple and forth) w/o ifdefs.
r328769: Centralize several variables.
r328779: Retire pnp.4th and the code needed only for 4th words used here.
r328780: These 4th words were an attempt to allow integration into the boot loader scripts. However, that path won't be taken after all it seems.
r328781: Remove pcibios forth support.
r328782: Now that we no longer conditionally compile some files outside of ficl
r328783: Invent new LDR_INTERP for the loader interpreter to use.
r328806: We need more heap space to properly load newer powerpc kernels.
r328808: Implement strcoll as strcmp.
r328826: Make cross-endian loader changes apply only to powerpc
r328835: Fix regression introduced in r328806, preventing boot on many platforms.
r328911: Ignore relocation tables for non-memory-resident sections.
r328986: Fix relative location of USB sources after recent move.
r328987: A more definitions to kernel emulation shim in order to build stand/usb.
r328990: Move the stand/usb test loader into its own directory.
r328999: Fix indentation to FreeBSD standard for interp files
r329000: Move simple interpreter 'perform' into interp.c and call it
r329019: Move to tabs for indentation and to 8-space notches, per style(9).
r329050: Fix build of userboot.so
r329054: Set script.lang in the environment to either 'forth' or 'simple' to reflect what scripting language was compiled into the loader.
r329060: loader: fix endianness conversion
PR: 225323
|
#
329182 |
|
12-Feb-2018 |
kevans |
Correct date in ObsoleteFiles
Getting a little ahead of myself here- correct the date to today.
|
#
329130 |
|
11-Feb-2018 |
kevans |
MFC Loader Fixes 2017q4p2: r324453, r324454
r324453: Create sys/boot/libsa and build libstand.a there
r324454: Disconnect libstand from the build.
|
#
328811 |
|
02-Feb-2018 |
asomers |
MFC geli test suite changes
MFC r306188, r306395, r327346-r327347, r327352-r327353, r327662, r327666, r327682-r327683, r327685
r306188 by br: Use bsdlabel as we don't have hardlink disklabel -> bsdlabel on some platforms.
Reviewed by: ngie Sponsored by: DARPA, AFRL Sponsored by: HEIF5 Differential Revision: https://reviews.freebsd.org/D7968
r306395 by br: Increase timeouts for geli tests. It takes 2-3x more time to proceed the tests on MIPS64EB in QEMU.
Sponsored by: DARPA, AFRL Sponsored by: HEIF5
r327346: Fix potential TOCTTOU bug in the geli tests
This change mostly reverts r293436, which introduced the bug due to a belief that geli(8) would allocate md(4) devices by itself. However, that belief is incorrect. Instead of using linear probing to find available md(4) numbers, it's best to use the existing attach_md function.
Reviewed by: ngie Sponsored by: Spectra Logic Corp Differential Revision: https://reviews.freebsd.org/D13666
r327347: geli: factor out some common code in the geli tests
No functional change.
Sponsored by: Spectra Logic Corp
r327352: Fix a harmless typo from r310786
I copy/pasted a reference to an undefined shell variable.
r327353: geli: fix the resize test on arm64
The resize test used bsdlabel(8), which is not available on all architectures. Change it to use gpart(8) instead, which should be available everywhere.
PR: 221763 Reported by: andrew
r327662: geli: convert most tests from TAP to ATF
I'm leaving readonly_test and nokey_test alone for now. In a future commit they should be broken up into several smaller test cases and distributed between multiple files.
Reviewed by: ngie Differential Revision: https://reviews.freebsd.org/D13717
r327666: geli: fix parallel execution of tests
The trick is not to destroy an md(4) device during a test. That can create a "double-free" situation, because we also destroy md devices during test cleanup.
r327682: Fix typo from r327666
X-MFC-With: 327666
r327683: geli: convert remaining TAP tests to ATF
r327685: geli: optimize tests
Reduce the geli tests' runtime by about a third:
* In integrity_test:copy, use a file-backed md(4) device instead of a malloc'd one. That way we can corrupt the underlying storage without needing to detach and reattach the geli device.
* In integrity_test:{copy, hmac, data} and onetime_test:{onetime, onetime_a}, move reads of /dev/random out of the loop.
|
#
327204 |
|
26-Dec-2017 |
dim |
MFC r326496:
Upgrade our copies of clang, llvm, lldb and libc++ to r319231 from the upstream release_50 branch. This corresponds to 5.0.1 rc2.
MFC r326831:
Pull in r315334 from upstream lld trunk (by Rafael Espindola):
Don't create a dummy __tls_get_addr.
We just don't need one with the current setup.
We only error on undefined references that are used by some relocation.
If we managed to relax all uses of __tls_get_addr, no relocation uses it and we don't produce an error.
This is less code and fixes the case were we fail to relax. Before we would produce a broken output, but now we produce an error.
Pull in r320390 from upstream lld trunk (by Rafael Espindola):
Create reserved symbols early so they can be versioned.
This fixes pr35570.
We were creating these symbols after parsing version scripts, so they could not be versioned.
We cannot move the version script parsing later because we need it for lto.
One option is to move both addReservedSymbols and createSyntheticSections earlier. The disadvantage is that some sections created by createSyntheticSections replace other input sections. For example, gdb index replaces .debug_gnu_pubnames, so it wants to run after gc sections so that it can set S->Live to false.
What this patch does instead is to move just the ElfHeader creation early.
Pull in r320412 from upstream lld trunk (by Rafael Espindola):
Handle symbols pointing to output sections.
Now that gc sections runs after linker defined symbols are added it can see symbols that point to an OutputSection.
Should fix a bot failure.
Pull in r320431 from upstream lld trunk (by Peter Collingbourne):
ELF: Do not follow relocation edges to output sections during GC.
This fixes an assertion error introduced by r320390.
Differential Revision: https://reviews.llvm.org/D41095
Together these fix handling of reserved symbols, in particular _end, which is needed to make brk(2) and sbrk(2) work correctly. This unbreaks the emacs ports on amd64, and also appears to unbreak most of world on i386.
Differential Revision: https://reviews.freebsd.org/D13466
MFC r326879 (by emaste):
lld: Simplify a boolean expression by De Morgan's laws.
Cherry-pick lld r315653 by Rui Ueyama: I don't really understand what exactly this expression means, but at least I can mechanically transform it.
Obtained from: LLVM r315653
MFC r326897 (by emaste):
lld: Slightly simplify code and add comment.
Cherry-pick lld r315658 by Rui Ueyama: This is not a mechanical transformation. Even though I believe this patch is correct, I'm not 100% sure if lld with this patch behaves exactly the same way as before on all edge cases. At least all tests still pass.
I'm submitting this patch because it took almost a day to understand this function, and I don't want to lose it.
This fixes jemalloc assertion failures observed at startup with i386 binaries and an lld-linked libc.so.
Reviewed by: dim Obtained from: LLVM r315658 Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D13503
MFC r326909:
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 5.0.1 release (upstream r320880).
Relnotes: yes
MFC r326957 (by emaste):
lld: Don't write preemptible symbol values to the .got.
It is not necessary and matches what bfd and gold do.
This was a regression from [LLVM] r315658.
Obtained from: LLVM r321023 by Rafael Espíndola
|
#
326918 |
|
17-Dec-2017 |
cy |
MFC r326558, r326566:
fdformat is a sysadmin command and thus its man page should be in volume 8 instead of volume 1.
Reviewed by: imp
|
#
324110 |
|
29-Sep-2017 |
dim |
Belatedely fill in the dates for clang 5.0.0 update in UPDATING and ObsoleteFiles.inc.
Noticed by: garga
|
#
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
|
#
323180 |
|
05-Sep-2017 |
markj |
MFC r321963: Rework and simplify the ksyms implementation.
|
#
321129 |
|
18-Jul-2017 |
ngie |
MFC r303212,r319642,r319830:
r303212 (by bdrewery):
Move chown tests to proper path
r319642:
Add some basic tests for chmod(1)
r319830:
Add more simple positive tests for chown(1)
The tests are largely symmetric with the tests for chmod(1)--added in r319642.
Remove chown-f_test (added in r268030) since the test coverage is now being provided by `chown_test`.
|
#
320150 |
|
20-Jun-2017 |
jhb |
MFC 319490: Remove stale cap_rights_get(2) manpage.
The documentation moved to section 3 several years ago, but 'man cap_rights_get' pulls up cap_rights_limit(2) (which is MLINKed to cap_rights_get.2) instead of cap_rights_get(3).
Approved by: re (gjb)
|
#
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>
|
#
318247 |
|
12-May-2017 |
jhb |
MFC 317412,317413: Fixes for info file removal.
317412: Add info files for GCC 4.2 to the list of info files to remove.
This would only affect upgrades from older versions of non-clang platforms.
317413: Remove info files from optional old files.
Info files are now all removed unconditionally after the removal of texinfo.
|
#
316556 |
|
06-Apr-2017 |
ngie |
MFC r316368: r316368 (by jkim):
Fix typos to stop removing new files.
|
#
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
|
#
316419 |
|
02-Apr-2017 |
bapt |
MFC: r315086 (by jhb)
Fix removal of /usr/share/info.
- The GNU as manual is named as.info.gz. - Remove the generated /usr/share/info/dir file.
Reported by: "Herbert J. Skuhra" <herbert@mailbox.org>
|
#
316256 |
|
30-Mar-2017 |
ngie |
MFC r315776:
Rename tests from <foo> to <foo>_test to match the FreeBSD test suite naming scheme
usr.bin/diff/diff_test was renamed to usr.bin/diff/netbsd_diff_test to avoid collisions with the renamed FreeBSD test.
|
#
315994 |
|
26-Mar-2017 |
bapt |
MFC r314902:
texinfo is gone in r276551 remove the related directories
Reported by: jbeich
|
#
315723 |
|
22-Mar-2017 |
bdrewery |
MFC r314886,r314943,r314944:
r314886: pwait: Add a -t flag to specify a timeout before exiting, and tests. r314943: Remove unneeded -x from tests. r314944: Rename some tests to end in _test.
|
#
315514 |
|
18-Mar-2017 |
ae |
MFC r304572 (by bz): Remove the kernel optoion for IPSEC_FILTERTUNNEL, which was deprecated more than 7 years ago in favour of a sysctl in r192648.
MFC r305122: Remove redundant sanity checks from ipsec[46]_common_input_cb().
This check already has been done in the each protocol callback.
MFC r309144,309174,309201 (by fabient): IPsec RFC6479 support for replay window sizes up to 2^32 - 32 packets.
Since the previous algorithm, based on bit shifting, does not scale with large replay windows, the algorithm used here is based on RFC 6479: IPsec Anti-Replay Algorithm without Bit Shifting. The replay window will be fast to be updated, but will cost as many bits in RAM as its size.
The previous implementation did not provide a lock on the replay window, which may lead to replay issues.
Obtained from: emeric.poupon@stormshield.eu Sponsored by: Stormshield Differential Revision: https://reviews.freebsd.org/D8468
MFC r309143,309146 (by fabient): In a dual processor system (2*6 cores) during IPSec throughput tests, we see a lot of contention on the arc4 lock, used to generate the IV of the ESP output packets.
The idea of this patch is to split this mutex in order to reduce the contention on this lock.
Update r309143 to prevent false sharing.
Reviewed by: delphij, markm, ache Approved by: so Obtained from: emeric.poupon@stormshield.eu Sponsored by: Stormshield Differential Revision: https://reviews.freebsd.org/D8130
MFC r313330: Merge projects/ipsec into head/.
Small summary -------------
o Almost all IPsec releated code was moved into sys/netipsec. o New kernel modules added: ipsec.ko and tcpmd5.ko. New kernel option IPSEC_SUPPORT added. It enables support for loading and unloading of ipsec.ko and tcpmd5.ko kernel modules. o IPSEC_NAT_T option was removed. Now NAT-T support is enabled by default. The UDP_ENCAP_ESPINUDP_NON_IKE encapsulation type support was removed. Added TCP/UDP checksum handling for inbound packets that were decapsulated by transport mode SAs. setkey(8) modified to show run-time NAT-T configuration of SA. o New network pseudo interface if_ipsec(4) added. For now it is build as part of ipsec.ko module (or with IPSEC kernel). It implements IPsec virtual tunnels to create route-based VPNs. o The network stack now invokes IPsec functions using special methods. The only one header file <netipsec/ipsec_support.h> should be included to declare all the needed things to work with IPsec. o All IPsec protocols handlers (ESP/AH/IPCOMP protosw) were removed. Now these protocols are handled directly via IPsec methods. o TCP_SIGNATURE support was reworked to be more close to RFC. o PF_KEY SADB was reworked: - now all security associations stored in the single SPI namespace, and all SAs MUST have unique SPI. - several hash tables added to speed up lookups in SADB. - SADB now uses rmlock to protect access, and concurrent threads can do SA lookups in the same time. - many PF_KEY message handlers were reworked to reflect changes in SADB. - SADB_UPDATE message was extended to support new PF_KEY headers: SADB_X_EXT_NEW_ADDRESS_SRC and SADB_X_EXT_NEW_ADDRESS_DST. They can be used by IKE daemon to change SA addresses. o ipsecrequest and secpolicy structures were cardinally changed to avoid locking protection for ipsecrequest. Now we support only limited number (4) of bundled SAs, but they are supported for both INET and INET6. o INPCB security policy cache was introduced. Each PCB now caches used security policies to avoid SP lookup for each packet. o For inbound security policies added the mode, when the kernel does check for full history of applied IPsec transforms. o References counting rules for security policies and security associations were changed. The proper SA locking added into xform code. o xform code was also changed. Now it is possible to unregister xforms. tdb_xxx structures were changed and renamed to reflect changes in SADB/SPDB, and changed rules for locking and refcounting.
Obtained from: Yandex LLC Relnotes: yes Sponsored by: Yandex LLC Differential Revision: https://reviews.freebsd.org/D9352
MFC r313331: Add removed headers into the ObsoleteFiles.inc.
MFC r313561 (by glebius): Move tcp_fields_to_net() static inline into tcp_var.h, just below its friend tcp_fields_to_host(). There is third party code that also uses this inline.
MFC r313697: Remove IPsec related PCB code from SCTP.
The inpcb structure has inp_sp pointer that is initialized by ipsec_init_pcbpolicy() function. This pointer keeps strorage for IPsec security policies associated with a specific socket. An application can use IP_IPSEC_POLICY and IPV6_IPSEC_POLICY socket options to configure these security policies. Then ip[6]_output() uses inpcb pointer to specify that an outgoing packet is associated with some socket. And IPSEC_OUTPUT() method can use a security policy stored in the inp_sp. For inbound packet the protocol-specific input routine uses IPSEC_CHECK_POLICY() method to check that a packet conforms to inbound security policy configured in the inpcb.
SCTP protocol doesn't specify inpcb for ip[6]_output() when it sends packets. Thus IPSEC_OUTPUT() method does not consider such packets as associated with some socket and can not apply security policies from inpcb, even if they are configured. Since IPSEC_CHECK_POLICY() method is called from protocol-specific input routine, it can specify inpcb pointer and associated with socket inbound policy will be checked. But there are two problems: 1. Such check is asymmetric, becasue we can not apply security policy from inpcb for outgoing packet. 2. IPSEC_CHECK_POLICY() expects that caller holds INPCB lock and access to inp_sp is protected. But for SCTP this is not correct, becasue SCTP uses own locks to protect inpcb.
To fix these problems remove IPsec related PCB code from SCTP. This imply that IP_IPSEC_POLICY and IPV6_IPSEC_POLICY socket options will be not applicable to SCTP sockets. To be able correctly check inbound security policies for SCTP, mark its protocol header with the PR_LASTHDR flag.
Differential Revision: https://reviews.freebsd.org/D9538
MFC r313746: Add missing check to fix the build with IPSEC_SUPPORT and without MAC.
MFC r313805: Fix LINT build for powerpc.
Build kernel modules support only when both IPSEC and TCP_SIGNATURE are not defined.
MFC r313922: For translated packets do not adjust UDP checksum if it is zero.
In case when decrypted and decapsulated packet is an UDP datagram, check that its checksum is not zero before doing incremental checksum adjustment.
MFC r314339: Document that the size of AH ICV for HMAC-SHA2-NNN should be half of NNN bits as described in RFC4868.
PR: 215978
MFC r314812: Introduce the concept of IPsec security policies scope.
Currently are defined three scopes: global, ifnet, and pcb. Generic security policies that IKE daemon can add via PF_KEY interface or an administrator creates with setkey(8) utility have GLOBAL scope. Such policies can be applied by the kernel to outgoing packets and checked agains inbound packets after IPsec processing. Security policies created by if_ipsec(4) interfaces have IFNET scope. Such policies are applied to packets that are passed through if_ipsec(4) interface. And security policies created by application using setsockopt() IP_IPSEC_POLICY option have PCB scope. Such policies are applied to packets related to specific socket. Currently there is no way to list PCB policies via setkey(8) utility.
Modify setkey(8) and libipsec(3) to be able distinguish the scope of security policies in the `setkey -DP` listing. Add two optional flags: '-t' to list only policies related to virtual *tunneling* interfaces, i.e. policies with IFNET scope, and '-g' to list only policies with GLOBAL scope. By default policies from all scopes are listed.
To implement this PF_KEY's sadb_x_policy structure was modified. sadb_x_policy_reserved field is used to pass the policy scope from the kernel to userland. SADB_SPDDUMP message extended to support filtering by scope: sadb_msg_satype field is used to specify bit mask of requested scopes.
For IFNET policies the sadb_x_policy_priority field of struct sadb_x_policy is used to pass if_ipsec's interface if_index to the userland. For GLOBAL policies sadb_x_policy_priority is used only to manage order of security policies in the SPDB. For IFNET policies it is not used, so it can be used to keep if_index.
After this change the output of `setkey -DP` now looks like: # setkey -DPt 0.0.0.0/0[any] 0.0.0.0/0[any] any in ipsec esp/tunnel/87.250.242.144-87.250.242.145/unique:145 spid=7 seq=3 pid=58025 scope=ifnet ifname=ipsec0 refcnt=1 # setkey -DPg ::/0 ::/0 icmp6 135,0 out none spid=5 seq=1 pid=872 scope=global refcnt=1
Obtained from: Yandex LLC Sponsored by: Yandex LLC Differential Revision: https://reviews.freebsd.org/D9805
PR: 212018 Relnotes: yes Sponsored by: Yandex LLC
|
#
313753 |
|
15-Feb-2017 |
asomers |
MFC r311893, r313008, r313081
r311893: ATFify the geom gate tests.
This ensures their cleanup routines will be run even if they should timeout.
tests/sys/geom/class/gate/ggate_test.sh tests/sys/geom/class/gate/Makefile Add an ATF test with three testcases, one for each TAP test. Use ATF-style cleanup functions, and convert sleeps to polling loops.
ObsoleteFiles.inc tests/sys/geom/class/gate/conf.sh tests/sys/geom/class/gate/1_test.sh tests/sys/geom/class/gate/2_test.sh tests/sys/geom/class/gate/3_test.sh Delete TAP test files
Reviewed by: ngie MFC after: 4 weeks Sponsored by: Spectra Logic Corp Differential Revision: https://reviews.freebsd.org/D8891
r313008: Wait for /dev/ggate* to appear after calling `ggatel create` in :ggatel_{file,md}
The test assumed that `ggatel create` created a device on completion, but that's incorrect. This squashes the race by waiting for the device to appear, as `ggatel create` daemonizes before issuing an ioctl to geom_gate(4) if not called with `-v`.
Discussed with: asomers MFC after: 1 week PR: 204616 Sponsored by: Dell EMC Isilon
r313081: Replace for/retry loops with "wait_for_ggate_device" calls and check results of commands
As noted in r313008, the underlying issue was that geom_gate device creation wasn't created at ggatel command completion, but some short time after. ggatec(8) employs similar logic when creating geom_gate(4) devices.
Switch from retry loops (after the ggatec/dd write calls) to wait_for_ggate_device function calls after calling ggatec(8) instead to detect the presence of the /dev/ggate* device, as this function is sufficient for determining whether or not the character device is ready for testing
While here, use atf_check consistently with all dd calls to ensure that data output is as expected.
MFC after: 1 week Reviewed by: asomers Differential Revision: D9409 Sponsored by: Dell EMC Isilon
|
#
313570 |
|
11-Feb-2017 |
mm |
MFC r310866,310868,310870,311903,313074: Sync libarchive with vendor.
MFC r310866: PR #771: Add NFSv4 ACL support to pax and restricted pax
NFSv4 ACL information may now be stored to and restored from tar archives. ACL must be non-trivial and supported by the underlying filesystem, e.g. natively by ZFS or by UFS with the NFSv4 ACL enable flag set.
MFC r310868: PR #843: Fix memory leak of struct archive_entry in cpio/cpio.c PR #851: Spelling fixes Fix two protoypes in manual page archive_read_disk.3
MFC r310870: Use __LA_DEPRECATED macro with functions deprecated in 379867e
MFC r311903: #691: Support for SCHILY.xattr extended attributes #854: Spelling fixes
Multiple fixes in ACL code: - prefer acl_set_fd_np() to acl_set_fd() - if acl_set_fd_np() fails, do no fallback to acl_set_file() - do not warn if trying to write ACLs to a filesystem without ACL support - fix id handling in archive_acl_(from_to)_text*() for NFSv4 ACLs
MFC r313074: - support extracting NFSv4 ACLs from Solaris tar archives - bugfixes and optimizations in the ACL code - multiple fixes in the test suite - typo and other small bugfixes
Security fixes: - cab reader: endless loop when parsing MSZIP signature (OSS-Fuzz 335) - LHA reader: heap-buffer-overflow in lha_read_file_header_1() (CVE-2017-5601) - LZ4 reader: null-pointer dereference in lz4_filter_read_legacy_stream() (OSS-Fuzz 453) - mtree reader: heap-buffer-overflow in detect_form() (OSS-Fuzz 421, 443) - WARC reader: heap-buffer-overflow in xstrpisotime() (OSS-Fuzz 382, 458)
Memory leak fixes: - ACL support: free memory allocated by acl_get_qualifier() - disk writer: missing free in create_filesystem_object() - file reader: fd leak (Coverity 1016755) - gnutar writer: fix free in archive_write_gnutar_header() (Coverity 101675) - iso 9660 reader: missing free in parse_file_info() (partial Coverity 1016754) - program reader: missing free in __archive_read_program() - program writer: missing free in __archive_write_program_free() - xar reader: missing free in xar_cleanup() - xar reader: missing frees in expat_xmlattr_setup() (Coverity 1229979-1229981) - xar writer: missing free in file_free() - zip reader: missing free in zip_read_local_file_header()
List of all libarchive issues at OSS-Fuzz: https://bugs.chromium.org/p/oss-fuzz/issues/list?can=1&q=libarchive
Security: CVE-2017-5601
|
#
313242 |
|
04-Feb-2017 |
ngie |
MFC r311174:
Make /usr/lib/libbsnmptools.so.0 into an INTERRNALLIB
Although it increases the size of the bsnmp{get,set,walk} binaries by four on my [amd64] system, it removes the need for producing .debug files, profiled libraries, and for installing the library itself, reducing the overall size use on disk by the utilities noted previously.
Plus, it guards against ABI/API compatibility issues with the library as it's only used internal to the tools themselves.
|
#
312829 |
|
26-Jan-2017 |
asomers |
MFC r310786, r310803, r310985, r311894
r310786: Reduce the runtime of the GELI tests
There is no reduction in test coverage. On my system runtime is reduced from 38m32s to 6m24s.
tests/sys/geom/class/eli/conf.sh tests/sys/geom/class/eli/init_a_test.sh tests/sys/geom/class/eli/init_test.sh tests/sys/geom/class/eli/integrity_copy_test.sh tests/sys/geom/class/eli/integrity_data_test.sh tests/sys/geom/class/eli/integrity_hmac_test.sh tests/sys/geom/class/eli/onetime_a_test.sh tests/sys/geom/class/eli/onetime_test.sh Move the looping code into common functions in conf.sh, and remove alias ciphers from the list.
tests/sys/geom/class/eli/init_a_test.sh tests/sys/geom/class/eli/init_test.sh tests/sys/geom/class/eli/integrity_copy_test.sh tests/sys/geom/class/eli/integrity_data_test.sh tests/sys/geom/class/eli/integrity_hmac_test.sh tests/sys/geom/class/eli/onetime_a_test.sh Move a few commands that don't need to be in the inner loop out.
tests/sys/geom/class/eli/init_test.sh tests/sys/geom/class/eli/onetime_a_test.sh Reduce the sector count
tests/sys/geom/class/eli/Makefile tests/sys/geom/class/eli/init_alias_test.sh Add a test for initializing a GELI device using one of the cipher aliases, and check that the alias is correctly interpreted.
MFC after: 4 weeks Sponsored by: Spectra Logic Corp Differential Revision: https://reviews.freebsd.org/D8814
r310803: ATFify the gnop tests
Also, add test cases for the -p, -P, and -s options to gnop create
Reviewed by: ngie MFC after: 4 weeks Differential Revision: https://reviews.freebsd.org/D8892
r310985: Update ObsoleteFiles.inc for r310803
MFC after: 26 days X-MFC-with: 310803
r311894: Fix typo from change 310985 in ObsoleteFiles.inc
MFC after: 16 days X-MFC-With: 310803 Sponsored by: Spectra Logic Corp
|
#
311999 |
|
12-Jan-2017 |
jhb |
MFC 307538,307948,308602,308603,311151: Move kdump's mksubr into libsysdecode.
307538: Move mksubr from kdump into libsysdecode.
Restructure this script so that it generates a header of tables instead of a source file. The tables are included in a flags.c source file which provides functions to decode various system call arguments.
For functions that decode an enumeration, the function returns a pointer to a string for known values and NULL for unknown values.
For functions that do more complex decoding (typically of a bitmask), the function accepts a pointer to a FILE object (open_memstream() can be used as a string builder) to which decoded values are written. If the function operates on a bitmask, the function returns true if any bits were decoded or false if the entire value was valid. Additionally, the third argument accepts a pointer to a value to which any undecoded bits are stored. This pointer can be NULL if the caller doesn't care about remaining bits.
Convert kdump over to using decoder functions from libsysdecode instead of mksubr. truss also uses decoders from libsysdecode instead of private lookup tables, though lookup tables for objects not decoded by kdump remain in truss for now. Eventually most of these tables should move into libsysdecode as the automated table generation approach from mksubr is less stale than the static tables in truss.
Some changes have been made to truss and kdump output: - The flags passed to open() are now properly decoded in that one of O_RDONLY, O_RDWR, O_WRONLY, or O_EXEC is always included in a decoded mask. - Optional arguments to open(), openat(), and fcntl() are only printed in kdump if they exist (e.g. the mode is only printed for open() if O_CREAT is set in the flags). - Print argument to F_GETLK/SETLK/SETLKW in kdump as a pointer, not int. - Include all procctl() commands. - Correctly decode pipe2() flags in truss by not assuming full open()-like flags with O_RDONLY, etc. - Decode file flags passed to *chflags() as file flags (UF_* and SF_*) rather than as a file mode. - Fix decoding of quotactl() commands by splitting out the two command components instead of assuming the raw command value matches the primary command component.
In addition, truss and kdump now build without triggering any warnings. All of the sysdecode manpages now include the required headers in the synopsis.
307948: Use binary and (&) instead of logical to extract the mask of a capability.
308602: Generate and use a proper .depend file for tables.h.
308603: Move libsysdecode-specific hack out of buildworld.
This should fix the lib32 build since it was not removing the generated ioctl.c. This file is generated by a find(1) call, so cannot use normal dependency tracking methods.
311151: Update libsysdecode for getfsstat() 'flags' argument changing to 'mode'.
As a followup to r310638, update libsysdecode (and kdump) to decode the 'mode' argument to getfsstat(). sysdecode_getfsstat_flags() has been renamed to sysdecode_getfsstat_mode() and now treats the argument as an enumerated value rather than a mask of flags.
|
#
311934 |
|
11-Jan-2017 |
dim |
MFC r311565:
Link llvm-ar to llvm-ranlib, if WITH_CLANG_EXTRAS is enabled. When invoked as llvm-ranlib, it can create an archive symbol table for archives of objects compiled for LTO by an LLVM compiler.
Submitted by: Dan McGregor <danismostlikely@gmail.com>
MFC r311806:
After r311565, also remove llvm-ranlib from ObsoleteFiles.inc.
|
#
310723 |
|
28-Dec-2016 |
emaste |
MFC r310274: Add ld.debug to ObsoleteFiles.inc
After r293285 GNU ld is installed as /usr/bin/ld.bfd, and linked as /usr/bin/ld. The debug file is /usr/lib/debug/usr/bin/ld.bfd.debug.
Sponsored by: The FreeBSD Foundation
|
#
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
|
#
310287 |
|
19-Dec-2016 |
lifanov |
MFC r310160
retain cc.4.gz man page for Chelsio T6 NICs
This man page was removed in r225583 when cc.4 was renamed to mod_cc.4 With reintroduction of cc.4 "make installworld; make delete-old" was no longer convergent.
Reviewed by: matthew Approved by: jhb (implicit), matthew (mentor) Differential Revision: https://reviews.freebsd.org/D8828
|
#
309469 |
|
02-Dec-2016 |
ngie |
MFC r304797,r305467,r305468,r305483:
r304797 (by jmmv):
Make use of Kyua's work directories.
Change the vnode tests to use the current directory when creating temporary files, which we can assume is a volatile work directory, and then make the kqueue_test.sh driver _not_ abandon the directory created by Kyua.
This makes the various kqueue tests independent of each other, and ensures the temporary file is cleaned up on failure.
Problem spotted by asomers@ when reviewing D4254.
r305467:
Move tests/sys/kqueue/... to tests/sys/kqueue/libkqueue/...
This is being done to clearly distinguish the libkqueue tests from the (soon to be imported) NetBSD tests.
r305468:
Port contrib/netbsd-tests/kernel/kqueue/... as tests/sys/kqueue/...
proc2_test must be skipped because the invariant tested (`ke.fflags & NOTE_TRACKERR`) doesn't pass.
r305483:
Fix tests/sys/kqueue NetBSD tests on 32-bit platforms by using proper format specifier for pointers when printing them out with printf(3)
Pointyhat to: ngie
|
#
309315 |
|
30-Nov-2016 |
dexuan |
MFC 308797-308799, 309082
r308797 update the hv_vmbus(4) manual by adding a dependency on pci
We enhanced the vmbus driver to support PCIe pass-through recently.
Reviewed by: sephe Approved by: sephe (mentor) Sponsored by: Microsoft
r308798 remove the hv_ata_pci_disengage(4) manual
A few months ago, we removed the driver, which was not necessary any longer.
Reviewed by: sephe Approved by: sephe (mentor) Sponsored by: Microsoft
r308799 fix share/man/man4/Makefile for hv_ata_pci_disengage.4
We need to remove the line since we removed the related manual just now.
Reviewed by: sephe Approved by: sephe (mentor) Sponsored by: Microsoft
r309082 share/man/man4/Makefile: Only install Hyper-V man pages on amd64 and i386
We shouldn't install them on the architectures not supported by Hyper-V.
And, hv_ata_pci_disengage.4.gz should be removed from all architectures: 1) It should have only applied to Hyper-V; 2) For Hyper-V platforms (amd64 and i386), the related driver was removed by r306426 | sephe | 2016-09-29 09:41:52 +0800 (Thu, 29 Sep 2016), because now we have a better mechanism to disble the ata driver for hard disks when the VM runs on Hyper-V.
Reviewed by: sephe, andrew, jhb Approved by: sephe (mentor) Sponsored by: Microsoft Differential Revision: https://reviews.freebsd.org/D8572
|
#
307340 |
|
15-Oct-2016 |
avos |
MFC r307000, r307001:
mbuf(9), mbuf_tags(9): fix function prototypes.
- Add m_getclr(9) symlink to ObsoleteFiles.inc (removed in r295481). - Add const qualifiers in m_dup(), m_dup_pkthdr() and m_tag_copy_chain() (r286450). - Fix m_dup_pkthdr() definition (it's not the same as m_move_pkthdr()).
|
#
303589 |
|
31-Jul-2016 |
dim |
MFC r303456:
Add tblgen to ObsoleteFiles.inc, as it was renamed to llvm-tblgen.
Approved by: re (kib) Noticed by: pluknet
|
#
303364 |
|
27-Jul-2016 |
ngie |
MFC r302842:
Don't delete usr/share/local/kk_KZ.UTF-8 with "make delete-old" after r302329
kk_KZ.UTF-8 was originally removed in r290494, but restored as an alias to en_US.UTF-8 in r302329
Approved by: re (kib) PR: 211046
|
#
302625 |
|
12-Jul-2016 |
ngie |
MFC r302532:
Correct OLD_LIBS change done in r298840
libkvm.so lives in /lib, not /usr/lib
Approved by: re (gjb)
|
#
302457 |
|
08-Jul-2016 |
bdrewery |
MFC r302449:
Use TARGET here to fix check/delete-old after r302391.
Approved by: re (gjb)
|