Currently, we encode the full path and compile flags for the build
compiler in libatf. However, these values are not correct when
cross-compiling: For example, when I build on macOS, CC is set to the
host path /usr/local/Cellar/llvm/11.0.0_1/bin/clang-11. This path will
not exist on the target system.
Simplify this logic and use cc/cpp/c++ since those binaries will exist
on the target system unless the compiler was explicitly disabled.
I'm not convinced ATF needs to encode these values, but this is a
minimal fix for these tests when using a non-bootstrapped compiler.
Reviewed By: ngie, brooks
Differential Revision: https://reviews.freebsd.org/D28414
A few shared libraries in the base system link against ncurses. An
upgrade from a 12.x host to 13 results in ABI breakage for existing
binaries since the newer versions of these libraries link against the
newer ncurses while the binary itself links against the older ncurses.
For example, dialog4ports built on 12.x sometimes crashes on 13 since
it depends on libdialog which links against ncurses internally.
MFC after: 3 days
Reviewed by: kib, delphij
Differential Revision: https://reviews.freebsd.org/D28448
This option has been equivalent to any form of C++ support since libstdc++
was removed. Therefore, replace all MK_LIBCPLUSPLUS uses with MK_CXX.
Reviewed By: emaste
Differential Revision: https://reviews.freebsd.org/D27974
This is a tradeoff which saves jumps for smaller sizes while making
the 8-16 range slower (roughly in line with the other cases).
Tested with glibc test suite.
For example size 3 (most common with vfs namecache) (ops/s):
before: 407086026
after: 461391995
The regressed range of 8-16 (with 8 as example):
before: 540850489
after: 461671032
The previous code neglected to use primitives which can find the end
of the string without having to branch on every character.
While here augment the somewhat misleading commentary -- strlen as
implemented here leaves performance on the table, especially so for
userspace. Every arch should get a dedicated variant instead.
In the meantime this commit lessens the problem.
Tested with glibc test suite.
Naive test just calling strlen in a loop on Haswell (ops/s):
$(perl -e "print 'A' x 3"):
before: 211198039
after: 338626619
$(perl -e "print 'A' x 100"):
before: 83151997
after: 98285919
This tests fork()s, so if there is still data in the stdout buffer on fork
it will print it again in the child process. This was happening in the
CheriBSD CI and caused the test to complain about malformed TAP output.
Reviewed By: ngie
Differential Revision: https://reviews.freebsd.org/D28397
SVN r343917 fixed this for in-tree clang, but when building with a newer
out-of-tree clang the test was still marked as XFAIL.
Reviewed By: dim
Differential Revision: https://reviews.freebsd.org/D28390
This is all code only run on ARMv4 and ARMv5. Support for these have
been dropped from FreeBSD.
Differential Revision: https://reviews.freebsd.org/D28314
This was only used when building for ARMv4 or some ARMv5 or when
_STANDALONE is defined. As ARMv4 and ARMv5 support has been removed,
and we only define _STANDALONE in the bootloader where we don't use
this version of memcpy we can remove it.
Differential Revision: https://reviews.freebsd.org/D28313
When building natively on RISC-V, linking the bootstrap clang-tblgen
fails with:
ld: error: undefined symbol: llvm::EnableABIBreakingChecks
>>> referenced by PrettyStackTrace.cpp
>>> PrettyStackTrace.o:(.sdata+0x0) in archive
/usr/obj/usr/src/freebsd-src/riscv.riscv64/tmp/obj-tools/lib/clang/libllvmminimal/libllvmminimal.a
>>> referenced by Signals.cpp
>>> Signals.o:(.sdata+0x8) in archive
/usr/obj/usr/src/freebsd-src/riscv.riscv64/tmp/obj-tools/lib/clang/libllvmminimal/libllvmminimal.a
>>> referenced by Timer.cpp
>>> Timer.o:(.sdata+0x28) in archive
/usr/obj/usr/src/freebsd-src/riscv.riscv64/tmp/obj-tools/lib/clang/libllvmminimal/libllvmminimal.a
This is likely due to Error.h's inclusion of abi-breaking.h. It's
unclear why this only affects RISC-V, but perhaps relates to its more
eager use of .sdata due to the ABI's support for linker relaxations.
Regardless, this is theoretically an issue for all architectures.
Reported by: Dennis Clarke <dclarke@blastwave.org>
Reviewed by: dim
Tested by: mhorne
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D28367
These tests are basic fuzz tests that permute input to trigger crashes
rather than regression or unit tests. Additionally, some of them take a
rather long time to run and should probably be run on a dedicated fuzzing
job instead. Moreover, these simple tests use rand() instead of a real
fuzzing tool that generates interesting inputs (e.g. LLVM libFuzzer) so are
unlikely to find anything interesting when run in CI.
This allows removing one BROKEN_TESTS case due to timeouts and speeds up
running tests on emulated platforms such as QEMU.
Reviewed By: lwhsu, mm
Differential Revision: https://reviews.freebsd.org/D27153
WITHOUT_LIBTHR has been broken for a little over five years now, since the
xz 5.2.0 update introduced a hard liblzma dependency on libthr, and building
a useful system without threading support is becoming increasingly more
difficult.
Additionally, in the five plus years that it's been broken more reverse
dependencies have cropped up in libzstd, libsqlite3, and libcrypto (among
others) that make it more and more difficult to reconcile the effort needed
to fix these options.
Remove the broken options.
PR: 252760
Reviewed by: brooks, emaste, kib
Differential Revision: https://reviews.freebsd.org/D28263
Some tests verify that the capgrp capability does not permit calls to
setgrent(3), but all tests need to ensure that they reset the
capability's group database handle, otherwise the local process and
casper process will be out of sync.
The cap_pwd tests already handle this.
Sponsored by: The FreeBSD Foundation
MFC after: 1 month
Because the "files" and "compat" implementations failed to set the
"stayopen", keyed lookups would close the database handle, contrary to
the purpose of setgroupent(3). setpassent(3)'s implementation does not
have this bug.
PR: 165527
Submitted by: Andrey Simonenko
MFC after: 1 month
The getpwent(3) and getgrent(3) implementations maintain some internal
iterator state. Interleaved calls to functions which do passwd/group
lookups using a key, such as getpwnam(3), would in some cases clobber
this state, causing a subsequent getpwent() or getgrent() call to
restart iteration from the beginning of the database or to terminate
early. This is particularly troublesome in programming environments
where execution of green threads is interleaved within a single OS
thread.
Take care to restore any iterator state following a keyed lookup. The
"files" provider for the passwd database was already handling this
correctly, but "compat" was not, and both providers had this problem
when accessing the group database.
PR: 252094
Submitted by: Viktor Dukhovni <ietf-dane@dukhovni.org>
MFC after: 1 month
Some NSS regression tests for getgrent(3) and getpwent(3) were not
testing anything because the test incorrectly requested creation of a
database snapshot.
Sponsored by: The FreeBSD Foundation
MFC after: 1 month
This file has other questionable code and "optimizations" (such as copying
one int at a time) that are probably no longer useful, so it might make
sense to replace it with a different implementation at some point.
Reviewed By: jhb
Differential Revision: https://reviews.freebsd.org/D28134
Define a non-const static char EMSG[] = "" to avoid having to add
__DECONST() to all uses of EMSG. Also make current_dash a const char *
to fix this warning.
This is a no-op for now since libifconfig is only built as a static lib.
Reviewed by: freqlabs, kp, adrian
Differential Revision: https://reviews.freebsd.org/D28119
In libcasper, the first argument to the function is a structure that
represents a connection to Casper. On systems without Casper, macros
are used to interpose the Casper functions to standard libc ones.
This may cause errors/warnings that the variable is not used.
With the inline function, there is no such problem.
I omitted this file in: 8c121177f0
One possible way the recursion can happen is during fork: suppose
that fork is called from early code that did not triggered
jemalloc(3) initialization yet. Then we lock thr_malloc lock, and
call malloc_prefork() that might require initialization of jemalloc
pthread_mutexes, calling into libthr malloc. It is safe to allow
recursion for this occurence.
PR: 252579
Reported by: Vasily Postnicov <shamaz.mazum@gmail.com>
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Previously, we would accept any kind of LIO_* opcode, including ones
that were intended for in-kernel use only like LIO_SYNC (which is not
defined in userland). The situation became more serious with
022ca2fc7f. After that revision, setting
aio_lio_opcode to LIO_WRITEV or LIO_READV would trigger an assertion.
Note that POSIX does not specify what should happen if aio_lio_opcode is
invalid.
MFC-with: 022ca2fc7f
Reviewed by: jhb, tmunro, 0mp
Differential Revision: <https://reviews.freebsd.org/D28078
Without wrapping, rtld services and malloc(3) are not guaranteed
to operate correctly in the forked child.
Reviewed by: markj
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D28088
which makes stack prot correct for non-main threads created by binaries
with statically linked libthr.
Cache result, but do not engage into the full double-checked locking,
since calculation of the return value is idempotent.
PR: 252549
Reported and reviewed by: emaste
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D28075
Detect and use RDTSCP if available, instead of fence+RDTSC. For AMD Zens+,
use LFENCE+RDTSC instead of RDTSCP (or MFENCE;RDTSC previously).
Reviewed by: gallatin, markj
Tested by: pho
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D27986
Create array of rdtsc selectors and provide helper that calculate the
index into the selectors array.
Reviewed by: gallatin, markj
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D27986
Instead of providing ifuncs for each kind of fence, define ifuncs
that combine fence and invocation of RDTSC. This refactoring makes
introduction of RDTSCP use possible.
Reviewed by: gallatin, markj
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D27986
Instead of trying to maintain pg_jobc counter on each process group
update (and sometimes before), just calculate the counter when needed.
Still, for the benefit of the signal delivery code, explicitly mark
orphaned groups as such with the new process group flag.
This way we prevent bugs in the corner cases where updates to the counter
were missed due to complicated configuration of p_pptr/p_opptr/real_parent
(debugger).
Since we need to iterate over all children of the process on exit, this
change mostly affects the process group entry and leave, where we need
to iterate all process group members to detect orpaned status.
(For MFC, keep pg_jobc around but unused).
Reported by: jhb
Reviewed by: jilles
Tested by: pho
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D27871
