The quantum cache is disabled, there is no uma.
Intent is to use this for resource allocation in bhyve(8), for start.
Addition of -luvmem to bhyve linking was done to test changes to share/mk.
Reviewed by: bnovkov, markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D27220
Otherwise the directory created by etc/mtree/BSD.tests.dist, which is
where these belong, and referred to by the generated Kyuafile for
/usr/tests/lib/libc (via stdbit's existence in TESTS_SUBDIRS), ends up
empty with no Kyuafile, which is an error for kyua.
Reported by: kp
Fixes: 2fb8cbc6ef ("libc/tests: add stdbit test framework and unit tests")
This adds unit tests for all 70 functions in <stdbit.h>.
I'm sorry for the test framework, but it makes it so I don't
have to write 70 unit tests by hand.
Reviewed by: adrian, des
Approved by: markj (mentor)
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D53660
This adds man pages for each group of functions in <stdbit.h>.
The man pages have cross references to one-another.
Cross references from external man pages to these will be added
in a later commit.
Reviewed by: pauamma@gundo.com, kib
Approved by: markj (mentor)
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D53659
This new header complies with ISO/IEC 9899:2024 (C23).
Contrary to glibc, we do not provide inline definitions in
<stdbit.h> as we expect our system compiler to soon recognise
these as builtins anyway.
Relnotes: yes
MFC after: 1 month
Reviewed by: adrian
Approved by: markj (mentor)
Differential Revision: https://reviews.freebsd.org/D53657
This file checks the correctness of the various _MAX, _MIN, and
_WIDTH macros defined for the libc types. It assumes that none
of the types have padding bits.
Approved by: markj (mentor)
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D53831
In 986e05bc2a I revamped the build for all the llvm subprojects. Among
others I added objects under contrib/llvm-project/llvm/lib/TableGen, but
I missed that upstream explicitly removes these when building the shared
llvm library:
https://github.com/llvm/llvm-project/blob/llvmorg-19.1.7/llvm/tools/llvm-shlib/CMakeLists.txt#L23
In 2e47f35be5 I converted libllvm to a shared library. From that point
onwards, some of the global command line option objects registered in
llvm/lib/TableGen/Main.cpp conflict with similar objects in tools like
llvm-cov, llvm-as, etc.
This results in an error when running these tools: "CommandLine Error:
Option 'o' registered more than once!", followed by a fatal exit.
Fix this by removing the TableGen objects from libllvm. Note that we no
longer install any of the tblgen binaries, these are only used during
buildworld, and then in a statically linked form.
PR: 291233
MFC after: 3 days
verify_prep can return VE_FINGERPRINT_NONE. Consider such scenario so
the VE_GEUSS heuristics works with files that likely will not have
fingerprints in the manifest file.
Obtained from: Hewlett Packard Enterprise
Reviewed by: sjg
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D53940
If the locale's positive_sign and negative_sign values would both be
returned by localeconv() as empty strings, strfmon() shall behave as if
the negative_sign value was the string "-".
This occurs with the C locale. The implementation previously assigned
"0" to sign_posn (parentheses around the entire string); now it assigns
it to "1" (sign before the string) when it is undefined (CHAR_MAX).
Austin Group Defect 1199[1] is applied, changing the requirements for
the '+' and '(' flags.
[1]: https://www.austingroupbugs.net/view.php?id=1199
Reviewed by: kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D53913
Add tests for The Open Group Base Specifications Issue 8[1], Austin
Group Defect 1199[2].
Items marked with XXX represent an invalid output. These items will be
fixed in subsequent commits.
Notice that an existing test is now considered invalid.
Our locale definitions do not include int_p_sep_by_space nor
int_n_sep_by_space[3]. Those will be addressed in a subsequent commit.
However, the CLDR project defines them as "0", which causes the output
to appear as "USD123.45". If our locale definitions were to set the
international {n,p}_sep_by_space to "1", the output would display as the
expected "USD 123.45".
While here, use the SPDX license identifier and add my name to the
file.
[1]: https://pubs.opengroup.org/onlinepubs/9799919799/functions/strfmon.html
[2]: https://www.austingroupbugs.net/view.php?id=1199
[3]: https://unicode-org.atlassian.net/browse/CLDR-237
Reviewed by: kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D53911
This commit introduces gratuitous white space and unused functions.
This functionality is guarded/commented out. This change is necessary
to reduce the differences with the reference file in subsequent commits.
No functional change intended.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1894
Fix typos in the files that are owned by the project.
Bring back a "duplicate word" removal (node node), which should have
been "node Node", the second "node" is not capitalized in the reference
file (yet). We'll bring it back capitalized to avoid it from triggering
automated checking scripts and possibly reverting this change again. A
few other typos were not fixed, as we strive to keep as close to the
reference files as possible, these fixes should be submitted to the
reference project (tianocore/edk2) in the not so distant future.
Reviewed by: imp
Pull Request: https://github.com/freebsd/freebsd-src/pull/1894
If we fail to open /dev/pf don't try to close it again. That would result in
errno getting overwritten by close(), hiding potentially useful information.
MFC after: 2 weeks
Sponsored by: Rubicon Communications, LLC ("Netgate")
* Always install the manual page as pam_krb5(8) regardless of which
version we're using.
* Regenerate it using pod2mdoc instead of pod2man so it doesn't claim
to be part of “User Contributed Perl Documentation”.
* Put the correct section number in the header and footer.
* Don't cross-reference non-existent pam(7) manual page.
Reviewed by: cperciva
Differential Revision: https://reviews.freebsd.org/D53885
[Driver] Enable outline atomics for FreeBSD/aarch64 (#156089)
The compiler_rt helper functions have been built since 12.4, 13.1, 14
and anything newer.
This reverts commit bd27bd1f51.
Only some people (including the release manager, unfortunately) ran into
build issues with the previous iteration of this commit, because they
were bootstrapping the compiler, either via the WITHOUT_SYSTEM_COMPILER
src.conf(5) setting, or because the build system determined that their
base system compiler was out of date.
The bootstrapped compiler would then enable outline atomics and compile
libgcc_s with these, but because libgcc_s is linked with -nodefaultlibs,
it could not find the helper routines in libcompiler_rt.a.
In contrast, people who did not bootstrap the compiler never saw any
issues, because libgcc_s was built using their 'old' base system
compiler, and so libgcc_s would not contain any calls to those helper
routines.
Fix this by ensuring that libgcc_s is linked against libcompiler_rt.a
explicitly, similar to some other binaries and libraries that are built
with -nodefaultlibs.
Also, bump FREEBSD_CC_VERSION to ensure that everybody gets the updated
compiler with outline atomics enabled. (This should have been done in
the first iteration of this commit, because the error would have shown
up right away then.)
MFC after: 3 days
libarchive 3.8.3
Important bugfixes:
#2753 lib: Create temporary files in the target directory
#2768 lha: Fix for an out-of-bounds buffer overrun when using
p[H_LEVEL_OFFSET]
#2769 7-zip: Fix a buffer overrun when reading truncated 7zip headers
#2771 lz4 and zstd: Support both lz4 and zstd data with leading
skippable frames
Obtained from: libarchive
Vendor commit: 1368b08875351df8aa268237b882c8f4ceb0882d
MFC after: 1 week
- also use new .St -ieee754-2008 request in *pi.3
Reviewed by: imp
Approved by markj (mentor)
See also: D53784
Differential Revision: https://reviews.freebsd.org/D53783
Make libesecureboot build, enabled when WITH_BEARSSL=y
WITH_LOADER_EFI_SECUREBOOT=y.
Copy EDK2 files related to secure boot to sys/contrib/edk2 and delete
duplicates under libsecreboot/efi/include.
Adjust efi_variables.c to build in the new environment.
Undefine MIN and MAX before include sys/param.h in libsecureboot.h. I'm
not sure that sys/param.h is needed here, but either the param.h or the
Base.h definitions are fine.
Fix include paths to reflect the new way.
Fixes: 43b8edb320
Sponsored by: Netflix
Have our own ProcessorBind.h. It just includes sys/efi-edk2.h, but
undefines TRUE, FALSE and MAC. The first two are from acpica and are
redefined to something almost the same. MAC is a global option that,
well, interferes with using EDK2, dangit. I suppose I should redefine it
after, but I don't think you can save the value of a pre-processor
variable.
This breaks a little with the tradition of having this in a seprate
directory and using build magic. However, the build is already magical
enough and having this here makes things less magical. Also, EDK2 puts
this in a processor specific directory, so we won't have conflicts (they
need it there since they run on more processors than we do: we can just
include sys/efi-edk2.h which covers the smallar variance we have in
processors).
Sponsored by: Netflix
Create efi-freebsd.h, which is safe to include from the FreeBSD context
(all of userland, except the small bits we share with edk2 and the
kernel). This defines anything that we need. At the moment, it just
includes NULL definitions.
Create efi-edk2.h, which is approximately ProcessorBind.h from edk2 that
we can include in FreeBSD compontents that are re-using edk2 components
(bits of the boot laoder, and libefi*). Update the efi_gid definitions
to match edk2 better. Add this file to badfiles.inc, since we can't
write it in a way that's compatible. This is copied from the old
efi-osdep.h.
This has to be done in one commit that's bigger than I like since we
can't easily move things piecemeal around they are so inter-related.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D53651
This new function computes the alignment of a pointer.
It is part of ISO/IEC 9899:2024, the new C standard.
If the pointer is a null pointer, null is returned.
I have tried to write an implementation that can cope
with traditional address-based architectures, even if
size_t and uintptr_t are of different length. Adjustments
may be needed for CHERI though.
A man page is provided, too. No unit test for now.
Reviewed by: kib, imp, ziaee (manpages), pauamma@gundo.com
Approved by: markj (mentor)
MFC after: 1 month
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D53673
OpenPAM is a discrete, largely self-contained system component.
Users may not need PAM for many use-cases (e.g. jails, containers),
so move it to its own package.
Use LIB_PACKAGE to create a separate pam-lib package for libpam,
so that applications that support PAM don't need to bring in all
the PAM modules if PAM isn't actually in use.
Add pam to the minimal sets, since this is a core system component that
people expect to be installed. This means all supported installation
methods will install the PAM modules by default, so don't add explicit
dependencies on the PAM modules from things that use PAM (e.g. runtime),
allowing custom/embedded systems to omit these easily.
This change adds a new package to the system so, until we have a proper
policy on how to handle this in release/stable branches, it should not
be MFC'd.
MFC after: never
Reviewed by: des, bapt
Sponsored by: https://www.patreon.com/bsdivy
Differential Revision: https://reviews.freebsd.org/D53602
These are user-facing manpages, but were installed in the runtime-dev
package since the PAM modules use bsd.lib.mk. Use MANNODEV instead of
MAN to put them in the base runtime package instead.
Fixes: 031e711647 ("packages: Install development manpages in the -dev package")
MFC after: 3 days
Reviewed by: bapt
Sponsored by: https://www.patreon.com/bsdivy
Differential Revision: https://reviews.freebsd.org/D53601