#
365988 |
|
22-Sep-2020 |
kevans |
MFC r365829, r365837: certctl rehash upon install/distribute
r365829: installworld: run `certctl rehash` after installation completes
This was originally introduced back in r360833, and subsequently reverted because it was broken for -DNO_ROOT builds and it may not have been the correct place for it.
While debatably this may still not be 'the correct place,' it's much cleaner than scattering rehashes all throughout the tree. brooks has fixed the issue with -DNO_ROOT by properly writing to the METALOG in r361397.
Do note that this is different than what was originally committed; brooks had revisions in D24932 that made it actually use the revised unprivileged mode and write to METALOG, along with being a little more friendly to foreign crossbuilds and just using the certctl in-tree.
With this change, I believe we should now have a populated /etc/ssl/certs in the VM images.
r365837: Promote the installworld `certctl rehash` to distributeworld
Contrary to my belief, installworld is not sufficient for getting certs installed into VM images. Promote the rehash to both installworld and distributeworld (notably: not stageworld) and rehash the base distdir so we end up with /etc/ssl/certs populated in the base dist archive. A future commit will remove the rehash from bsdinstall, which doesn't really need to happen if they're installed into base.txz.
While here, fix a minor typo: s/CERTCLTFLAGS/CERTCTLFLAGS/
|
#
363653 |
|
28-Jul-2020 |
truckman |
Make lex a bootstrap tool when cross-building on recent 13-CURRENT.
The import of flex 2.6.4 into -CURRENT changed the type of yy_n_chars in the lex skeleton from yy_size_t to int, which breaks the build of binutils/ld when using the host copy of lex.
ldlex.c:3216:3: error: incompatible pointer types passing 'int *' to parameter of type 'yy_size_t *' (aka 'unsigned long *') [-Werror,-Wincompatible-pointer-types] ...YY_INPUT( (&YY_CURRENT_BUFFER_LVALUE->yy_ch_buf[number_to_move]), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is a direct commit to stable/11 since binutils/ld has been removed from -CURRENT, and it would require a different fix there since the bootstrap tool version of lex would also cause breakage.
|
#
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
|
#
362918 |
|
04-Jul-2020 |
delphij |
MFC r362452, r362478: liblzma: Make liblzma use libmd implementation of SHA256.
|
#
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
|
#
360643 |
|
04-May-2020 |
dim |
Merge additions of LLVM libunwind libgcc_eh and libgcc_s. This is in preparation of further LLVM merges.
MFC r307230 (by emaste):
Introduce lib/libgcc_eh and lib/libgcc_s for LLVM's implementation
They are not yet connected to the build, but I am adding them to allow for easier testing, ports exp-runs, etc.
Reviewed by: ed Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D8188
MFC r307231 (by emaste):
libgcc_s: add libm dependencies from div{d,s,x}c3
compiler-rt's complex division support routines contain calls to compiler builtins such as `__builtin_scalbnl`. Unfortunately Clang turns these back into a call to `scalbnl`.
For now link libm's C version of the required support routines.
Reviewed by: ed Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D8190
MFC r307864 (by emaste):
Move the LLVM-based libgcc_s to /lib
When enabled, it should install in the same location as the existing library.
Reported by: antoine
MFC r308001 (by emaste):
libgcc_eh/libgcc_s: apply hidden visibility only to static libs
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 r308294 (by emaste):
libgcc_s: make unspecified shlib symbols local
We want only symbols explicitly specified in the Version.map.
Sponsored by: The FreeBSD Foundation
MFC r308308 (by emaste):
Connect new LLVM-based libgcc_eh & libgcc_s to the build
Compiler-rt and LLVM's libunwind provide a suitable replacement for libgcc.a, libgcc_eh.a, and libgcc_s.so.
Remove the now-unused LLVM_LIBUNWIND block from gnu/lib/libgcc.
PR: 213480 [exp-run] Reviewed by: brooks, ed Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D8189
MFC r308379 (by emaste):
add __divdi3 and __udivdi3 to libgcc_s symbol version map
After r308294 they were missing on i386 (and previously were exported only accidentally).
Reported by: antoine
MFC r308445 (by emaste):
add missing i386 symbols libgcc_s symbol version map
After r308294 they were missing on i386 (and previously were exported only accidentally).
Reported by: antoine
MFC r312076 (by emaste):
libgcc_s: add libc DT_NEEDED to fix underlinking
PR: 216012 Reported by: jbeich Sponsored by: The FreeBSD Foundation
MFC r316101 (by ngie):
Apply r315689 to lib/libgcc_s as well to unbreak the gcc xtoolchain build
lib/libgcc_s consumes lib/libcompiler_rt/Makefile*. The NO_WERROR.gcc in lib/libcompiler_rt/Makefile doesn't seem to have made a difference in being able to build this, so sprinkle NO_WERROR.gcc here as well.
Reported by: Jenkins (FreeBSD-head-amd64-gcc) Tested with: amd64-gcc-6.3.0 (devel/amd64-xtoolchain-gcc) Sponsored by: Dell EMC Isilon
MFC r320673 (by emaste):
Sort entries in libgcc_s Version.map
MFC r337585 (by dim):
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
|
#
360542 |
|
01-May-2020 |
dim |
MFC r360322:
Fix race between prebuilding libsbuf and libgeom
The latter needs the former, but with a multi-job build on a fast machine, the race is sometimes lost. This leads to "ld: error: unable to find library -lsbuf", when linking libgeom.so.
Submitted by: kevans
|
#
360234 |
|
24-Apr-2020 |
gjb |
Rename stable/11 to 11.4-PRERELEASE, marking the start of the 11.4 release cycle.
Approved by: re (implicit) Sponsored by: Rubicon Communications, LLC (netgate.com)
|
#
357106 |
|
25-Jan-2020 |
kevans |
MFC r352919: Update cloudabi(32|64) sysents with "make sysent".
Additionally, I've added svr4 which still exists in this branch.
|
#
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.
|
#
353790 |
|
21-Oct-2019 |
kevans |
MFC r352929: Add a top-level makeman target
Abstracting away the details of how src.conf(5) is generated is arguably a good thing; do so with a top-level makeman target.
|
#
347034 |
|
03-May-2019 |
gjb |
Update stable/11 from 11.2-STABLE to 11.3-PRERELEASE, marking the official start of the code slush for the 11.3-RELEASE cycle.
Set the default mdoc(7) version to 11.3, and update the clang(1) TARGET_TRIPLE to reflect 11.3.
Update the default pkg(8) repository to the 'quarterly' branch to prevent further 11.3 builds from downgrading packages when invoking 'pkg upgrade' for the duration of the cycle. This will be reverted on the stable/11 branch once releng/11.3 is branched. [*]
Approved by: re (implicit) MFC after: 6 weeks MFC note: reminder to revert pkg(8) default repository [8] Sponsored by: The FreeBSD Foundation
|
#
346429 |
|
20-Apr-2019 |
kevans |
MFC bectl(8)/libbe(3): r337663-337664,337667,337697-337699,337800,337805, 337915-337918,337921,337924,337947,337993-337995,338221-338222,338303, 338417,339047,339972,339994,340334,340507-340508,340592-340594, 340635-340636,340722-340723,340974,342466,342849,342903,342911,343335, 343543,343977,343993-343994,344034,344067,344084,345302,345769, 345845-345846,345848,346082
There are simply too many small changes to enumerate; in summary:
bectl(8)/libbe(3) has been introduced from current state in -CURRENT and added to the stable/11 rescue build. bectl(8) is a tool for managing ZFS boot environments, largely inspired by beadm. It includes features such as being able to jail a boot environment or easily mount it for modification.
Relnotes: probably
|
#
343595 |
|
30-Jan-2019 |
brooks |
MFC r340242:
Add a top-level make target to rebuild all sysent files.
The sysent target is useful when changing makesyscalls.sh, when making paired changes to syscalls.master files, or in a future where freebsd32 sysent entries are built from the default syscalls.master.
Reviewed by: bdrewery Obtained from: CheriBSD Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D17899
|
#
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.
|
#
337946 |
|
17-Aug-2018 |
kevans |
MFC r337559: Makefile.inc1: Add libl to -legacy as well
libl is needed for config(8), which is a bootstrap-tool. It is possible to build a system WITHOUT_TOOLCHAIN to exclude lex and thus, libl. We still need to support building from this kind of host, though.
While here, group the config(8) dependencies together and add a small explanation. These can likely both be scoped more clearly, but this will need some further investigation.
|
#
337499 |
|
08-Aug-2018 |
bdrewery |
MFC r320280,r320281,r320282,r320283,r320284,r320285,r320692,r322362,r322401,r322402,r336181:
r320280: packages: Allow stageworld/stagekernel to run with make jobs. r320281: packages: Allow staging world/kernel in parallel. r320282: packages: Allow creating kernel/world packages in parallel. r320283: packages: Allow actually building individual world packages in parallel. r320284: packages: Parallelize individual kernel packaging. r320285: Expose only the create-packages-* targets since they set needed DEST/DIRDIR. r320692: Fix create-kernel-packages with multiple BUILDKERNELS after r320284 r322362: Indent nested conditionals for readability. r322401: Avoid creating kernel-dbg.txz distribution sets and kernel-debug packages when MK_DEBUG_FILES is 'no'. r322402: Fix indentation from r322401. r336181: Fix parsing of create-kernel-packages
|
#
337498 |
|
08-Aug-2018 |
bdrewery |
Revert r325808 (MFC r322401) to re-MFC with larger set
|
#
337496 |
|
08-Aug-2018 |
bdrewery |
MFC r320274:
Set compiler metadata for stageworld/distributeworld.
PR: 212877
|
#
337492 |
|
08-Aug-2018 |
bdrewery |
MFC r320286:
compiler-metadata: Properly handle cross-build OBJDIR.
|
#
337489 |
|
08-Aug-2018 |
bdrewery |
MFC r321491:
Remove unneeded dependency for libzfs.
|
#
337488 |
|
08-Aug-2018 |
bdrewery |
MFC r321492:
Only build libzfs_core in 'make libraries' if needed.
|
#
337472 |
|
08-Aug-2018 |
bdrewery |
MFC r335244:
Assert that a build is done before an install.
|
#
337333 |
|
04-Aug-2018 |
kevans |
kenv MFC: r335998, r336019, r336026, r336036, r336217, r336335, r336337, r336415-r336416, r336419
As an aside- this has been slightly altered from the version in head to keep the MD and config-static environments mutually exclusive by default.
This difference is a one-line change in init_static_kenv to setup the MD environment if the config-static environment is empty or if loader_env.disabled is explicitly set to 0.
r335998: kern_environment: use any provided environments, evict hintmode/envmode
At the moment, hintmode and envmode are used to indicate whether static hints or static env have been provided in the kernel config(5) and the static versions are mutually exclusive with loader(8)-provided environment. hintmode *can* be reconfigured later to pull from the dynamic environment, thus taking advantage of the loader(8) or post-kmem environment setting.
This changeset fixes both problems at once to move us from a semi-confusing state to a consistent state: if an environment file, hints file, or loader(8) environment are provided, we use them in a well-known order of precedence:
- loader(8) environment - static environment - static hints file
Once the dynamic environment is setup this becomes a moot point. The loader(8) and static environments are merged (respecting the above order of precedence), and the static hints are merged in on an as-needed basis after the dynamic environment has been setup.
Hints lookup are changed to respect all of the above. Before the dynamic environment is setup, lookups use the above-mentioned order and fallback to the next environment if a matching hint is not found. Once the dynamic environment is setup, that is used on its own since it captures all of the above information plus any dynamic kenv settings that came up later in boot.
The following tangentially related changes were made to res_find:
- A hintp cookie is now passed in so that related searches continue using the chain of environments (or dynamic environment) without relying on global state - All three environments will be searched if they actually have valid hints to use, rather than just choosing the first environment that actually had a hint and rolling with that only
The hintmode sysctl has been ripped out. static_{env,hints}.disabled are still honored and will disable their respective environments from being used for hint lookups and from being merged into the dynamic environment, as expected.
r336019: config(8): De-dupe hint/env vars within a single file
r335653 flipped the order in which hints/env files are concatenated to match the order in which vars are processed by the kernel. This is the other hammer to drop.
Use nv(9) to de-dupe entries within a single `hint` or `env` file, using the latest value specified for a key. This leaves some duplicates if a variable is specified in multiple hint/env files or via `envvar` in a kernel config, but the reversed order of concatenation (from r335653) makes this a non-issue as the latest-specified version will be seen first.
This change also silently rewrote hint bits to use the same sanitization process that ian@ wrote for r335642. To the kernel, hints and env vars are basically the same thing through early boot, then get merged into the dynamic environment once kmem becomes available and the dynamic environment is created. They should be subjected to the same restrictions.
libnv has been added to -legacy for the time being to support the build of config(8) with the new cnvlist API.
r336026: config(8): Fix broken ABI
r336019 introduced ${SRCTOP}/sys to the include paths in order to pull in a new sys/{c,}nv.h. This is wrong, because the build tree's ABI isn't guaranteed to match what's running on the host system.
Fix instead by removing -I${SRCTOP}/sys and installing the libnv headers with `make -C lib/libnv includes`... this may or may not get re-worked in the future so that a userland lib isn't installing includes from sys/.
r336036: kern_environment: Fix SYSINIT ordering
The dynamic environment was being initialized at SI_SUB_KMEM, SI_ORDER_ANY. I added the hint-merging at SI_SUB_KMEM, SI_ORDER_ANY as well in r335998 - this can only work by coincidence.
Re-do both to operate at SI_SUB_KMEM + 1, SI_ORDER_FIRST and SI_ORDER_SECOND respectively to be safe. It's sufficiently obfuscated away as to when in SU_SUB_KMEM malloc will be available, and the dynamic environment cannot be relied upon there anyways since it's initialized at SI_ORDER_ANY.
r336217: kern_environment: Give the static environment a chance to disable MD env
This variable has been given the name "loader_env.disabled" as it's the primary way most people will have an MD environment. This restores the previously-default behavior of ignoring the loader(8) environment, which may be useful for vendor distributions or other scenarios where inheriting the loader environment may be considered a security issue or potentially breaking of a more locked-down environment.
As the change to config(5) indicates, disabling the loader environment should not be a choice made lightly since it may provide ACPI hints and other useful things that the system can rely on to boot.
An UPDATING entry has been added to mention an upgrade path for those that may have relied on the previous behavior.
r336335 by arichardson: No longer install sys/nv.h and sys/cnv.h in lib/libnv/Makefile
Use tools/build/Makefile to install the headers into ${WORLDTMP}/legacy instead. Compared to r336026 this has the minor advantage that it avoids unncessary header installation when building the non-bootstrap libnv.
r336337: Unconditionally build libnv in legacy
Rather than using a config(8) built from new tree linking libnv built on host.
r336415: config(8): Add compatibility shims for r335998
Plumb the %VERSREQ from Makefile.<arch> through to the rest of config(8). We've recorded the config(8) version that we're calling "the end of envmode and hintmode," and we'll write them out for earlier versions. Later kernel version bumps will remove envmode/hintmode from the kernel as needed, which is OK since the current kernel does not use them at all.
These compatibility shims really need to go away when the major version rolls over...
r336416: Fix GCC 4.2 build after r336415, proper declaration and prototype
r336419: config(8): Invert checks; envmode/hintmode reflect "env provided"
Relnotes: yes (maybe) [The loader environment may now be used with the config-static environment by specifying loader_env.disabled=0 in the config-static environment]
|
#
335992 |
|
05-Jul-2018 |
ian |
MFC r335283:
Build LOCAL_LIB_DIRS along with system lib dirs, rather than building them in parallel with LOCAL_DIRS and all the other system post-libs stuff.
|
#
335825 |
|
30-Jun-2018 |
kib |
MFC r335253: Rework ofed build.
Sponsored by: Mellanox Technologies
|
#
332802 |
|
20-Apr-2018 |
gjb |
Update stable/11 from 11.1-STABLE to 11.2-PRERELEASE, marking the official start of the code slush.
Set the default mdoc(7) version to 11.2, and update the clang(1) TARGET_TRIPLE to reflect 11.2. While here, add missing FreeBSD major versions to mdoc(7).
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
|
#
332301 |
|
08-Apr-2018 |
emaste |
MFC r328972: add retpoline compiler and linker feature flags
These features indicate that the compiler and linker support the retpoline speculative execution vulnerability (CVE-2017-5715) mitigation.
|
#
331769 |
|
30-Mar-2018 |
hselasky |
MFC r303505, r303506, r303512, r303513, r303646, r320418, r323082, r326169, r326563, r326649, r326716, r326764, r326765 and r329222:
RoCE/infiniband/iWarp upgrade to Linux 4.9 for kernel and userspace. This commit merges projects/bsd_rdma_4_9 to 11-stable.
Compatibility wrappers have been made for existing 11-stable ibcore APIs, including ib_reg_phys_mr(). Refer to "sys/ofed/include/rdma/ib_verbs_compat.h" for more information.
The iw_cxgb driver has not been updated and has been disconnected from the build.
Sponsored by: Mellanox Technologies
MFC r326169 and r326563: RoCE/infiniband upgrade to Linux v4.9 for kernel and userspace.
List of kernel sources used: ============================
1) kernel sources were cloned from git://github.com/torvalds/linux.git Top commit 69973b830859bc6529a7a0468ba0d80ee5117826 - tag: v4.9, linux-4.9
2) krping was cloned from https://github.com/larrystevenwise/krping Top commit 292a2f1abf0348285e678a82264740d52e4dcfe4
List of userspace sources used: ===============================
1) rdma-core was cloned from https://github.com/linux-rdma/rdma-core.git Top commit d65138ef93af30b3ea249f3a84aa6a24ba7f8a75
2) OpenSM was cloned from git://git.openfabrics.org/~halr/opensm.git Top commit 85f841cf209f791c89a075048a907020e924528d
3) libibmad was cloned from git://git.openfabrics.org/~iraweiny/libibmad.git Tag 1.3.13 with some additional patches from Mellanox.
4) infiniband-diags was cloned from git://git.openfabrics.org/~iraweiny/infiniband-diags.git Tag 1.6.7 with some additional patches from Mellanox.
NOTES: ======
1) The mthca driver has been removed from userspace. 2) All GPLv2 only sources have been removed and where applicable rewritten from scratch under a BSD license. 3) List of fully supported drivers in userspace and kernel: a) iw_cxgbe (Chelsio) b) mlx4ib (Mellanox) c) mlx5ib (Mellanox) 4) WITH_OFED=YES is still required by make in order to build OFED userspace and kernel code. 5) Full support has been added for routable RoCE, RoCE v2.
MFC r326649: Disconnect OFED after r326169 broke all DIRDEPS support for it.
MFC r326716: Correctly define the unordered_map namespace in ofed/libibnetdisc .
This should fix ofed/libibnetdisc compilation with C-compilers different from clang and GCC v4.2.1.
Submitted by: kib Sponsored by: Mellanox Technologies
MFC r326764: ofed: Remove duplicated symbols from the version file.
ld.bfd accepts multiple listing of the same symbol in the version script. lld is stricter and errors out. Since arm64 and sometimes amd64 use lld, we should correct this cosmetic issue.
Sponsored by: Mellanox Technologies Reviewed by: hselasky Differential revision: https://reviews.freebsd.org/D13329
MFC r326765: ofed: Define barriers for mips and arm.
I used the strongest barriers available on the architectures, so if the future analysis show that it is excessive, the barriers could be relaxed. Still, it is unlikely that it is meaningful to run IB on 32bit ARM or current MIPS machines, so the change is to make WITH_OFED to pass tinderbox.
Sponsored by: Mellanox Technologies Reviewed by: hselasky Differential revision: https://reviews.freebsd.org/D13329
MFC r303505: sdp: Use an mbufq for received control packets.
This is simpler than the hand-rolled queue, and fixes a use-after-free.
Sponsored by: EMC / Isilon Storage Division
MFC r303506: sdp: Destroy the PCB lock before freeing to the zone.
Sponsored by: EMC / Isilon Storage Division
MFC r303512: sdp: Use malloc(9) instead of the Linux compat layer.
SDP transmit and receive rings are always created in a sleepable context, so we can use M_WAITOK and remove error checks.
Sponsored by: EMC / Isilon Storage Division
MFC r303513: sdp: Destroy the RDMA ID after destroying the connection's queue pair.
This is the ordering documented by rdma_destroy_qp(). Also add a useful KASSERT to sdp_pcbfree().
Sponsored by: EMC / Isilon Storage Division
MFC r303646: ipoib: Bound the number of egress mbufs buffered during pathrec lookups.
In pathological situations where the master subnet manager becomes unresponsive for an extended period, we may otherwise end up queuing all of the system's mbufs while waiting for a response to a path record lookup.
This addresses the same issue as commit 1e85b806f9 in Linux.
Reviewed by: cem, ngie Sponsored by: EMC / Isilon Storage Division
MFC r329222: Import the mthca kernel side infiniband driver from Linux 4.9 and fix compilation under FreeBSD. The mthca driver was temporarily removed as part of the Linux 4.9 RoCE/infinband upgrade.
Top commit in Linux source tree: 69973b830859bc6529a7a0468ba0d80ee5117826
Sponsored by: Mellanox Technologies
MFC r320418. Note that the socket lock _is_ the same as so_rcv's lock in 11 and this is a no-op in this branch.
Sponsored by: Chelsio Communications
MFC r323082: cxgbe/iw_cxgbe: Set TCP_NODELAY before initiating connection so that t4_tom picks it up right away. This is less work than waiting for the connection to be established before applying the setting.
Sponsored by: Chelsio Communications
|
#
331730 |
|
29-Mar-2018 |
emaste |
MFC kernel build-id support
MFC r320244, r320245, r320246, r320247, r320248, r320249, r320250 (bdrewery):
Add basic bsd.linker.mk auto included from bsd.compiler.mk. This will provide LINKER_TYPE and LINKER_VERSION.
Support XLD for setting X_LINKER_TYPE and X_LINKER_VERSION. This is similar to r300350 for bsd.compiler.mk.
Support cached linker values in environment. This is similar to r289659 for bsd.compiler.mk.
LINKER_VERSION: Support external binutils. The ports binutils stores the version in the 5th word so just look for a version using a pattern instead.
Don't overwrite already-set LINKER_VERSION/LINKER_TYPE.
Provide proper values for X_LINKER_TYPE/VERSION when XLD == LD.
Pass along LINKER_* vars during installworld and show in test-system-compiler.
MFC r320258, r320272, r320275, r320502 (emaste):
change GNU ld LINKER_TYPE from binutils to bfd
GNU binutils includes two linkers: ld.bfd and ld.gold. For clarity use LINKER_TYPE=bfd to refer to ld.bfd, the original binutils linker that identifies itself as "GNU ld".
bsd.linker.mk: add band-aid for linker invocation failure
In some cases bsd.linker.mk reports an error like:
make[4]: ".../share/mk/bsd.linker.mk" line 56: Unknown linker from LD=ld -m elf32ppc_fbsd:"
For now change this to a .warning, and then assume GNU ld 2.17.50. At present the linker type detection is used only for enabling build-id, and we can carry on without it when type detection fails.
Also, show errors from ${LD} --version to aid in failure diagnosis. Successful invocations of ${LD} --version produce no output on stderr so this will not create any spam in non-failing builds.
enable --build-id for the kernel link
A Build-ID is an identifier generated at link time to uniquely identify ELF binaries. It allows efficient confirmation that an executable or shared library and a corresponding standalone debuginfo file match. (Otherwise, a checksum of the debuginfo file must be calculated when opening it in a debugger.)
The FreeBSD base system includes GNU bfd ld 2.17.50 as the linker for architectures other than arm64. Build-ID support was added to bfd ld shortly after that version, so was not previously available to us.
We can now start making use of Build-ID as we migrate to using lld or bfd ld from ports, conditionally enabled based on the LINKER_TYPE and LINKER_VERSION make variables added in r320244 and subsequent commits.
Introduce LINKER_FEATURES to avoid duplicating version logic
MFC r327857 (bdrewery, submitted by Dan McGregor): Cache LINKER_FEATURES to fix the wrong ones being used.
Sponsored by: Dell EMC Isilon Sponsored by: The FreeBSD Foundation
|
#
331308 |
|
21-Mar-2018 |
kevans |
MFC r330929: pkgbase: Fix post-install script for kernel packages
kernel.ucl uses a hardcoded boot/kernel for kldxref, which is the incorrect directory when we're installing extra kernels that aren't the "default" kernel (placed at boot/kernel).
Fix this by instead using a new %KERNELDIR% that we now replace in Makefile.inc1 with "kernel" for the default kernel and "kernel.${_kernel}" for these extra kernels so that, e.g. /boot/kernel.SHIVA, will get properly kldxref'd upon update and avoid outdated linker.hints.
|
#
329145 |
|
12-Feb-2018 |
kevans |
MFC r325834,r325997,326502: Move sys/boot to stand/
This is effectively a direct commit to stable/11, due to differences between stable/11 and head. Changes to DTS in sys/boot/fdt/dts were often accompanied by kernel changes. Many of these were also risc-v updates that likely had many more dependencies to MFC.
Because of this, sys/boot/fdt/dts remains as-is while everything else in sys/boot relocates to stand/.
r325834: Move sys/boot to stand. Fix all references to new location
r325997: Remove empty directories.
r326502: Document the sys/boot -> stand move in hier.7 and the top-level README.
|
#
328929 |
|
06-Feb-2018 |
kevans |
MFC r325116,r325515: Stop masking errors during buildenv
MFC r325116(imp): Return proper status from buildenv.
make buildenv BUILDENV_SHELL=<some command> more useful. Remove '|| true' from the command line so that errors are properly returned. There appears to be no reason for it, and it dates back to the original commit by ru@.
MFC r325515 (imp): Note interactive shell errors for make buildenv and add a warning for people tempted to add back the || true to get rid of them.
|
#
327663 |
|
07-Jan-2018 |
ian |
MFC r327439:
Allow use of .WAIT in the LOCAL_DIRS and LOCAL_LIB_DIRS lists.
A comment in Makefile.inc1 has long stated that LOCAL_DIRS are built last, after the base system. Incremental improvements in parallel building over the years have led to LOCAL_DIRS being built in parallel with base system directories. This change allows the .WAIT directive to appear in LOCAL_DIRS and LOCAL_LIB_DIRS lists to give the user some control over parallel building of local additions.
Differential Revision: https://reviews.freebsd.org/D13622
|
#
326833 |
|
13-Dec-2017 |
cy |
MFC r324248:
hen building multiple kernels using KERNCONF, non-existent KERNCONF files will produce an error and buildkernel will fail. Previously missing KERNCONF files silently failed giving no indication as to why, only to subsequently discover during installkernel that the desired kernel was never built in the first place.
This is a rework of r302865.
This is the correct patch.
Reviewed by: ngie (previous version, r302865) Differential Revision: https://reviews.freebsd.org/D7167
|
#
325808 |
|
14-Nov-2017 |
gjb |
MFC r322401: Avoid creating kernel-dbg.txz distribution sets and kernel-debug packages when MK_DEBUG_FILES is 'no'.
Differential Revision: https://reviews.freebsd.org/D12544 (related) Sponsored by: The FreeBSD Foundation
|
#
324133 |
|
30-Sep-2017 |
ngie |
MFC r322951:
Respect MK_TCSH with build-tools and native-xtools
This helps reduce the WORLDTMP footprint slightly.
Based on a patch I submitted 5 years ago to GNATS.
PR: 174051 Relnotes: yes (anyone who cross-builds with MK_TCSH=yes will run into build failures if the host doesn't have tcsh(1)) Reminded by: Fabian Keil <fk@fabiankeil.de>
|
#
323461 |
|
11-Sep-2017 |
ian |
MFC r321876:
In xdev-links, when installing symlinks to the cross-compiler pieces that includes the OS version (armv6-freebsd12.0-cc, etc), use the OS version of the compiler/world source code, not the version of the build host machine.
|
#
322433 |
|
12-Aug-2017 |
dim |
MFC r321684:
Don't use libc++ when cross-building for gcc arches
Since we imported clang 5.0.0, the version check in Makefile.inc1 which checks whether to use libc++ fires even when the compiler for the target architecture is gcc 4.2.1. This is because only X_COMPILER_VERSION is checked. Also check X_COMPILER_TYPE, so it will only use libc++ when an external gcc toolchain is used.
Reviewed by: emaste, rpokala Differential Revision: https://reviews.freebsd.org/D11776
MFC r322170:
Follow-up to r321684 (Don't use libc++ when cross-building for gcc arches), and handle two more cases where libc++ includes could be incorrectly enabled, in case the host compiler is clang 5.0.0, and the target (cross) compiler is gcc 4.2.1.
Noted by: bdrewery
|
#
321339 |
|
21-Jul-2017 |
bdrewery |
MFC r320292:
NO_ROOT: Remove excessive // when DESTDIR/DISTDIR are empty.
|
#
321337 |
|
21-Jul-2017 |
bdrewery |
MFC r320806:
SYSTEM_COMPILER: Ensure there is not a stale compiler in WORLDTMP.
|
#
321053 |
|
16-Jul-2017 |
emaste |
MFC r319219: add a sanity check before installworld on the running system
FreeBSD does not guarantee kernel forward compatibility (that is, running a newer userland on an older kernel). The documented upgrade procedure specifies that installkernel should be performed, followed by a reboot and then installworld. As a sanity check when installing onto the running system (DESTDIR is / or unset), attempt to run "sh echo OK" using rescue from the objdir. If rescue fails (e.g., because the system has not been rebooted and the "old" kernel lacks a system call required by the to-be-installed world), abort the installation.
This was added to avoid ino64 foot-shooting in HEAD, but is generally useful for any upgrade case adding new syscalls.
Sponsored by: The FreeBSD Foundation
|
#
319192 |
|
30-May-2017 |
ngie |
MFC r306375,r307802:
r306375 (by emaste):
Add a WITHOUT_DIALOG src.conf(5) knob
It also turns off dependencies (bsdinstall, bsdconfig, dpv, tzsetup).
r307802 (by bapt):
Fix build of tzsetup when WITHOUT_DIALOG is set
Hide dialog specific code behind HAVE_DIALOG. It allows to build a stripped down version (missing the dialog UI) but perfectly function tzsetup when world is built WITHOUT_DIALOG
Reorganise a bit the code to limit the number of blocks under HAVE_DIALOG
|
#
319024 |
|
28-May-2017 |
ngie |
MFC r309412,r316109,r316132:
r309412 (by imp):
dd is currently a bootstrap tool. It really doesn't have any business being a bootstrap tool. However, for reproducible build output, FreeBSD added dd status=none because it was otherwise difficult to suppress the status information, but retain any errors that might happen. There's no real reason that dd has to be a build tool, other than we use status=none unconditional. Remove dd from a bootstrap tool entirely by only using status=none when available. This may also help efforts to build the system on non-FreeBSD hosts as well.
r316109:
Don't hardcode input files for stage 1/2 bootloaders; use .ALLSRC instead
This is a better pattern to follow when creating the bootloaders and doing the relevant space checks to make sure that the sizes aren't exceeded (and thus, copy-pasting is a bit less error prone).
r316132:
Parameterize out 7680 (15 * 512) as BOOT2SIZE, similar to sys/boot/i386/zfsboot/...
This is being done to make it easier to change in the future--this action might be needed sooner rather than later because of gcc 6.3.0 bailing, stating that there is negative free space left (deficit) in the boot2 bootloader.
|
#
318507 |
|
19-May-2017 |
gjb |
Update stable/11 from 11.0-STABLE to 11.1-PRERELEASE, marking the official start of the code slush.
Set the default mdoc(7) version to 11.1, and update the clang(1) TARGET_TRIPLE to reflect 11.1. While here, add missing FreeBSD major versions to mdoc(7).
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
|
#
318472 |
|
18-May-2017 |
emaste |
MFC LLD changes and enable LLD as /usr/bin/ld on arm64 by default
MFC r316629: do not require binutils port when using lld as ld
r279908 added logic to Makefile.inc1 to automatically set CROSS_BINUTILS_PREFIX for architectures not supported by the in-tree binutils: arm64 when first introduced, and later riscv64 as well.
LLVM's LLD linker is now included in the base system, and is enabled by default for arm64 and capable of linking world and kernel. Thus, avoid automatically setting CROSS_BINUTILS_PREFIX and requiring the binutils port if WITH_LLD_IS_LD is true.
--
MFC r317608: revert r313473 (Disable LLD_IS_LD option combinations that fail)
r316647 corrected the build of tblgen and libllvm as dependencies for LLD so undo the temporary seat-belt.
We still want to extend the build infrastructure to automatically detect the case where the host LLD can be used instead of building a bootstrap LLD, and likely extend libllvmminimal to meet LLD's needs for cases where the build includes LLD but not Clang.
--
MFC r316684: Make WITHOUT_TOOLCHAIN imply WITHOUT_LLD.
LLD is a toolchain component.
--
MFC r316647: Introduce LLD_BOOTSTRAP to control lld as bootstrap linker
Add WITH_LLD_BOOTSTRAP and WITHOUT_LLD_BOOTSTRAP knobs, similar to the Clang bootstrap knobs.
Reviewed by: andrew Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D10793
|
#
317565 |
|
28-Apr-2017 |
bdrewery |
MFC r316794:
Cache compiler metadata and reuse it at installworld time.
|
#
317564 |
|
28-Apr-2017 |
bdrewery |
MFC r316780:
Pass COMPILER_FEATURES down to submakes for installworld.
|
#
317562 |
|
28-Apr-2017 |
bdrewery |
MFC r316586:
META_MODE: Fix build-tools still sometimes rebuilding during target build.
|
#
317260 |
|
21-Apr-2017 |
gjb |
MFC r317100: Use relative symlink for 'latest' to allow repo to work after being moved.
PR: 217197 Sponsored by: The FreeBSD Foundation
|
#
317259 |
|
21-Apr-2017 |
gjb |
MFC r310181 (matthew) (originally r309314): Allow a user-overridable setting 'PKG_CMD' to control the command used to create a repo during 'make packages'.
Sponsored by: The FreeBSD Foundation
|
#
316786 |
|
13-Apr-2017 |
bdrewery |
MFC r315691:
Rename _cc to _gcc to be more clear.
|
#
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
|
#
316420 |
|
02-Apr-2017 |
bapt |
RFC: 312593, 313958
Update mandoc to 1.14
|
#
315724 |
|
22-Mar-2017 |
bdrewery |
MFC r314709,r314790,r314794:
r314709: Fix bootstrapping mtree after r313404 for older systems. r314790: Added comments for why nmtree/libmd are bootstrapped. r314794: Fix bootstrapping libmd on older systems after r314709.
PR: 217673
|
#
314635 |
|
03-Mar-2017 |
bdrewery |
MFC r313907:
xdev: Fix after libc++ update in r300873.
|
#
314633 |
|
03-Mar-2017 |
bdrewery |
MFC r313905:
xdev: Build yacc which is needed for recent libpcap updates.
|
#
314630 |
|
03-Mar-2017 |
bdrewery |
MFC r313904:
META_MODE+xdev: Don't rebuild build-tools during normal build.
|
#
314629 |
|
03-Mar-2017 |
bdrewery |
MFC r313163:
native-xtools: Add missing readelf.
|
#
314628 |
|
03-Mar-2017 |
bdrewery |
MFC r313184:
Remove LOCAL_LIB_DIRS warning added in r275839.
|
#
314235 |
|
25-Feb-2017 |
ngie |
MFC r313924,r313925:
r313924:
Quote path to doxygen/kyua in test(1) -x check
This is a basic stopgap against ${LOCALBASE} containing spaces in it
r313925:
Include ${LOCALBASE}/bin in $PATH when running "make checkworld"
Some of the tests in devel/atf // devel/kyua rely on the tools being in $PATH, which means that the tests fail when run via "make checkworld" because $PATH is restricted to exclude directory elements like "${LOCALBASE}/bin".
|
#
313380 |
|
07-Feb-2017 |
ngie |
MFC r313182:
Fix typo in variable name (_REDUNDENT_LIB_DIRS -> _REDUNDANT_LIB_DIRS)
|
#
312268 |
|
16-Jan-2017 |
ngie |
MFC r311140:
Only bake krb5_config.h support in to ssh(3), etc if both MK_GSSAPI and MK_KERBEROS_SUPPORT != no
This fixes the odd case where someone specified MK_GSSAPI=no and MK_KERBEROS_SUPPORT=yes (which admittedly, probably doesn't make sense, but the build system doesn't prevent this case today, and it didn't when I filed the bug back in 2011 either).
PR: 159745
|
#
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.
|
#
311558 |
|
06-Jan-2017 |
dim |
MFC r311131:
Make native-xtools build correctly after clang/llvm 3.9.0 import
During the clang/llvm 3.9.0 import, the build structure for it was completely revamped. This broke the native-xtools target.
It first attempts to build libllvmminimal, then the llvm-tblgen and clang-tblgen executables, but these fail to link because they are linked to the 'full' libllvm by default, as they normally are during the 'world' stage.
To make these link against libllvmminimal instead, define TOOLS_PREFIX, similarly as during the bootstrap-tools phase. The value itself is empty, as we don't really want to use a prefix.
Reviewed by: imp PR: 215684 Differential Revision: https://reviews.freebsd.org/D9026
|
#
311198 |
|
03-Jan-2017 |
bdrewery |
Revert MFC of r308603.
This depends on unmerged r307538 still.
|
#
311197 |
|
03-Jan-2017 |
bdrewery |
MFC r308603:
Move libsysdecode-specific hack out of buildworld.
|
#
311186 |
|
03-Jan-2017 |
bdrewery |
MFC r305256:
Bump __FreeBSD_version for crunchgen META_MODE fix in r311185.
|
#
310618 |
|
26-Dec-2016 |
dim |
MFC r309124:
Upgrade our copies of clang, llvm, lldb, compiler-rt and libc++ to 3.9.0 release, and add lld 3.9.0. Also completely revamp the build system for clang, llvm, lldb and their related tools.
Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11 support to build; see UPDATING for more information.
Release notes for llvm, clang and lld are available here: <http://llvm.org/releases/3.9.0/docs/ReleaseNotes.html> <http://llvm.org/releases/3.9.0/tools/clang/docs/ReleaseNotes.html> <http://llvm.org/releases/3.9.0/tools/lld/docs/ReleaseNotes.html>
Thanks to Ed Maste, Bryan Drewery, Andrew Turner, Antoine Brodin and Jan Beich for their help.
Relnotes: yes
MFC r309147:
Pull in r282174 from upstream llvm trunk (by Krzysztof Parzyszek):
[PPC] Set SP after loading data from stack frame, if no red zone is present
Follow-up to r280705: Make sure that the SP is only restored after all data is loaded from the stack frame, if there is no red zone.
This completes the fix for https://llvm.org/bugs/show_bug.cgi?id=26519.
Differential Revision: https://reviews.llvm.org/D24466
Reported by: Mark Millard PR: 214433
MFC r309149:
Pull in r283060 from upstream llvm trunk (by Hal Finkel):
[PowerPC] Refactor soft-float support, and enable PPC64 soft float
This change enables soft-float for PowerPC64, and also makes soft-float disable all vector instruction sets for both 32-bit and 64-bit modes. This latter part is necessary because the PPC backend canonicalizes many Altivec vector types to floating-point types, and so soft-float breaks scalarization support for many operations. Both for embedded targets and for operating-system kernels desiring soft-float support, it seems reasonable that disabling hardware floating-point also disables vector instructions (embedded targets without hardware floating point support are unlikely to have Altivec, etc. and operating system kernels desiring not to use floating-point registers to lower syscall cost are unlikely to want to use vector registers either). If someone needs this to work, we'll need to change the fact that we promote many Altivec operations to act on v4f32. To make it possible to disable Altivec when soft-float is enabled, hardware floating-point support needs to be expressed as a positive feature, like the others, and not a negative feature, because target features cannot have dependencies on the disabling of some other feature. So +soft-float has now become -hard-float.
Fixes PR26970.
Pull in r283061 from upstream clang trunk (by Hal Finkel):
[PowerPC] Enable soft-float for PPC64, and +soft-float -> -hard-float
Enable soft-float support on PPC64, as the backend now supports it. Also, the backend now uses -hard-float instead of +soft-float, so set the target features accordingly.
Fixes PR26970.
Reported by: Mark Millard PR: 214433
MFC r309212:
Add a few missed clang 3.9.0 files to OptionalObsoleteFiles.
MFC r309262:
Fix packaging for clang, lldb and lld 3.9.0
During the upgrade of clang/llvm etc to 3.9.0 in r309124, the PACKAGE directive in the usr.bin/clang/*.mk files got dropped accidentally.
Restore it, with a few minor changes and additions: * Correct license in clang.ucl to NCSA * Add PACKAGE=clang for clang and most of the "ll" tools * Put lldb in its own package * Put lld in its own package
Reviewed by: gjb, jmallett Differential Revision: https://reviews.freebsd.org/D8666
MFC r309656:
During the bootstrap phase, when building the minimal llvm library on PowerPC, add lib/Support/Atomic.cpp. This is needed because upstream llvm revision r271821 disabled the use of std::call_once, which causes some fallback functions from Atomic.cpp to be used instead.
Reported by: Mark Millard PR: 214902
MFC r309835:
Tentatively apply https://reviews.llvm.org/D18730 to work around gcc PR 70528 (bogus error: constructor required before non-static data member). This should fix buildworld with the external gcc package.
Reported by: https://jenkins.freebsd.org/job/FreeBSD_HEAD_amd64_gcc/
MFC r310194:
Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 3.9.1 release.
Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11 support to build; see UPDATING for more information.
Release notes for llvm, clang and lld will be available here: <http://releases.llvm.org/3.9.1/docs/ReleaseNotes.html> <http://releases.llvm.org/3.9.1/tools/clang/docs/ReleaseNotes.html> <http://releases.llvm.org/3.9.1/tools/lld/docs/ReleaseNotes.html>
Relnotes: yes
|
#
309605 |
|
06-Dec-2016 |
dim |
MFC r309332:
Cleanup old debug dirs in delete-old-dirs target
Any .debug or .symbols files under /usr/lib/debug which correspond to OLD_FILES entries in ObsoleteFiles.inc are also automatically cleaned up by the delete-old target. Make this also apply to any OLD_DIRS entries.
Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D8683
|
#
307770 |
|
22-Oct-2016 |
bapt |
MFC: 306864,307648
Groff is needed only if MK_GROFF and MK_SHAREDOCS are both true.
|
#
304475 |
|
19-Aug-2016 |
bdrewery |
MFC r304217:
Trim unneeded bootstrap after r301470 made 9.1 the minimum supported release.
|
#
304472 |
|
19-Aug-2016 |
bdrewery |
MFC r304006:
Avoid showing the bootstrap make command for check-old, etc.
|
#
304296 |
|
17-Aug-2016 |
lwhsu |
MFC 303935
Only remove empty directories before packaging.
This preserves files are intentionally empty, most of them are in tests.txz
Reviewed by: bdrewery
|
#
303360 |
|
27-Jul-2016 |
bdrewery |
MFC r303274:
Don't disable binutils/elftoolchain bootstrapping with external compiler.
Approved by: re (kib)
|
#
303359 |
|
27-Jul-2016 |
bdrewery |
MFC r303272,r303273:
r303272: SYSTEM_COMPILER: Rework the logic to allow a 'make test-system-compiler'. r303273: Fix empty WANT_COMPILER_TYPE when neither compiler is bootstrapped.
Approved by: re (kib)
|
#
303337 |
|
26-Jul-2016 |
emaste |
MFC r303034: Include makewhatis in ITOOLS when MK_MAN_UTILS is true
Previously it was conditional on MK_MAN. It's possible to build FreeBSD with man pages but without man page tools. MK_MAN_UTILS is the conditional used in share/man/Makefile for determining whether makewhatis is executed at install time, so it is the proper one for ITOOLS as well.
PR: 210142 Approved by: re (gjb)
|