This makes use of the alternate address space support in both GCC and
clang to access per-CPU data as accesses relative to GS:. The
original motivation for this is that it quiets verbose warnings from
GCC 12. However, this version is also much easier to read and
allows the compiler to generate better code (e.g. the compiler can
use a GS: memory operand directly in other instructions such as IMUL
and CMP rather than always MOVing to a temporary register).
The one caveat is that the current approach is very inefficient at -O0
since the compiler expects to load the 0 base offset from a global
variable instead of assuming it is 0 (even with the const).
Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D40647
Update its mtree entry.
Reviewed by: christos, markj
Fixes: 911f026039 dtrace: move kinst tests to common
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40901
This can be run inside a bhyve guest to query the value of fwctl
nodes. Note that fwctl in bhyve only supports a single hw.ncpu node.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D40803
The right unwinding stop indicator should be CFI-undefined PC.
https://dwarfstd.org/doc/Dwarf3.pdf - page 118:
If a Return Address register is defined in the virtual unwind table,
and its rule is undefined (for example, by DW_CFA_undefined), then
there is no return address and no call address, and the virtual
unwind of stack activations is complete.
Reviewed by:
Differential Revision: https://reviews.freebsd.org/D40623
Strictly speaking, SYS V Aarch64 ABI does not states that lr should be
cleared, however gdb relies on lr and tryes to unwind stack further.
Reviewed by:
Differential Revision: https://reviews.freebsd.org/D40841
1. Add a stop indicator to rtld_start to satisfy unwinders on aarch64:
The right unwinding stop indicator should be CFI-undefined PC.
https://dwarfstd.org/doc/Dwarf3.pdf - page 118:
If a Return Address register is defined in the virtual unwind table,
and its rule is undefined (for example, by DW_CFA_undefined), then
there is no return address and no call address, and the virtual
unwind of stack activations is complete.
2. Add a proper annotations for CFA.
That is allows gdb and libunwind successfully stop when unwinding stack
from global constructors and destructors.
Reviewed by:
Differential Revision: https://reviews.freebsd.org/D40844
Use the LDP (load pair registers) instruction to load entry point
arguments from the stack.
Reviewed by:
Differential Revision: https://reviews.freebsd.org/D40843
Normally, modern unwinders uses Dwarf information to unwind stack,
however in case when the code is not annotated by Dwarf instructions,
unwinders fallbacks to a frame-pointer based algorithm.
That is allows libunwind to unwind stack from global constructors and
destructors. Also it makes gdb happy as it printed nonexistent frame
before.
Reviewed by:
Differential Revision: https://reviews.freebsd.org/D40842
In most cases, usage does not return, so mark them as __dead2. For the
cases where they do return, they have not been marked __dead2.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/735
In most cases, usage does not return, so mark them as __dead2. For the
cases where they do return, they have not been marked __dead2.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/735
In most cases, usage does not return, so mark them as __dead2. For the
cases where they do return, they have not been marked __dead2.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/735
In most cases, usage does not return, so mark them as __dead2. For the
cases where they do return, they have not been marked __dead2.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/735
In most cases, usage does not return, so mark them as __dead2. For the
cases where they do return, they have not been marked __dead2.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/735
In most cases, usage does not return, so mark them as __dead2. For the
cases where they do return, they have not been marked __dead2.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/735
In most cases, usage does not return, so mark them as __dead2. For the
cases where they do return, they have not been marked __dead2.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/735
In most cases, usage does not return, so mark them as __dead2. For the
cases where they do return, they have not been marked __dead2.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/735
In most cases, usage does not return, so mark them as __dead2. For the
cases where they do return, they have not been marked __dead2.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/735
In most cases, usage does not return, so mark them as __dead2. For the
cases where they do return, they have not been marked __dead2.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/735
In most cases, usage does not return, so mark them as __dead2. For the
cases where they do return, they have not been marked __dead2.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/735
In most cases, usage does not return, so mark them as __dead2. For the
cases where they do return, they have not been marked __dead2.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/735
In most cases, usage does not return, so mark them as __dead2. For the
cases where they do return, they have not been marked __dead2.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/735
In most cases, usage does not return, so mark them as __dead2. For the
cases where they do return, they have not been marked __dead2.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/735
In most cases, usage does not return, so mark them as __dead2. For the
cases where they do return, they have not been marked __dead2.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/735
Replace the 'count' field in a trie node with a bitmap that
identifies non-NULL children. Drop the 'last' field, and use the
last bit set in the bitmap instead. In lookup_le, lookup_ge,
remove, and reclaim_all, use the bitmap to find the
previous/next/only/every non-null child in constant time by
examining the bitmask instead of looping across array elements
and null-checking them one-by-one.
A buildworld test suggests that this reduces the cycle count on
those functions that eliminate some null-checks by 4.9%, 1.5%,
0.0% and 13.3%.
Reviewed by: alc
Tested by: pho
Differential Revision: https://reviews.freebsd.org/D40775
vmspace_free() is called redundantly in the 32-bit-compatible
path in sysctl_kern_proc_vm_layout(), causing a premature free
(possibly for the current address space). Remove the extra call.
PR: 272401
Reported by: marklmi at yahoo.com
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D40908
This kind of quoting doesn't work, no idea why shellcheck wanted this.
If there is a "safer" way to "fix" this feel free to do it just test
that it's working after.
Reported by: Kenneth Raplee <kenrap@kennethraplee.com>
Sponsored by: Beckhoff Automation GmbH & Co. KG
Fixes: 7ad4d94d5b ("Fix some shell issues by adding quotes and replace backticks with $()")
When saving log files in RFC 5424 format presence of STRUCTURED-DATA
in message caused line to not appear in log file at all, because
a variable forgotten to initialize. This could be tested by (slightly
modified) example from RFC:
echo '<165>1 2003-10-11T22:14:15.003Z mymachine.example.com su 12345 ID47 [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"][id@2 test="tast"] BOM"su root" failed for lonvick on /dev/pts/8" ' | nc -w1 -Uu /var/run/log
While here, update stale information in comment to logmsg() that RFC 5424
log format was not supported.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/717
Refactor to eliminate duplicated rate and delay tables, with minor style
tweaks for changed lines. Remove an obsolete comment about needing to
convert from microseconds to ticks (that's done elsewhere). Remove
traiing whitespace in kbdcontrol.c.
Except for the new warning, no change in behavior
Sponsored by: DSS GmbH
Reviewed by: imp [minor style tweaks as well]
Pull Request: https://github.com/freebsd/pull/683
Differential Revision: https://reviews.freebsd.org/D38818
The layout of modspecific_t on both little endian and big endian are as
follows:
|0|1|2|3|4|5|6|7|
+-------+-------+
|uintval| |
+-------+-------+
|ulongval |
+-------+-------+
For the following code snippet:
CP(mod->data, data32, longval);
CP(mod->data, data32, ulongval);
It only takes care of little endian platforms that it truncates the
highest 32bit automatically. However on big endian platforms it takes
the highest 32bit instead. This eventually returns a garbage syscall
number to the 32bit userland.
Since modspecific_t's usage currently is for the use of syscall modules,
we only initialize modspecific32_t with uintval. Now on both BE and LE
64-bit platforms it always pick up the first 4 bytes.
Sponsored by: Juniper Networks, Inc.
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D40814
MFC after: 1 week
This patch fixes a bug which prevents building libthr without
_PTHREADS_INVARIANTS defined. The default remains to build libthr
with -D_PTHREADS_INVARIANTS. However, with this patch, if one builds
libthr with WITHOUT_PTHREADS_ASSERTIONS=true then the latency to
acquire+release a default pthread mutex is reduced by roughly 5%, and a
robust mutex by roughly 18% (as measured by a simple synthetic test on a
Xeon E5-2697a based machine).
Reviewed by: jhb, kib, mjg
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D40900
As noted in the comment, we already know the rest of libbe_init() will
fail because there's no pool imported. Avoid the side effect by
checking beforehand and bailing out early.
With this, freebsd-update(8) should no longer trigger a load of the zfs
kmod just because it runs `bectl check`.
Reviewed by: jwmaag_gmail.com, rew
Differential Revision: https://reviews.freebsd.org/D36188
To enable faster debug of customer issues Intel wants an end user to
gather information about PHY configuration and status to debug link and
connection issues in the field. For this reason the end user should
have possibility of obtaining PHYs registers values at runtime during
debugging.
Differential Revision: https://reviews.freebsd.org/D40354
Approved by: erj
flsll is inlined, or replaced by a smart binary search implementation,
on all architectures, and HAVE_INLINE_FLSLL is #defined always. So
remove code the the #undefined case.
Reviewed by: mhorne, tuexen
Differential Revision: https://reviews.freebsd.org/D40704
There is no longer be any point to maintaining a binary search routine
for ffs; inlines will always do it as well or better.
Reviewed by: mhorne
Differential Revision: https://reviews.freebsd.org/D40703
HAVE_INLINE_FLSLL is #defined always. This change assumes that where
__HAVE_INLINE_FLSLL is tested, the two leading underscores are a
mistake, and that the code will be better for using the efficient
flsll implementation.
Reviewed by: markj, mhorne
Differential Revision: https://reviews.freebsd.org/D40705
HAS_INLINE_FLS and similar macros are defined always.
Removes the redundant tests for these always-true conditions.
Reviewed by: mhorne
Differential Revision: https://reviews.freebsd.org/D40707
These are poorly optimized (linear search), and we now prefer the
compiler-provided routines on all platforms. These files can be removed.
Reviewed by: emaste, dougm
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40699
Use of compiler builtin ffs/ctz functions will result in optimized
instruction sequences when possible, and fall back to calling a function
provided by the compiler run-time library. We have slowly shifted our
platforms to take advantage of these builtins in 60645781d6 (arm64),
1c76d3a9fb (arm), 9e319462a0 (powerpc, partial).
Some platforms still rely on the libkern implementations of these
functions provided by libkern, namely riscv, powerpc (ffs*, flsll), and
i386 (ffsll and flsll). These routines are slow, as they perform a
linear search for the bit in question. Even on platforms lacking
dedicated bit-search instructions, such as riscv, the compiler library
will provide better-optimized routines, e.g. by using binary search.
Consolidate all definitions of these functions (whether currently using
builtins or not) to libkern.h. This should result in equivalent or
better performing routines in all cases.
One wart in all of this is the existing HAVE_INLINE_F*** macros, which
we use in a few places to conditionally avoid the slow libkern routines.
These aren't easily removed in one commit. For now, provide these
defines unconditionally, but marked for removal after subsequent
cleanup.
Removal of the now unused libkern routines will follow in the next
commit.
Reviewed by: dougm, imp (previous version)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40698
Simply speaking, being started the drm-kmod driver should create sysfs helpers,
which is «drm» class devices, with the unit number 0, 128 and, perhaps 64.
If a drm helper created by vgapci driver with the corresponding unit number
exists then the drm-kmod driver initialize it by the device_initialize() lkpi
method, otherwise drm-kmod driver create new «drm» device.
For hw, where two or more different GPU installed, it's not guaranteed that
the order of loading GPU drivers will be the same as the vgapci devices numbered.
I.e., on hw where vgapci0 is Nvidia GPU and vgapci1 is Intel GPU, when drm-kmod
loaded first it will use drm0 helper of vgapci0 device.
There is no problem for drm-kmod driver unless we do not traverse device
tree, as needed for https://reviews.freebsd.org/D38545.
drm-kmod is ok for this change as it has fallback to create corresponding
drm device.
Reviewed by:
Differential Revision: https://reviews.freebsd.org/D38546
This is historical (?), but today /compat is the default according to
linux(4). The only remaining reference to /usr/compat in the src tree is
under tools/test/stress2.
Add a next-level entry for /compat/linux.
PR: 261349
Reviewed by: grahamperrin, karels, dchagin
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D40876
