contrib/lutok: remove autotools generated files
These files provide no value in the FreeBSD tree proper and change
frequently, depending on what machine I generate the release tarball on
(and what versions of autotools are on the host). Nuke the autogenerated
files to avoid bloating commit history/the tree.
MFC after: 3 days
Requested by: Benjamin Jacobs <freebsd at dev.thsi.be>
(cherry picked from commit cfe443e1e63dd588fba7eabec553ed5e1c408d1f)
contrib/atf: upgrade to 0.26
This new version gets contrib/atf in line with the published version of
the package up on [GitHub][github].
Please note that this release is a major update: it contains several
bugfixes and feature enhancements. Most were already present in the
FreeBSD src repo, but there were a large number of changes made in
addition to what was already present.
MFC after: 1 month
Merge commit '9c78088348bcf1059d82a62bb57a0746309d4312'
(cherry picked from commit 952231086100bed7130212b5425e44ffd732913b)
[github]: https://github.com/freebsd/atf
build: install NextBSD packages with NextBSD's pkg-static
The NextBSD repository now carries the NextBSD ABI (NextBSD:27:<arch>,
OSVERSION 2700000), and the build VM's stock pkg refuses it ("wrong
architecture: NextBSD:27:aarch64 instead of FreeBSD:15:aarch64").
Install NextBSD-everything, the pkglist.txt packages and the residue
clean with nextbsd-contrib's pkg-static, the same tool nextbsd-pkg uses,
with ABI=NextBSD:27:<arch> (aarch64 on arm64) and OSVERSION=2700000. The
workflow downloads the amd64 pkg-static from nextbsd-contrib's continuous
release for both build jobs (amd64/arm64 and rpi5); a hand run fetches
it. The FreeBSD:15 ABI pin and the VM's uname -K OSVERSION are gone, so
the image's package database carries the ABI its own pkg computes.
Refs nextbsd/nextbsd-kernel#376
Co-Authored-By: Claude Opus 5.5 <noreply at anthropic.com>
tests/libc: only build brk_test where libc provides sbrk
Replace the exclusion list with an allowlist of the architectures
whose libc exports brk/sbrk: amd64, i386, arm and powerpc.
On aarch64, riscv and loongarch libc does not export those symbols
and the test cannot run, so do not build it there. New architectures
now default to not building the test unless brk support is added.
MFC after: 1 week
Signed-off-by: Xiaoqiang Zhao <zhaoxiaoqiang007 at gmail.com>
Reviewed by: ngie
Differential Revision: https://reviews.freebsd.org/D60357
(cherry picked from commit 8a7df6c58d549bd2eaa5cad30b2ef93c3eca3c18)
LinuxKPI: firmware: remove `enoentok` logic in `*firmware_request(..)`
Prior to this change, in the event that a firmware module could not be
loaded, the linux_firmware driver would return a partially initialized
structure with uninitialized/zeroed out values for certain fields. Linux
does not do this, however, so some drivers that use
`request_firmware_nowait` expecting Linux behavior, like `if_bcrmfmac`,
would crash trying to dereference a NULL pointer.
This doesn't address the load/unload situation completely as the driver
remains loaded after the "firmware crashes", but it makes a completely
unusable situation (a kernel panic) into a slightly more usable situation
(driver does not unload).
As a sidenote: the raw free(9) call was replaced with a call to
`linuxkpi_release_firmware` because the latter call [better] ensures
that all resources allocated earlier on in the function are cleaned up.
MFC after: 1 weeks
[4 lines not shown]
LinuxKPI: firmware: remove `enoentok` logic in `*firmware_request(..)`
Prior to this change, in the event that a firmware module could not be
loaded, the linux_firmware driver would return a partially initialized
structure with uninitialized/zeroed out values for certain fields. Linux
does not do this, however, so some drivers that use
`request_firmware_nowait` expecting Linux behavior, like `if_bcrmfmac`,
would crash trying to dereference a NULL pointer.
This doesn't address the load/unload situation completely as the driver
remains loaded after the "firmware crashes", but it makes a completely
unusable situation (a kernel panic) into a slightly more usable situation
(driver does not unload).
As a sidenote: the raw free(9) call was replaced with a call to
`linuxkpi_release_firmware` because the latter call [better] ensures
that all resources allocated earlier on in the function are cleaned up.
MFC after: 1 weeks
[4 lines not shown]
[SLP]Vectorize loads from the single predecessor block
Model loads from the single predecessor block as copyable elements of a
consecutive load node in the successor block. The wide load covers them
if their memory is not modified after them in the predecessor block or
anywhere in the successor block.
Fixes #43232
Assisted-by: Cursor
Reviewers: RKSimon, bababuck
Pull Request: https://github.com/llvm/llvm-project/pull/233297
[tests] lib/libc/gen:assert_test: undefine `NDEBUG`
In the event `NDEBUG` was defined, `assert` would become a no-op,
breaking some of the expectations in `assert_test` around `assert(..)`
failing generating a coredump.
This is a better approach than the previous one committed in 6f3445006a
as it continues to test the `assert(..)` function instead of just
skipping it if `NDEBUG` was defined.
Suggested by: kevans
MFC after: 4 days
MFC with: 6f3445006a
Fixes: 6f3445006a
Differential Revision: https://reviews.freebsd.org/D60253
(cherry picked from commit 9d5a33d9c294b01cead6ff65b0773b5b5ab85ccd)
[tests] lib/libc/gen:assert_test: skip tests when NDEBUG set
In the event that NDEBUG is specified in CFLAGS--which is most likely
triggered via `MK_ASSERT_DEBUG` == "no" -- all assert(3) statements are
optimized out by design. This breaks the assert(3) tests as they
specifically rely on assert(3) actually raising a `SIGABRT` instead of
quietly succeeding.
Skip both tests if `NDEBUG` is set. There's no sense running the
`assert(true)` test if the result could instead be a false positive.
MFC after: 2 weeks
(cherry picked from commit 6f3445006aa05550f14af65b04276c3d25169941)
[tests] lib/libc/gen:assert_test: skip tests when NDEBUG set
In the event that NDEBUG is specified in CFLAGS--which is most likely
triggered via `MK_ASSERT_DEBUG` == "no" -- all assert(3) statements are
optimized out by design. This breaks the assert(3) tests as they
specifically rely on assert(3) actually raising a `SIGABRT` instead of
quietly succeeding.
Skip both tests if `NDEBUG` is set. There's no sense running the
`assert(true)` test if the result could instead be a false positive.
MFC after: 2 weeks
(cherry picked from commit 6f3445006aa05550f14af65b04276c3d25169941)
[tests] lib/libc/gen:assert_test: undefine `NDEBUG`
In the event `NDEBUG` was defined, `assert` would become a no-op,
breaking some of the expectations in `assert_test` around `assert(..)`
failing generating a coredump.
This is a better approach than the previous one committed in 6f3445006a
as it continues to test the `assert(..)` function instead of just
skipping it if `NDEBUG` was defined.
Suggested by: kevans
MFC after: 4 days
MFC with: 6f3445006a
Fixes: 6f3445006a
Differential Revision: https://reviews.freebsd.org/D60253
(cherry picked from commit 9d5a33d9c294b01cead6ff65b0773b5b5ab85ccd)
share/mk/bsd.confs.mk: fix trivial typo in message
The error message noting that the file should not be included said
"bsd.conf.mk" before this change. Now it correctly says "bsd.confs.mk".
MFC after: 3 days
(cherry picked from commit a3214d4e9b661fb173fc25b06b7ee9902b0b57e3)
share/mk/bsd.confs.mk: fix trivial typo in message
The error message noting that the file should not be included said
"bsd.conf.mk" before this change. Now it correctly says "bsd.confs.mk".
MFC after: 3 days
(cherry picked from commit a3214d4e9b661fb173fc25b06b7ee9902b0b57e3)
clk: add config(5) entry for `rk_clk_mmc.c`
This is needed in order to unbreak the build on armv7.
Reported by: Jenkins
Fixes: e32b082ba28b ("clk: rockchip: Add the MMC phase clock")
atf/FREEBSD-upgrade: update document/rewrite in Markdown
The document does not reflect current reality with how updates/releases
should be managed with contrib/atf . Update it to a state that better
reflects current practices with git, as well as information about where
the latest version of the project can be found, etc.
This change will be used as a template for adding instructions on how to
update contrib/kyua and contrib/lutok in future commits.
MFC after: 1 month
Reviewed by: ziaee, carlavilla
Differential Revision: https://reviews.freebsd.org/D59879
