o ignore '.POSIX:' if not in first non-comment line
of Makefile as specified by POSIX.
add unit-tests for above.
Merge commit '92bfae0e6bd53a7a0d6fe55e70a916d86cf26e8b'
Fix dialogs building and updating fault with disabled shadow
(conf.shadow=false and implicitly bsddialog --no-shadow).
While here delete WARNS=2: all warnings were fixed in upstream and
imported in 0.2.
Approved by: bapt (mentor)
Differential Revision: https://reviews.freebsd.org/D34958
Insert padding in __cxa_exception struct for compatibility
Similar to https://github.com/llvm/llvm-project/commit/f2a436058fcb, the
addition of __attribute__((__aligned__)) to _Unwind_Exception (in commit
b9616964) causes implicit padding to be inserted before the unwindHeader
field in __cxa_exception.
Applications attempt to get at the earlier fields in __cxa_exception, so
preserve the same negative offsets in __cxa_exception, by moving the
padding to the beginning of the struct.
The assumption here is that if the ABI is not aware of the padding
before unwindHeader and put the referenceCount/primaryException in
there, no padding should exist before unwindHeader.
This should make libreoffice's custom exception handling mechanisms work
correctly, even if it was built against an older cxxabi.h/unwind.h pair.
PR: 263370
MFC after: 3 days
Main change is a callback for checking validity period of certificates.
Merge commit 'f6acb9b9f81c96ae7c9592bee1bb89c4357cc3e5'
Add -DHAVE_BR_X509_TIME_CHECK to libsecureboot/Makefile.inc
This update fixes an issue in input line editing: when going left to
the start of the line, the cursor would jump to the end of the line
instead.
Merge commit 'bc75dcc4ce682562390fa32e7cd63c08160e21b9'
The second argument to pcap_next_ex() is a pointer to a pointer.
Not a pointer. This fixes a wpa_supplicent SIGSEGV.
PR: 263266
Reported by: Marek Zarychta <zarychtam@plan-b.pwste.edu.pl>
Fixes: 6e5d01124f
MFC: immediately
hostapd calls pcap_next(3) to read the next packet off the wlan interface.
pcap_next() returns a pointer to the packet header but does not indicate
success or failure. Unfortunately this results in an infinite loop (100%
CPU) when the wlan device disappears, i.e. when a USB wlan device is
manually removed or a USB error results in the device removal. However
pcap_next_ex(3) does return success or failure. To resolve this we use
pcap_next_ex(), forcing hostapd to exit when the error is encountered.
An error message is printed to syslog or stderr when debugging (-d flag)
is enabled. Unfortunately wpa_printf() only works when debugging is enabled.
PR: 253608
Reported by: Damjan Jovanovic <damjan.jov@gmail.com>,
bz (privately)
MFC after: 3 days
Bugfixes:
IS #1685 and OSS-Fuzz #38764 (security):
(ISO reader) fix possible heap buffer overflow in read_children()
IS #1715 and OSS-Fuzz #46279 (security):
(RARv4 reader) fix heap-use-after-free in run_filters()
MFC after: 3 days
Merge LLVM commit 81f5c6270cdfcdf80e6296df216b696a7a37c8b5.
This fixes runtime of most notably pcre libraries (currently patched in ports),
and probably also other ports since currently __clear_cache() just calls
SIGABRT on powerpc.
MFC after: 3 days
Reviewed by: dim
Differential Revision: https://reviews.freebsd.org/D34736
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
Import bsddialog 0.1 Utility and Library, fully refatorized, API stable,
manuals completed, easier to maintain and improve.
Update deps for new API:
add mixedgauge consts, delete __DECONST and add bsddialog_geterror()
info to avoid silent errors
* tzsetup
* kbdmap
* distextract
Differential Revision: https://reviews.freebsd.org/D34066
The kern.elf64.aslr.pie_enable and kern.elf32.aslr.pie_enable sysctls
control the default setting for PIE binary address randomization, but
it is possible to enable or disable ASLR on a per-process basis. Use
procctl(2) to query whether ASLR is enabled.
(Note that with ASLR enabled but sysctl kern.elf64.aslr.pie_enable=0
a PIE binary will in effect have randomization disabled, and be
functional with msan. This is not intended as as a user-facing control
though. The user can use proccontrol(1) to disable aslr for the
process.)
Approved by: dim
Obtained from: LLVM 64de0064f315f57044294879d9ff4eacb454d45b
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D33933
When running the installer, in particular disextract (which is so far
the only part converted to bsddialog), on serial console or vt100 or
actually any terminal without color support, it failed to start.
This change makes bsddialog fallback on the black and white theme.
This is incorporated in newer version of bsddialog which will be
imported soon.
PR: 261272
Reported by: thj
Differential Revision: https://reviews.freebsd.org/D33920
This reverts commit 5eb81a4b40, reversing
changes made to c6806434e7 and
this reverts commit 679ff61123.
What happend is git rebase --rebase-merges doesn't do what is expected.
ASLR stack randomization will reappear in a forthcoming commit. Rather
than inserting a random gap into the stack mapping, the entire stack
mapping itself will be randomized in the same way that other mappings
are when ASLR is enabled.
No functional change intended, as the stack gap implementation is
currently disabled by default.
Reviewed by: kib
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D33704
The test tries to connect a socket to a closed port at 127.0.0.1. It
sets O_NONBLOCK on the socket first and expects to get EINPROGRESS from
connect(2), but this is not guaranteed, ECONNREFUSED is possible.
Handle both cases, and re-enable the test.
PR: 240621
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
The stack gap implementation is disabled by default now, so the test
passes.
This reverts commit dad71022bd.
PR: 259969
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
The introduction of <sched.h> improved compatibility with some 3rd
party software, but caused the configure scripts of some ports to
assume that they were run in a GLIBC compatible environment.
Parts of sched.h were made conditional on -D_WITH_CPU_SET_T being
added to ports, but there still were compatibility issues due to
invalid assumptions made in autoconfigure scripts.
The differences between the FreeBSD version of macros like CPU_AND,
CPU_OR, etc. and the GLIBC versions was in the number of arguments:
FreeBSD used a 2-address scheme (one source argument is also used as
the destination of the operation), while GLIBC uses a 3-adderess
scheme (2 source operands and a separately passed destination).
The GLIBC scheme provides a super-set of the functionality of the
FreeBSD macros, since it does not prevent passing the same variable
as source and destination arguments. In code that wanted to preserve
both source arguments, the FreeBSD macros required a temporary copy of
one of the source arguments.
This patch set allows to unconditionally provide functions and macros
expected by 3rd party software written for GLIBC based systems, but
breaks builds of externally maintained sources that use any of the
following macros: CPU_AND, CPU_ANDNOT, CPU_OR, CPU_XOR.
One contributed driver (contrib/ofed/libmlx5) has been patched to
support both the old and the new CPU_OR signatures. If this commit
is merged to -STABLE, the version test will have to be extended to
cover more ranges.
Ports that have added -D_WITH_CPU_SET_T to build on -CURRENT do
no longer require that option.
The FreeBSD version has been bumped to 1400046 to reflect this
incompatible change.
Reviewed by: kib
MFC after: 2 weeks
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D33451
Since popcnt is only supported by CPUTYPE=nehalem and later, ensure that
this instruction is only emitted when appropriate. Otherwise, programs
using the library can abort with SIGILL.
See also: https://github.com/llvm/llvm-project/issues/52893
PR: 258156
Reported by: Eric Rucker <bhtooefr@bhtooefr.org>
MFC after: 3 days
Merge commit 77e8f4eeeeed from llvm git (by David Green):
[ARM] Define ComplexPatternFuncMutatesDAG
Some of the Arm complex pattern functions call canExtractShiftFromMul,
which can modify the DAG in-place. For this to be valid and handled
successfully we need to define ComplexPatternFuncMutatesDAG.
Differential Revision: https://reviews.llvm.org/D107476
When building parts of llvm targeting armv6 on stable/12, the following
assertion can appear (or if assertions are disabled, clang is likely to
crash):
Assertion failed: (NodeToMatch->getOpcode() != ISD::DELETED_NODE && "NodeToMatch was removed partway through selection"), function SelectCodeCommon, file /usr/src/contrib/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp, line 3573.
PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0. Program arguments: /usr/obj/usr/src/freebsd12-amd64/tmp/usr/bin/c++ -cc1 -triple armv6kz-unknown-freebsd12.3-gnueabihf -S --mrelax-relocations -disable-free -disable-llvm-verifier -discard-value-names -mrelocation-model static -mconstructor-aliases -target-cpu arm1176jzf-s -target-feature +vfp2 -target-feature +vfp2sp -target-feature -vfp3 -target-feature -vfp3d16 -target-feature -vfp3d16sp -target-feature -vfp3sp -target-feature -fp16 -target-feature -vfp4 -target-feature -vfp4d16 -target-feature -vfp4d16sp -target-feature -vfp4sp -target-feature -fp-armv8 -target-feature -fp-armv8d16 -target-feature -fp-armv8d16sp -target-feature -fp-armv8sp -target-feature -fullfp16 -target-feature +fp64 -target-feature -d32 -target-feature -neon -target-feature -sha2 -target-feature -aes -target-feature -fp16fml -target-feature +strict-align -target-abi aapcs-linux -mfloat-abi hard -fallow-half-arguments-and-returns -ffunction-sections -fdata-sections -O1 -std=c++14 -fdeprecated-macro -fno-rtti -fno-signed-char -faddrsig -fexperimental-new-pass-manager PPCISelLowering-009095.ii
1. <eof> parser at end of file
2. Code generation
3. Running pass 'Function Pass Manager' on module 'PPCISelLowering-009095.cpp'.
4. Running pass 'ARM Instruction Selection' on function '@_ZN4llvm17PPCTargetLoweringC2ERKNS_16PPCTargetMachineERKNS_12PPCSubtargetE'
This crash or assertion is fixed by the upstream commit.
MFC after: 3 days
clock_gettime() returns 0 if it succeeds, so don't capture that into the
fail logic. With this, WITH_DETECT_TZ_CHANGES successfully detects a
change after 61 seconds.
Reviewed by: imp, trasz
Differential Revision: https://reviews.freebsd.org/D33494
This reverts commit 4f741801d8.
As per discussion in PR: 260303 the reverted patch covered the
real issue with a fixed address of the top of the stack.
Remove the remaining unused source files. These were never used.
This is the last of a three commit series to move ipfilter.
Discussed with: glebius
Reviewed by: glebius, kp (for #network)
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33510
Through fixes and improvements our ipfilter sources have diverged
enough to warrant move from contrib into sbin/ipf. Now that I'm
planning on implementing MSS clamping as in iptables it makes more
sense to move ipfilter to sbin.
This is the second of three commits of the ipfilter move.
Suggested by glebius on two occaions.
Suggested by and discussed with: glebius
Reviewed by: glebius, kp (for #network)
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D33510
With ASLR enabled by default, RLIMIT_STACK test fails due to the fact
that default stack gap can be as big as 15M. Because of that the
resource limit of 4M results in test program receiving SIGSEGV
immediately after exiting the setrlimit syscall. Since the idea of this
test is to check if rlim_cur does not extend past rlim_max, adjusting
the resource limit to 20M should not invalidate the test results.
Obtained from: Semihalf
Sponsored by: Alstom Group
Differential revision: https://reviews.freebsd.org/D33116
Merge commit e5a8af7a90c6 from llvm git (by Gulfem Savrun Yeniceri):
[Passes] Fix relative lookup table converter pass
This patch fixes the relative table converter pass for the lookup table
accesses that are resulted in an instruction sequence, where gep is not
immediately followed by a load, such as gep being hoisted outside the loop
or another instruction is inserted in between them. The fix inserts the
call to load.relative.instrinsic in the original place of load instead of gep.
Issue is reported by FreeBSD via https://bugs.freebsd.org/259921.
Differential Revision: https://reviews.llvm.org/D115571
PR: 259921
Reported by: O. Hartmann <freebsd@walstatt-de.de>
MFC after: 3 days
This works around brokenness in buildworld's bootstrapping logic: it
uses the source tree's metadata to collect dependency info (such as,
"libdwarf depends on libz") but links against static host libraries.
If these two are out of sync, as is the case if one builds a commit
prior to the introduction of the libz dependency, then the build fails
when trying to statically link nm(1).
Mitigate the problem by defining a weak uncompress() symbol which simply
returns an error. This ensures that the build won't fail when
statically linking libdwarf without zlib. The downside is that any
tools using libdwarf without zlib will now hit a runtime error if they
attempt to decode compressed sections, but at least they'll fail
deterministically, and compressed debug info is only enabled by default
in main.
In particular, this fixes building of branches lacking commit
dbf05458e3, such as releng branches, stable/12 and 13 and old
revisions of main. Previously the nm(1) build would fail with:
ld: error: undefined symbol: uncompress
>>> referenced by libdwarf_elf_init.c:233
>>> (/usr/src/contrib/elftoolchain/libdwarf/libdwarf_elf_init.c:233)
>>> libdwarf_elf_init.o:(_dwarf_elf_init) in archive
>>> /usr/lib/libdwarf.a
Reported by: dim, ler, krion
Reviewed by: imp, emaste
Fixes: dbf05458e3 ("libdwarf: Support consumption of compressed ELF sections")
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D33419
We were not setting "ret" before jumping to the error path, so the
function returned success even when it had failed.
Reviewed by: emaste
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D33420
Revert commit e655e74a318e from llvm git (by Peter Collingbourne):
AST: Create __va_list in the std namespace even in C.
This ensures that the mangled type names match between C and C++,
which is significant when using -fsanitize=cfi-icall. Ideally we
wouldn't have created this namespace at all, but it's now part of
the ABI (e.g. in mangled names), so we can't change it.
Differential Revision: https://reviews.llvm.org/D104830
As reported by Jessica in https://reviews.llvm.org/D104830#3129527, this
upstream change is implemented in such a way that it breaks DTrace's
CTF. Since a proper fix has not yet been forthcoming, and we are
unaffected by the (CFI-related) problem upstream was trying to address,
revert the change for now.
Requested by: jrtc27
MFC after: 3 days
These files were intended to track version and perhaps maintainership
information for contrib software. However, they were never used beyond
bzip2, netcat, and OpenSSH, and generally haven't been kept up to date
recently (my OpenSSH 8.7p1 update notwithstanding). Just remove them to
avoid having confusing or outdated information.
Suggested by: des
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Merge commit df08b2fe8b35 from llvm git (by Dimitry Andric):
[AArch64] Avoid crashing on invalid -Wa,-march= values
As reported in https://bugs.freebsd.org/260078, the gnutls Makefiles
pass -Wa,-march=all to compile a number of assembly files. Clang does
not support this -march value, but because of a mistake in handling
the arguments, an unitialized Arg pointer is dereferenced, which can
cause a segfault.
Work around this by adding a check if the local WaMArch variable is
initialized, and if so, using its value in the diagnostic message.
Reviewed By: tschuett
Differential Revision: https://reviews.llvm.org/D114677
PR: 260078
Reported by: bz
MFC after: 3 days
This reverts commit 266f97b5e9, reversing
changes made to a10253cffe.
A mismerge of a merge to catch up to main resulted in files being
committed which should not have been.
Vendor commit message (ede459d2e):
archive_write_disk_posix: fix writing fflags broken in 8a1bd5c
The fixup list was erroneously assumed to be directories only.
Only in the case of critical file flags modification (e.g.
SF_IMMUTABLE on BSD systems), other file types (e.g. regular files
or symbolic links) may be added to the fixup list. We still need to
verify that we are writing to the correct file type, so compare the
archive entry file type with the file type of the file to be
modified.
Fixes vendor issue #1617:
Immutable flag no longer preserved during tar extraction on FreeBSD
MFC after: 3 days
Reported by: markjdb
Libarchive commit: ede459d2ebb879f5eedb6f7abea203be0b334230
Merge commit e27a6db5298f from llvm git (by Jameson Nash):
Bad SLPVectorization shufflevector replacement, resulting in write to wrong memory location
We see that it might otherwise do:
%10 = getelementptr {}**, <2 x {}***> %9, <2 x i32> <i32 10, i32 4>
%11 = bitcast <2 x {}***> %10 to <2 x i64*>
...
%27 = extractelement <2 x i64*> %11, i32 0
%28 = bitcast i64* %27 to <2 x i64>*
store <2 x i64> %22, <2 x i64>* %28, align 4, !tbaa !2
Which is an out-of-bounds store (the extractelement got offset 10
instead of offset 4 as intended). With the fix, we correctly generate
extractelement for i32 1 and generate correct code.
Differential Revision: https://reviews.llvm.org/D106613
Merge commit 029f1a534489 from llvm git (by Arthur Eubanks):
[LazyCallGraph] Skip blockaddresses
blockaddresses do not participate in the call graph since the only
instructions that use them must all return to someplace within the
current function. And passes cannot retrieve a function address from a
blockaddress.
This was suggested by efriedma in D58260.
Fixes PR50881.
Reviewed By: nickdesaulniers
Differential Revision: https://reviews.llvm.org/D112178
Merge commit f5755c0849a5 from llvm git (by Jessica Clarke):
[Mips] Add glue between CopyFromReg, CopyToReg and RDHWR nodes for TLS
The MIPS ABI requires the thread pointer be accessed via rdhwr $3, $r29.
This is currently represented by (CopyToReg $3, (RDHWR $29)) followed by
a (CopyFromReg $3). However, there is no glue between these, meaning
scheduling can break those apart. In particular, PR51691 is a report
where PseudoSELECT_I was moved to between the CopyToReg and CopyFromReg,
and since its expansion uses branches, it split the def and use of the
physical register between two basic blocks, resulting in the def being
eliminated and the use having no def. It also seems possible that a
similar situation could arise splitting up the CopyToReg from the RDHWR,
causing the RDHWR to use a destination register other than $3, violating
the ABI requirement.
Thus, add glue between all three nodes to ensure they aren't split up
during instruction selection. No regression test is added since any test
would be implictly relying on specific scheduling behaviour, so whilst
it might be testing that glue is preventing reordering today, changes to
scheduling behaviour could result in the test no longer being able to
catch a regression here, as the reordering might no longer happen for
other unrelated reasons.
Fixes PR51691.
Reviewed By: atanasyan, dim
Differential Revision: https://reviews.llvm.org/D111967
Merge commit c9539f957f57 from llvm git (by Nemanja Ivanovic):
[PowerPC] Define XL-compatible macros only for AIX and Linux
Since XLC only ever shipped on PowerPC AIX and Linux, it is not
reasonable to provide the compatibility macros on any target other
than those two. This patch restricts those macros to AIX/Linux.
Differential revision: https://reviews.llvm.org/D110213
PR: 258209
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvmorg-13-init-16847-g88e66fa60ae5, the last commit before
the upstream release/13.x branch was created.
PR: 258209
MFC after: 2 weeks
Upstream one-true-awk has two sets of tests. These are in addition to
NetBSD's tests we're using. The 'bugs-fixed' tests from upstream are
ready to use as-is (more or less). However, the 'tests' from upstream
are not, so for now we'll just use the netbsd and bugs-fixed tests.
They provide an OK workout and are better than nothing, though the tests
themselves are for specific esoteric things.
The upstream bugs-fixed tests are *ALMOST* a drop in. However, 3 test
for errors and the upstream test jig mashes stdout and stderr together,
which atf doesn't do, so make a tiny tweak to the upstream tests that I
hope to upstream. Plus upstream has ../a.out: instead of awk: in the
output. Not sure how to deal with this yet, so I've not proposed
anything upstream and have changed the test locally.
In addition, the system-status.awk test is not suitable to run in ATF.
It wants to force sh to dump core, but kyua doesn't seem to allow that
sometimes so the test will fail or pass based on whether or not a core
dump can be created. Since it's unstable, remove it.
This required moving the netbsd tests to a new direcotry, so update
mtree files as well. The change is useless for 'make check' without it.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D31376
Allow users to set a number on rules which will be exposed as part of
the pflog header.
The intent behind this is to allow users to correlate rules across
updates (remember that pf rules continue to exist and match existing
states, even if they're removed from the active ruleset) and pflog.
Obtained from: pfSense
MFC after: 3 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D32750
Previously strip reported a somewhat cryptic error for empty files:
strip: elf_begin() failed: Invalid argument
Add a special case to treat empty files as with an unknown file format.
This is consistent with llvm-strip. GNU strip produces no output which
does not seem like useful behaviour (but it does exit with status 1).
Reported by: andrew
Reviewed by: markj
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D32648
Merge commit 2d8c18fbbdd1 from llvm git (by Jessica Clarke):
[X86] Don't add implicit REP prefix to VIA PadLock xstore
Commit 8fa3e8fa1492 added an implicit REP prefix to all VIA PadLock
instructions, but GNU as doesn't add one to xstore, only all the others.
This resulted in a kernel panic regression in FreeBSD upon updating to
LLVM 11 (https://bugs.freebsd.org/259218) which includes the commit in
question. This partially reverts that commit.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D112355
MFC after: 3 days
Add necessary bits to detect ELF format on Linux/aarch64; note that
Linux calls it aarch64 where we would typically call it arm64 (uname -m)
Reviewed by: arichardson, emaste, imp
Sponsored by: Ampere Computing LLC
Sponsored by: Klara Inc.
Differential Revision: https://reviews.freebsd.org/D32542
On arm64 binaries can be tagged as using BTI or PAC. Add support to
decode these to the elftoolchain readelf.
To simplify the code use a table based method to find the flag
description table.
Reviewed by: emaste
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D32315
Cherry-picked from libfido2 upstream f20a735c0a6f:
iso7816: Avoid storing pointers in a packed structure
On CHERI, and thus Arm's experimental Morello prototype architecture,
pointers are represented as capabilities, which are unforgeable bounded
pointers, providing always-on fine-grained spatial memory safety. The
unforgeability is enforced through the use of tagged memory, with one
validity tag bit per capability-sized-and-aligned word in memory. This
means that storing a pointer to an unaligned location, which is not
guaranteed to work per the C standard, either traps or results in the
capability losing its tag (and thus never being dereferenceable again),
depending on how exactly the store is done (specifically, whether a
capability store or memcpy is used).
However, iso7816 itself does not need to be packed, and doing so likely
causes inefficiencies on existing architectures. The iso7816_header_t
member is packed, and the flexible payload array is a uint8_t (which by
definition has no padding bits and is exactly 8 bits in size and, since
CHAR_BITS must be at least 8, its existence implies that it has the same
representation as unsigned char, and that it has size and alignment 1)
so there will never be any padding inserted between header and payload
(but payload may overlap with padding at the end of the struct due to
how flexible arrays work, which means we need to be careful about our
calculations).
Co-authored-by: pedro martelletto <pedro@yubico.com>