In contrast to Linux it does not provide entries which can be readlinked
-- these are just regular files, not giving the expected outcome. That's
on top of procfs not being mounted by default to begin with.
Reviewed by: dim
Differential Revision: https://reviews.freebsd.org/D34684
Bugfixes:
IS #1672 and OSS-Fuzz #38766:
(zip reader) fix possible out-of-bounds read in zipx_lzma_alone_init()
PR #1676: (mtree reader) remove the unused variable "detected_bytes"
PR #1674: (doc) fix use of At mdoc(7) macro in cpio.5
MFC after: 3 days
This register set contains the values of the fsbase and gsbase
registers. Note that these registers can already be controlled
individually via ptrace(2) via MD operations, so the main reason for
adding this is to include these register values in core dumps. In
particular, this will enable looking up the value of TLS variables
from core dumps in gdb.
The value of NT_X86_SEGBASES was chosen to match the value of
NT_386_TLS on Linux. The notes serve similar purposes, but FreeBSD
will never dump a note equivalent to NT_386_TLS (which dumps a single
segment descriptor rather than a pair of addresses) and picking a
currently-unused value in the NT_X86_* range could result in a future
conflict.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D34650
Summary:
Without it building rust fails with:
ld: error: CallSiteSplitting.cpp:(function llvm::SmallVectorImpl<std::__1::pair<llvm::BasicBlock*, llvm::SmallVector<std::__1::pair<llvm::ICmpInst*, unsigned int>, 2u> > >::operator=(llvm::SmallVectorImpl<std::__1::pair<llvm::BasicBlock*, llvm::SmallVector<std::__1::pair<llvm::ICmpInst*, unsigned int>, 2u> > >&&): .text._ZN4llvm15SmallVectorImplINSt3__14pairIPNS_10BasicBlockENS_11SmallVectorINS2_IPNS_8ICmpInstEjEELj2EEEEEEaSEOSB_+0xB0): relocation R_PPC_PLTREL24 out of range: -33582208 is not in [-33554432, 33554431]
This will need to be merged to releng/13.1.
Reviewed by: dim
Differential Revision: https://reviews.freebsd.org/D34652
MFC after: 3 days
This register set exposes the per-thread TLS register. It matches the
layout used by Linux on arm64. Linux does not implement this note for
32-bit arm.
Reviewed by: andrew, markj
Sponsored by: University of Cambridge, Google, Inc.
Differential Revision: https://reviews.freebsd.org/D34595
Fix unlock in two-word version and add missing comment.
Fixes#15Fixes#16
This should fix the hangs in __cxa_guard_acquire() reported on i386 (and
possibly other 32-bit platforms).
Obtained from: https://github.com/libcxxrt/libcxxrt/commit/f2e5509
Fixes: 56aaed388b
MFC after: 2 weeks
This reapplies upstream commit fd484be, as there is a follow-up fix for
the possible hangs in __cxa_guard_acquire() on i386:
Atomics cleanup (#11)
We need to test exception specifiers but they're gone in C++17 so
compile the tests with an older version of the standard.
Rewrite the guard logic to be more idiomatic C++ and more
comprehensible and make sure that atomics are used where necessary.
Obtained from: https://github.com/libcxxrt/libcxxrt/commit/fd484be
Fixes: 56aaed388b
MFC after: 2 weeks
After merging llvm commit b9ca73e1a8fd for PR 262608, it would fail to
compile with:
/usr/src/contrib/llvm-project/llvm/lib/IR/Operator.cpp:197:22: error: no member named 'isZero' in 'llvm::APInt'
if (!IndexedSize.isZero()) {
~~~~~~~~~~~ ^
Upstream refactored their APInt class, and isZero() was one of the newer
methods which did not yet exist in llvm 13.0.0. Fix this by using the
older but equivalent isNullValue() method instead.
Fixes: 1b3bef43e3
MFC after: 3 days
Merge commit b9ca73e1a8fd from llvm git (by Stephen Tozer):
[DebugInfo] Correctly handle arrays with 0-width elements in GEP salvaging
Fixes an issue where GEP salvaging did not properly account for GEP
instructions which stepped over array elements of width 0 (effectively a
no-op). This unnecessarily produced long expressions by appending
`... + (x * 0)` and potentially extended the number of SSA values used
in the dbg.value. This also erroneously triggered an assert in the
salvage function that the element width would be strictly positive.
These issues are resolved by simply ignoring these useless operands.
Reviewed By: aprantl
Differential Revision: https://reviews.llvm.org/D111809
PR: 262608
Reported by: Damjan Jovanovic <damjan.jov@gmail.com>
MFC after: 3 days
This reverts upstream commit fd484be:
Atomics cleanup (#11)
We need to test exception specifiers but they're gone in C++17 so
compile the tests with an older version of the standard.
Rewrite the guard logic to be more idiomatic C++ and more
comprehensible and make sure that atomics are used where necessary.
It looks like there are some corner cases in the i386 and/or 32-bit
atomics handling, which can make __cxa_guard_acquire() hang in certain
situations.
Reported by: antoine
Obtained from: https://github.com/libcxxrt/libcxxrt/commit/fd484be
Fixes: 56aaed388b
MFC after: 2 weeks
This reverts 9097e3cbca, which was in itself a revert of upstream
libcxxrt commits 88bdf6b290da ("Specify double-word alignment for ARM
unwind") and b96169641f79 ("Updated Itanium unwind"), and a
reapplication of our commit 3c4fd2463b ("libcxxrt: add padding in
__cxa_allocate_* to fix alignment").
The editors/libreoffice port will be patched to be able to cope with the
standards-compliant alignment of _Unwind_Exception and consequently,
that of __cxa_exception. The layouts and sizes of these structures
should then be completely the same for libcxxrt, libunwind and
libc++abi.
PR: 262008
Reviewed by: emaste, jhb, theraven
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D34488
This version fixes a parse error when passing a file to bc using -f
if that file has a multiline comment or string in it.
Merge commit '3673adf1ee311d6f83176d3e43cf0efb314764e4'
MFC after: 3 days
Merge commit f457863ae345 from llvm git (by Fangrui Song):
[ELF] Support REL-format R_AARCH64_NONE relocation
-fprofile-use=/-fprofile-sample-use= compiles may produce REL-format
.rel.llvm.call-graph-profile even if the prevailing format is RELA on AArch64.
Add R_AARCH64_NONE to getImplicitAddend to fix this linker error:
```
ld.lld: error: internal linker error: cannot read addend for relocation R_AARCH64_NONE
PLEASE submit a bug report to https://crbug.com and run tools/clang/scripts/process_crashreports.py (only works inside Google) which will upload a report and include the crash backtrace.
```
Merge commit 53fc5d9b9a01 from llvm git (by Fangrui Song):
[ELF] Support R_PPC_NONE/R_PPC64_NONE in getImplicitAddend
Similar to f457863ae345d2635026501f5383e0e625869639
Merge commit 767e64fc11d7 from llvm git (by Fangrui Song):
[ELF] Support some absolute/PC-relative relocation types for REL format
ctfconvert seems to use REL-format `.rel.SUNW_dof` for 32-bit architectures.
```
Binary file usr/ports/lang/perl5.32/work/perl-5.32.1/dtrace_mini.o matches
[alfredo.junior@dell-a ~/tmp/llvm-bug]$ readelf -r dtrace_mini.o
Relocation section (.rel.SUNW_dof):
r_offset r_info r_type st_value st_name
00000184 0000281a R_PPC_REL32 00000000 $dtrace1772974259.Perl_dtrace_probe_load
```
Support R_PPC_REL32 to fix `ld.lld: error: drti.c:(.SUNW_dof+0x4E4): internal linker error: cannot read addend for relocation R_PPC_REL32`.
While here, add some common relocation types for AArch64, PPC, and PPC64.
We perform minimum tests.
Reviewed By: adalava, arichardson
Differential Revision: https://reviews.llvm.org/D120535
Requested by: alfredo
MFC after: 3 days
Summary:
Use initial-exec, like other architectures.
While here, switch MACHINE_ARCH in lib/libc/Makefile to LIBC_ARCH and consistently use powerpc.
Subscribers: imp, #contributor_reviews_base
Differential Revision: https://reviews.freebsd.org/D34315
Reviewed by: luporl
MFC after: 2 weeks
Update unbound manpages by copying the current unbound manpages in
contrib/doc/*.in to their respective manpages,
PR: 262013
Reported by: Michael Osipov <michael.osipov@siemens.com>
Fixes: numerous previous updates
MFC after: 3 days
NetBSD has an ATF test for newfs_msdos. Connect it to the build.
Adapt it for FreeBSD. This would have caught the bug fixed by my
previous commit.
Reviewed by: delphij, emaste
MFC after: 1 week
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D34116
Libarchive 3.6.0
New features:
PR #1614: tar: new option "--no-read-sparse"
PR #1503: RAR reader: filter support
PR #1585: RAR5 reader: self-extracting archive support
New features (not used in FreeBSD base):
PR #1567: tar: threads support for zstd (#1567)
PR #1518: ZIP reader: zstd decompression support
Security Fixes:
PR #1491, #1492, #1493, CVE-2021-36976:
fix invalid memory access and out of bounds read in RAR5 reader
PR #1566, #1618, CVE-2021-31566:
extended fix for following symlinks when processing the fixup list
Other notable bugfixes and improvements:
PR #1620: tar: respect "--ignore-zeros" in c, r and u modes
PR #1625: reduced size of application binaries
MFC after: 2 weeks
Relnotes: yes
* unit-tests/Makefile: disable opt-debug-x-trace on Linux if there
is any chance we have dash as .SHELL
* meta.c: use a variable to hold command line to be filtered
to avoid any side effects from content of command line.
Merge commit '535c59a6a9214436f5d6643775d29808e4b3408d'
Libarchive 3.6.0
New features:
PR #1614: tar: new option "--no-read-sparse"
PR #1503: RAR reader: filter support
PR #1585: RAR5 reader: self-extracting archive support
New features (not used in FreeBSD base):
PR #1567: tar: threads support for zstd (#1567)
PR #1518: ZIP reader: zstd decompression support
Security Fixes:
PR #1491, #1492, #1493, CVE-2021-36976:
fix invalid memory access and out of bounds read in RAR5 reader
PR #1566, #1618, CVE-2021-31566:
extended fix for following symlinks when processing the fixup list
Other notable bugfixes and improvements:
PR #1620: tar: respect "--ignore-zeros" in c, r and u modes
PR #1625: reduced size of application binaries
Obtained from: libarchive
Libarchive commit: 9147def1da7ad1bdd47b3559eb1bfeeb0e0f374b
Libarchive tag: v3.6.0
It fails during GitHub cross-build actions from Ubuntu 20.04.
sjg investigated and found it is a dash bug; a more extensive change
to handle this case will come in the next bmake update.
Reviewed by: sjg
Differential Revision: https://reviews.freebsd.org/D34219
Merge commit 28fb22c90fe7 from llvm git (by Dimitry Andric):
[TSan] Handle FreeBSD specific indirection of libpthread functions
Similar to 60cc1d3218fc for NetBSD, add aliases and interceptors for the
following pthread related functions:
- pthread_cond_init(3)
- pthread_cond_destroy(3)
- pthread_cond_signal(3)
- pthread_cond_broadcast(3)
- pthread_cond_wait(3)
- pthread_mutex_init(3)
- pthread_mutex_destroy(3)
- pthread_mutex_lock(3)
- pthread_mutex_trylock(3)
- pthread_mutex_unlock(3)
- pthread_rwlock_init(3)
- pthread_rwlock_destroy(3)
- pthread_rwlock_rdlock(3)
- pthread_rwlock_tryrdlock(3)
- pthread_rwlock_wrlock(3)
- pthread_rwlock_trywrlock(3)
- pthread_rwlock_unlock(3)
- pthread_once(3)
- pthread_sigmask(3)
In FreeBSD's libc, a number of internal aliases of the pthread functions
are invoked, typically with an additional prefixed underscore, e.g.
_pthread_cond_init() and so on.
ThreadSanitizer needs to intercept these aliases too, otherwise some
false positive reports about data races might be produced.
Reviewed By: dvyukov
Differential Revision: https://reviews.llvm.org/D119034
MFC after: 3 days
getline() returns -1 on erorr or EOF, so use that condition instead of
feof() and check that there was no error after the loop exits.
Reviewed by: bapt, kevans (both earlier)
MFC after: 3 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34159
This release assigns a default value to the internal program name
variable in case the program is invoked with argv[0] == NULL.
There was no security issue: the prevuous program version would have
been immediately terminated due to a NULL dereference.
Some sanitizers (at least msan) currently require ASLR to be disabled.
When we detect that ASLR is enabled, re-exec with it disabled rather
than exiting with an error. See LLVM GitHub issue 53256 for more
detail: https://github.com/llvm/llvm-project/issues/53256
No objection: dim
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D33934
Based on getMainExecutable() in llvm/lib/Support/Unix/Path.inc.
This will need a little more work for an upstream change as it must
support older FreeBSD releases that lack elf_aux_info() / AT_EXEC_PATH.
No objection: dim
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D33934
Merge commit 6b0f35931a44 from llvm git (by Jennifer Yu):
Fix signal during the call to checkOpenMPLoop.
The root problem is a null pointer is accessed during the call to
checkOpenMPLoop, because loop up bound expr is an error expression
due to error diagnostic was emit early.
To fix this, in setLCDeclAndLB, setUB and setStep instead return false,
return true when LB, UB or Step contains Error, so that the checking is
stopped in checkOpenMPLoop.
Differential Revision: https://reviews.llvm.org/D107385
Note this only fixes the assertion reported in bug 261567; some other
tweaks for port dependencies are probably still required to make it
build to completion.
PR: 261567
MFC after: 3 days
Merge commit c7c84b90879f from llvm git (by Adrian Prantl):
[DwarfDebug] Refuse to emit DW_OP_LLVM_arg values wider than 64 bits
DwarfExpression::addUnsignedConstant(const APInt &Value) only supports
wider-than-64-bit values when it is used to emit a top-level DWARF
expression representing the location of a variable. Before this change,
it was possible to call addUnsignedConstant on >64 bit values within a
subexpression when substituting DW_OP_LLVM_arg values.
This can trigger an assertion failure (e.g. PR52584, PR52333) when it
happens in a fragment (DW_OP_LLVM_fragment) expression, as
addUnsignedConstant on >64 bit values splits the constant into separate
DW_OP_pieces, which modifies DwarfExpression::OffsetInBits.
This change papers over the assertion errors by bailing on overly wide
DW_OP_LLVM_arg values. A more comprehensive fix might be to be to split
wide values into pointer-sized fragments.
[0] https://github.com/llvm/llvm-project/blob/e71fa03/llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp#L799-L805
Patch by Ricky Zhou!
Differential Revision: https://reviews.llvm.org/D115343
MFC after: 3 days
This was prompted by the recent pkexec vulnerability (CVE-2021-4034).
This change is being made on general principle for setuid/setgid
binaries and is not in response to an actual issue.
Reviewed by: kevans, markj (both earlier)
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D34087
Per RFC2822 the maximum transmitted line length is "998 characters...
excluding the CRLF." In a file the maximum is 999 with the \n included.
Previously mail containing a line with exactly 999 characters would
bounce.
PR: 208261
Reported by: Helge Oldach
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
