config.h as a guide. In practice contributed software maintains a copy
of config.h within its build directory tree containing its Makefile.
usr.sbin/unbound is the home for its config.h.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D22983
The patch is untested and is almost certainly insufficient. Per the
author's request, revert until someone with access to sparc64 hardware
can test and report.
sparc64 is the only architecture currently using the DWARF unwinder from
GCC 4.2.1. Old GCC and related libraries are being removed soon; absent
other changes sparc64 would be left with no unwinder when that happens.
Instead, commit these changes which should at least allow the LLVM
unwinder to build. Someone with access to the obolete sparc64 hardware
supported by FreeBSD will need to test the result.
PR: 233405
Submitted by: cem
[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 after: 1 week
X-MFC-With: r353358
[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 after: 1 week
X-MFC-With: r353358
[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 after: 1 week
X-MFC-With: r353358
[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 after: 1 week
X-MFC-With: r353358
[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 after: 1 week
X-MFC-With: r353358
[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 after: 1 week
Update libarchive to 3.4.1
Relevant vendor changes since last update:
Issue #351: Refactor and implement private state logic for write filters
PR #1252: RAR5 reader - verify window size for solid files (OSS-Fuzz 15482)
PR #1255: zip writer - don't append unused NUL for directories
PR #1260: Fix sparse file offset overflow on 32-bit systems
PR #1263: UNICODE filename support for reading lha/lzh format
Issue #1276: Bugfix and optimize archive_wstring_append_from_mbs()
PR #1288: Add the "xattrhdr" option to pax write options
PR #1295: 7z reader - fix reading archives with digests in PackInfo
PR #1296: RAR5 reader - verify window size for multivolume archives
PR #1297: ZIP reader - support LZMA_STREAM_END marker in 'lzma alone' files
Issue #1298: Fix a heap-buffer-overflow in archive_string_append_from_wcs()
OSS-Fuzz 19360, 19362: LHA reader - plug two memory leaks on error
Fix possible off-by-one when dealing with readlink(2)
MFC after: 2 weeks
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
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
[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
[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 after: 3 days
Fix libpcap issue #893: check for invalid IPv4 addresses.
This fixes errors such as:
tcpdump -i lagg0 net 999.999.999.999
This was originally discovered on a Red Hat 7.7 server and verified
to also be a bug on FreeBSD.
Obtained from: https://github.com/the-tcpdump-group/libpcap/commit/ \
07070918d5e81a515315b395f334e52589fe0fb
Fixed by: https://github.com/guyharris
MFC after: 2 weeks
Pick 2d6d099fed05b1509e81e54458516528bfbbf38d from upstream jemalloc:
Fix GCC-9.1 warning with macro GET_ARG_NUMERIC
GCC-9.1 reports following error when trying to compile file
src/malloc_io.c and with CFLAGS='-Werror' :
src/malloc_io.c: In function ‘malloc_vsnprintf’:
src/malloc_io.c:369:2: error: case label value exceeds maximum value for type [-Werror]
369 | case '?' | 0x80: \
| ^~~~
src/malloc_io.c:581:5: note: in expansion of macro ‘GET_ARG_NUMERIC’
581 | GET_ARG_NUMERIC(val, 'p');
| ^~~~~~~~~~~~~~~
...
<snip>
cc1: all warnings being treated as errors
make: *** [Makefile:388: src/malloc_io.sym.o] Error 1
The warning is reported as by default the type 'char' is 'signed char'
and or-ing 0x80 will turn the case label char negative which will be
beyond the printable ascii range (0 - 127).
The patch fixes this by explicitly casting the 'len' variable as
unsigned char' inside the 'switch' statement so that value of
expression " '?' | 0x80 " falls within the legal values of the
variable 'len'.
Discussed with: jasone (maintainer)
Sponsored by: Dell EMC Isilon
This uses the new layout of the upstream repository, which was recently
migrated to GitHub, and converted into a "monorepo". That is, most of
the earlier separate sub-projects with their own branches and tags were
consolidated into one top-level directory, and are now branched and
tagged together.
Updating the vendor area to match this layout is next.
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
statistics obtained with stats(3) in JSON format to standard error.
Reviewed by: allanjude, thj, cem (earlier version)
Tested by: thj
MFC after: 2 weeks
Relnotes: yes
Sponsored by: Klara Inc.
Differential Revision: https://reviews.freebsd.org/D21324
I'm pretty skeptical that any crypto in telnet is worth using, but if we're
ostensibly generating keys, arc4random is strictly better than the previous
construct.
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
[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 after: 1 month
X-MFC-With: r353358
The bogus use could lead to an infinite loop depending on how fast the
audit_warn script to execute.
By fixing read(2) interruptibility, d060887 (r335899) revealed another bug
in auditd_wait_for_events. When read is interrupted by SIGCHLD,
auditd_reap_children will always return with errno set to ECHILD. But
auditd_wait_for_events checks errno after that point, expecting it to be
unchanged since read. As a result, it calls auditd_handle_trigger with bogus
stack garbage. The result is the error message "Got unknown trigger 48." Fix
by simply ignoring errno at that point; there's only one value it could've
possibly had, thanks to the check up above.
The best part is we've had a fix for this for like 18 months and just never
merged it. Merge it now.
PR: 234209
Reported by: Marie Helene Kvello-Aune <freebsd AT mhka.no> (2018-12)
Submitted by: asomers (2018-07)
Reviewed by: me (in OpenBSM)
Obtained from: OpenBSM
X-MFC-With: r335899
Security: ¯\_(ツ)_/¯
Differential Revision: https://github.com/openbsm/openbsm/pull/45
Clarify the deprecation notice in amd.8. amd will be removed from the
FreeBSD base system before FreeBSD 13.0.
Reviewed by: rgrimes, trasz, kevans, brooks (all earlier, in D22466)
Discussed with: cy
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
[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 after: 1 month
X-MFC-With: r353358
[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 after: 1 month
X-MFC-With: r353358
[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 after: 1 month
X-MFC-With: r353358
[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 after: 1 month
X-MFC-With: r353358
[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 after: 1 month
X-MFC-With: r353358
[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 after: 1 month
X-MFC-With: r353358
[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 after: 1 month
X-MFC-With: r353358
This reapplies the RISC-V GNU ld workaround from r354896, r354899, and
354900, along with a fix for the build failure during cleandir.
LINKER_TYPE was not being set during cleandir, resulting in
Malformed conditional (${LINKER_TYPE} == "bfd" && ${MACHINE} == "riscv")
from Cirrus-CI.
PR: 242109
Sponsored by: The FreeBSD Foundation
