Even though clang comes with a number of internal CUDA wrapper headers,
compiling sample CUDA programs will result in errors similar to:
In file included from <built-in>:1:
In file included from /usr/lib/clang/9.0.0/include/__clang_cuda_runtime_wrapper.h:204:
/usr/home/arr/cuda/var/cuda-repo-10-0-local-10.0.130-410.48/usr/local/cuda-10.0//include/crt/math_functions.hpp:2910:7: error: no matching function for call to '__isnan'
if (__isnan(a)) {
^~~~~~~
/usr/lib/clang/9.0.0/include/__clang_cuda_device_functions.h:460:16: note: candidate function not viable: call to __device__ function from __host__ function
__DEVICE__ int __isnan(double __a) { return __nv_isnand(__a); }
^
CUDA expects __isnan() and __isnanf() declarations to be available,
which are glibc specific extensions, equivalent to the regular isnan()
and isnanf().
To provide these, define __isnan() and __isnanf() as aliases of the
already existing static inline functions __inline_isnan() and
__inline_isnanf() from math.h.
Reported by: arrowd
PR: 241550
MFC after: 1 week
It turns out that a test of backtrace symbol resolution and formatting
requires symbols. Another option mightt be building with -rdynamic instead,
but this works for now.
Re-enabled skipped CI test, as it should now pass.
PR: 241562
Submitted by: lwhsu
Reported by: lwhsu
X-MFC-With: r354126, r354135, r354144
Drop portions that are unlit or redundant with llvm-libunwind: builtin.c,
unwind.h, and unwind_arm_ehabi_stub.c.
This code should now work with -fPIE binaries, should we choose to build any
that way.
When backtrace() array is full, signal an error so the underlying
Itanium-style C++ exception handling library (llvm-libunwind) knows to stop
tracing instead of continuing. (It should stop on its own when it finishes
unwinding, so this is mostly an extra seatbelt against an infinite loop bug
in the unwinder.)
For EFI at least, we can seed the environment
with VE_VERBOSE etc.
Reviewed by: stevek imp
Sponsored by: Juniper Networks
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D22135
operation & ~limit where limit is a bool is clearly not what was intended,
given the line prior. Correct it to use the calculated mask for validation.
The cap_sysctl tests should now be functional again.
Imported BE, much like the activated BE, will not have an origin that we can
fetch/examine for destruction. be_destroy should not return BE_ERR_NOORIGIN
for failure to get the origin property for BE_DESTROY_AUTOORIGIN, because
we don't really know going into it that there's even an origin to be
destroyed.
BE_DESTROY_NEEDORIGIN has been renamed to BE_DESTROY_WANTORIGIN because only
a subset of it *needs* the origin, so 'need' is too strong of verbiage.
This was caught by jenkins and the bectl tests, but kevans failed to run the
bectl tests prior to commit.
Reported by: lwhsu
New BEs can be created from either an existing snapshot or an existing BE.
If an existing BE is chosen (either implicitly via 'bectl create' or
explicitly via 'bectl create -e foo bar', for instance), then bectl will
create a snapshot of the current BE or "foo" with be_snapshot, with a name
formatted like: strftime("%F-%T") and a serial added to it.
This commit adds the needed bits for libbe or consumers to determine if a
snapshot names matches one of these auto-created snapshots (with some light
validation of the date/time/serial), and also a be_destroy flag to specify
that the origin should be automatically destroyed if possible.
A future commit to bectl will specify BE_DESTROY_AUTOORIGIN by default so we
clean up the origin in the most common case, non-user-managed snapshots.
Summary:
This forces applications linked with lib CSU to have a .got, fixing binaries
linked with LLD9 after secure-plt was enabled on FreeBSD.
Submitted by: Alfredo Dal'Ava Junior (alfredo.junior_eldorado.org.br)
Differential Revision: https://reviews.freebsd.org/D21476
Compiling with clang gives a loss-of-alignment error due the cast to
uint8_t *. Since the TLS is always tcb aligned and TP_OFFSET is defined
as sizeof(struct tcb) we can guarantee there is no misalignment. Silence
the error by moving the offset into the inline assembly.
Reviewed by: br
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D21926
Clang from trunk recently added a warning for when implicit int-to-float
conversions cause a loss of precision. The code in question is designed
to be able to handle that, so add explicit casts to silence this.
Submitted by: James Clarke <jrtc27@jrtc27.com>
Reviewed by: dim
Obtained from: CheriBSD
MFC after: 1 week
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D21913
This warning (comparing a pointer against a zero character literal
rather than NULL) has existed since GCC 7.1.0, and was recently added to
Clang trunk.
Almost all of these are harmless, except for fwcontrol's str2node, which
needs to both guard against dereferencing a NULL pointer (though in
practice it appears none of the callers will ever pass one in), as well
as ensure it doesn't parse the empty string as node 0 due to strtol's
awkward interface.
Submitted by: James Clarke <jtrc27@jrtc27.com>
Obtained from: CheriBSD
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D21914
This provides a framework to define a template describing
a set of "variables of interest" and the intended way for
the framework to maintain them (for example the maximum, sum,
t-digest, or a combination thereof). Afterwards the user
code feeds in the raw data, and the framework maintains
these variables inside a user-provided, opaque stats blobs.
The framework also provides a way to selectively extract the
stats from the blobs. The stats(3) framework can be used in
both userspace and the kernel.
See the stats(3) manual page for details.
This will be used by the upcoming TCP statistics gathering code,
https://reviews.freebsd.org/D20655.
The stats(3) framework is disabled by default for now, except
in the NOTES kernel (for QA); it is expected to be enabled
in amd64 GENERIC after a cool down period.
Reviewed by: sef (earlier version)
Obtained from: Netflix
Relnotes: yes
Sponsored by: Klara Inc, Netflix
Differential Revision: https://reviews.freebsd.org/D20477
Diff partially stolen from CheriBSD; these bits need -Wl,-z,notext in order
to build in an LLVM world. They are needed for all flavors/sizes of MIPS.
This will eventually get fixed in LLVM, but it's unclear when.
Reported by: arichardson, emaste
Differential Revision: https://reviews.freebsd.org/D21696
The debug level generally just controls verbosity of libusb for debugging
libusb devices/usage. We allow the environment to set the debug level
independent of the application, but the application will always override
this if it explicitly sets the debug level.
Changing the environment is easy, but patching the software to change the
debug level isn't necessarily easy or possible. Further, there's this
write-only debug_fixed variable that would seem to imply that the debug
level should be fixed, but it isn't currently used. Change the logic to use
strtol() so we can detect real 0 vs. conversion failure, then honor
debug_fixed in libusb_set_debug.
Reviewed by: hselasky
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D21877
While FreeBSD's implementation of these expect an int inside of libc, that's an
implementation detail that we can hide from the user as it's the natural
promotion of the current mode_t type and before it is used in the kernel, it's
converted back to the narrower type that's the current definition of mode_t. As
such, documenting int is at best confusing and at worst misleading. Instead add
a note that these args are variadic and as such calling conventions may differ
from non-variadic arguments.
promoted to ints).
- `mode_t` is `uint16_t` (`sys/sys/_types.h`)
- `openat` takes variadic args
- variadic args cannot be 16-bit, and indeed the code uses int
- the manpage currently kinda implies the argument is 16-bit by saying `mode_t`
Prompted by Rust things: https://github.com/tailhook/openat/issues/21
Submitted by: Greg V at unrelenting
Differential Revision: https://reviews.freebsd.org/D21816
Summary: When powerpc64 switches to LLVM, use this patch to enable
OpenMP as well. OpenMP on PPC is only for 64-bits, so don't make a
32-bit libomp. A change to openmp files is necesssary (under review on
https://reviews.llvm.org/D67190), because it determines ELF format
version based on endianness, which is incorrect.
Reviewed by: alfredo.junior_eldorado.org.br, #manpages
Differential Revision: https://reviews.freebsd.org/D21532
Add an atomic shm rename operation, similar in spirit to a file
rename. Atomically unlink an shm from a source path and link it to a
destination path. If an existing shm is linked at the destination
path, unlink it as part of the same atomic operation. The caller needs
the same permissions as shm_unlink to the shm being renamed, and the
same permissions for the shm at the destination which is being
unlinked, if it exists. If those fail, EACCES is returned, as with the
other shm_* syscalls.
truss support is included; audit support will come later.
This commit includes only the implementation; the sysent-generated
bits will come in a follow-on commit.
Submitted by: Matthew Bryan <matthew.bryan@isilon.com>
Reviewed by: jilles (earlier revision)
Reviewed by: brueffer (manpages, earlier revision)
Relnotes: yes
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D21423
Described in [1], signal handlers running in a vfork child have
opportunities to corrupt the parent's state. Address this by adding a new
rfork(2) flag, RFSPAWN, that has vfork(2) semantics but also resets signal
handlers in the child during creation.
x86 uses rfork_thread(3) instead of a direct rfork(2) because rfork with
RFMEM/RFSPAWN cannot work when the return address is stored on the stack --
further information about this problem is described under RFMEM in the
rfork(2) man page.
Addressing this has been identified as a prerequisite to using posix_spawn
in subprocess on FreeBSD [2].
[1] https://ewontfix.com/7/
[2] https://bugs.python.org/issue35823
Reviewed by: jilles, kib
Differential Revision: https://reviews.freebsd.org/D19058
When RFSPAWN is passed, rfork exhibits vfork(2) semantics but also resets
signal handlers in the child during creation to avoid a point of corruption
of parent state from the child.
This flag will be used by posix_spawn(3) to handle potential signal issues.
Reviewed by: jilles, kib
Differential Revision: https://reviews.freebsd.org/D19058
C/C++) in exp(3), expf(3), expm1(3) and expm1f(3) during intermediate
computations that compute the IEEE-754 bit pattern for |2**k| for
integer |k|.
The implementations of exp(3), expf(3), expm1(3) and expm1f(3) need to
compute IEEE-754 bit patterns for 2**k in certain places. (k is an
integer and 2**k is exactly representable in IEEE-754.)
Currently they do things like 0x3FF0'0000+(k<<20), which is to say they
take the bit pattern representing 1 and then add directly to the
exponent field to get the desired power of two. This is fine when k is
non-negative.
But when k<0 (and certain classes of input trigger this), this
left-shifts a negative number -- an operation with undefined behavior in
C and C++.
The desired semantics can be achieved by instead adding the
possibly-negative k to the IEEE-754 exponent bias to get the desired
exponent field, _then_ shifting that into its proper overall position.
(Note that in case of s_expm1.c and s_expm1f.c, there are SET_HIGH_WORD
and SET_FLOAT_WORD uses further down in each of these files that perform
shift operations involving k, but by these points k's range has been
restricted to 2 < k <= 56, and the shift operations under those
circumstances can't do anything that would be UB.)
Submitted by: Jeff Walden, https://github.com/jswalden
Obtained from: https://github.com/freebsd/freebsd/pull/411
Obtained from: https://github.com/freebsd/freebsd/pull/412
MFC after: 3 days
memfd_create is effectively a SHM_ANON shm_open(2) mapping with optional
CLOEXEC and file sealing support. This is used by some mesa parts, some
linux libs, and qemu can also take advantage of it and uses the sealing to
prevent resizing the region.
This reimplements shm_open in terms of shm_open2(2) at the same time.
shm_open(2) will be moved to COMPAT12 shortly.
Reviewed by: markj, kib
Differential Revision: https://reviews.freebsd.org/D21393
bde reports (in a reply to r351700 commit mail):
This uses scasb, which was last optimal on the 8086, or perhaps the
original i386. On freefall, it is several times slower than the
naive translation of the naive C code.
Reported by: bde
Reviewed by: kib, markj
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D21785
If robust mutex' owner terminated, causing kernel-assisted state
recovery, and then pthread_mutex_destroy() is executed as the next
action, assert is triggered about mutex still being on the list.
Ignore the mutex linkage in pthread_mutex_destroy() for shared robust
mutexes with dead owner, same as for enqueue_mutex().
Reported by: avg
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
The two options are
* nocover/cover: Prevent/allow mounting over an existing root mountpoint.
E.g., "mount -t ufs -o nocover /dev/sd1a /usr/local" will fail if /usr/local
is already a mountpoint.
* emptydir/noemptydir: Prevent/allow mounting on a non-empty directory.
E.g., "mount -t ufs -o emptydir /dev/sd1a /usr" will fail.
Neither of these options is intended to be a default, for historical and
compatibility reasons.
Reviewed by: allanjude, kib
Differential Revision: https://reviews.freebsd.org/D21458
Add support for kernel threads in kvm_getprocs() and the underlying
kvm_proclist() in libkvm when fetching from a kernel core file. This
has been missing/needed for several releases, when kernel threads became
normal threads. The loop over the processes now contains a sub-loop for
threads, which iterates beyond the first thread only when threads are
requested. Also set some fields such as tid that were previously
uninitialized.
Reviewed by: vangyzen jhb(earlier revision)
MFC after: 4 days
Sponsored by: Forcepoint LLC
Differential Revision: https://reviews.freebsd.org/D21461
There is no trivial way to mark single libarchive test skip currently so just
add it to BROKEN_TESTS for now.
PR: 240683
Sponsored by: The FreeBSD Foundation
BERI stands for Bluespec Extensible RISC Implementation, based on MIPS.
BERI has not implemented standard MIPS perfomance monitoring counters,
instead it provides statistical counters.
BERI statcounters have a several limitations:
- They can't be written
- They don't support start/stop operation
- None of hardware interrupt is provided on a counter overflow.
So make it separate to hwpmc_mips module and support process/system
counting mode only.
Sponsored by: DARPA, AFRL
Note that old pkg will failed to build after this. A recent ports tree (one
providing pkg 1.12+) is required to build. Older already built pkg, should
continue working as expected
PR: 238797
Exp run by: antoine
Reviewed by: cem
Approved by: cem
Differential Revision: https://reviews.freebsd.org/D20752
has become very trigger-happy with libc++ 9.0.0.
It does not help that gcc's implementation of this warning is even more
trigger-happy, in the sense that it already warns on the declaration
itself, not when you are using it. This is very annoying with our use
of -Wsystem-headers. That should really be disabled for gcc.
calls to max allowed UDP datagram size.
Since max allowed size both for keys and values where increased, the
old sizes of around 1K cause ypmatch(3) failures, while plain maps
fetches work.
The buffers were reduced in r34146 from default UDP rpcclient values
to 1024/2304 due to the key and value size being 1K.
Reviewed by: slavash
Sponsored by: Mellanox Technologies
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D21586
std::auto_ptr in a whole bunch of individual Makefiles, make the warning
globally non-fatal instead. This is similar to what was done to many
more non-fatal warnings from newer gcc versions.
- Fix the statement that big5 is a de facto standard of Traditional Chinese
text [1]
- Add a BUGS section describes the problem of big5 and suggests use utf8
PR: 189095
Submitted by: Brennan Vincent <brennan@umanwizard.com> [1]
Reviewed by: Ting-Wei Lan <lantw44@gmail.com>
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D21622
I/O requests after the given number have been allowed though.
Approved by: imp (mentor)
Reviewed by: rpokala kib 0mp mckusick
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D21593
It turns out that parts of the common sanitizer code still do not
compile for arm and aarch64, at least not on FreeBSD, so for now those
are all limited to amd64, and sometimes i386.
This version bring many fixes regarding unicode support
It also adds proper support for filename completion (we do not need our custom
patches anymore)
Improves the libreadline compatibility
Note that the same work was done by Yuichiro Naito in
https://reviews.freebsd.org/D21196 the main difference is in this case we have
reimported libedit in contrib to fix a long standing mess in the previous merges
which prevented a proper update workflow. (discussed long ago with pfg@)
The only difference with upstream libedit is we have added a compatibility shim
for the _elf_fn_sh_complete function which we previously added to support quoting
in filename completion and is not needed anymore.
This was added to continue supported old /bin/sh binaries and not break backward
compatibility (as discussed with jilles@)
Reviewed by: Yuichiro Naito <naito.yuichiro_gmail.com>
MFC after: 3 weeks
Differential Revision: https://reviews.freebsd.org/D21584
When ifuncs are used in statically linked binaries, the C runtime
must perform the needed dynamic relocations, to make calls to ifuncs
work correctly.
Reviewed by: jhibbits
Differential Revision: https://reviews.freebsd.org/D21070
When SO_TIMESTAMP is set, the kernel will attempt to attach a timestamp as
ancillary data to each IP datagram that is received on the socket. However,
it may fail, for example due to insufficient memory. In that case the
packet will still be received but not timestamp will be attached.
Reviewed by: kib
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D21607
This was used to store the mtime of the source file in a commment in a
generated header file. This is of little-to-no diagnostic value and
the result doesn't even end up in the source tree.
Reported by: arichardson
Reviewed by: arichardson
MFC after: 1 days
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D21605
heap buffer overflow. This was discovered by a Google fuzzer test.
This can lead to remote denial of service. User interaction and
execution privileges are not a prerequisite for exploitation.
Reported by: enh at Google, to FreeBSD by maya@NetBSD.org
Obtained from: enh at Google
See also: NetBSD ns_name.c r1.12
Reviewed by: delphij, ume
MFC after: 3 days
https://android-review.googlesource.com/c/platform/bionic/+/1093130
Differential Revision: https://reviews.freebsd.org/D21523
This is a simple set of VHT channels and flags for the FCC (US) regulatory
domain. This needs to be researched and done for the rest of the
regulatory domains, but this should at least unblock some more ath10k
testing.
The default package use to be FreeBSD-runtime but it should only contain
binaries and libs enough to boot to single user and repair the system, it
is also very handy to have a package that can be tranform to a small mfsroot.
So create a new package named FreeBSD-utilities and make it the default one.
Also move a few binaries and lib into this package when it make sense.
Reviewed by: bapt, gjb
Differential Revision: https://reviews.freebsd.org/D21506
All of them are needed to be able to boot to single user and be able
to repair a existing FreeBSD installation so put them directly into
FreeBSD-runtime.
Reviewed by: bapt, gjb
Differential Revision: https://reviews.freebsd.org/D21503
It make sense to have everything bluetooth related in the same package.
Reviewed by: bapt, gjb
Differential Revision: https://reviews.freebsd.org/D21502
A lot of binaries present in FreeBSD-runtime depend on it so move
the libs there.
Reviewed by: bapt, gjb
Differential Revision: https://reviews.freebsd.org/D21501
GEOM is supposed to be topology-agnostic, but the GPT and BSD partition code
has arbitrary restrictions on nesting that are annoying in cases such as
running VMs on raw partitions (since the VM's partitioning scheme is not
visible to the host).
This patch adds sysctls to disable the restrictions except in the case of
BSD label (and similar) partitions with offset 0 (where we need to avoid
recursively recognizing the label).
Submitted by: Andrew Gierth
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D21350
It allows a process to request that stack gap was not applied to its
stacks, retroactively. Also it is possible to control the gaps in the
process after exec.
PR: 239894
Reviewed by: alc
Sponsored by: The FreeBSD Foundation
Differential revision: https://reviews.freebsd.org/D21352
Previously userspace would issue one syscall to resolve the sysctl and then
another one to actually use it. Do it all in one trip.
Fallback is provided in case newer libc happens to be running on an older
kernel.
Submitted by: Pawel Biernacki
Reported by: kib, brooks
Differential Revision: https://reviews.freebsd.org/D17282
