[Midnightbsd-cvs] [MidnightBSD/src] a57248: libc/csu: Unify INIT_RELOCS across architectures
Jessica Clarke
noreply at github.com
Sun Jan 18 16:44:59 EST 2026
Branch: refs/heads/master
Home: https://github.com/MidnightBSD/src
Commit: a572482f9d33ce633142266700d738c531428277
https://github.com/MidnightBSD/src/commit/a572482f9d33ce633142266700d738c531428277
Author: Jessica Clarke <jrtc27 at FreeBSD.org>
Date: 2026-01-18 (Sun, 18 Jan 2026)
Changed paths:
M lib/libc/csu/aarch64/Makefile.inc
M lib/libc/csu/aarch64/reloc.c
M lib/libc/csu/amd64/Makefile.inc
M lib/libc/csu/amd64/reloc.c
M lib/libc/csu/arm/Makefile.inc
M lib/libc/csu/i386/Makefile.inc
M lib/libc/csu/i386/reloc.c
M lib/libc/csu/libc_start1.c
M lib/libc/csu/mips/Makefile.inc
M lib/libc/csu/powerpc/Makefile.inc
M lib/libc/csu/powerpc64/Makefile.inc
M lib/libc/csu/powerpc64/reloc.c
M lib/libc/csu/powerpcspe/Makefile.inc
Log Message:
-----------
libc/csu: Unify INIT_RELOCS across architectures
Some architectures don't need any arguments, whilst others need auxargs,
which they get by passing in env thanks to INIT_RELOCS referencing the
local variable in __libc_start1(_gcrt) by name. This is unnecessarily
confusing, fragile (one has to look at INIT_IRELOCS's definition to see
that it uses env) and duplicates code between architectures.
Instead, implement it more like rtld-elf. Each architecture provides an
ifunc_init that takes the auxargs directly, and those that don't need it
can just ignore it.
Reviewed by: kib
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D47188
(cherry picked from commit 9684658e35ab033c79e0519e3681d9a194976b71)
Commit: 18d962e281e4f725447e33d89696515a263d21f5
https://github.com/MidnightBSD/src/commit/18d962e281e4f725447e33d89696515a263d21f5
Author: Jessica Clarke <jrtc27 at FreeBSD.org>
Date: 2026-01-18 (Sun, 18 Jan 2026)
Changed paths:
M sys/sys/cdefs.h
Log Message:
-----------
sys/cdefs.h: Add comments to make #if/#else/#endif triple more obvious
This block has a lot of nesting, not helped by two adjacent nested
blocks involving _POSIX_C_SOURCE, with only the inner one commented,
looking like it's the end of the outer one. Comment the outer one as
well so it's not quite so hard to figure out.
MFC after: 1 week
(cherry picked from commit 7a3af393d8ac2dfe72d24fe401344b60c4f87866)
Commit: 33dff54b1c0263b3ee6f20188208b8eae0c464df
https://github.com/MidnightBSD/src/commit/33dff54b1c0263b3ee6f20188208b8eae0c464df
Author: David Gilbert <dave at daveg.ca>
Date: 2026-01-18 (Sun, 18 Jan 2026)
Changed paths:
M lib/libutil/hexdump.3
Log Message:
-----------
hexdump.3: Add missing LIBRARY section
All the other libutil section 3 manpages document this, and although
it's heavily implied by the libutil.h header in the synopsis, we should
still be explicit and consistent.
PR: 280078
Reviewed by: jrtc27
MFC after: 1 week
(cherry picked from commit 169e23d41f8ff16244f4fb04924fdc9828325dce)
Commit: 29c74c29d8a7bd03c34d2db63ddb5252ebeeb6bb
https://github.com/MidnightBSD/src/commit/29c74c29d8a7bd03c34d2db63ddb5252ebeeb6bb
Author: Jessica Clarke <jrtc27 at FreeBSD.org>
Date: 2026-01-18 (Sun, 18 Jan 2026)
Changed paths:
M sys/arm64/arm64/gic_v3.c
M sys/arm64/arm64/gic_v3_acpi.c
M sys/arm64/arm64/gic_v3_var.h
Log Message:
-----------
gic_v3: Correctly handle GICC GIGR Base Address case
When using the GICR Base Address field from each GICC structure instead
of GICR structures, the field gives the address of a single
redistributor page. However, that does not mean that they are not
contiguous, and so GICR_TYPER.Last could be clear on them. Thus we must
ignore GICR_TYPER.Last in this case and always treat each region as
having a single page. Normally we'd do that as a result of checking
against the rman's size (though that's a rather roundabout and iffy way
of achieving it), but for whatever reason this is bigger on the Qualcomm
Snapdragon X Elite (I assume the MADT reports GICv4 but TYPER doesn't
report VLPIS and so there is a mismatch between the rman size and the
stride used) and we end up walking off the region's mapping.
Reviewed by: andrew, phk
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D47560
(cherry picked from commit f8c90b704189c94275d22d7cc204d1d74e821d86)
Commit: aae783cfb675b1781744daf03276933d7e1e5a64
https://github.com/MidnightBSD/src/commit/aae783cfb675b1781744daf03276933d7e1e5a64
Author: Jessica Clarke <jrtc27 at FreeBSD.org>
Date: 2026-01-18 (Sun, 18 Jan 2026)
Changed paths:
M sys/dev/ofw/ofw_bus_subr.c
Log Message:
-----------
ofw: Fix inverted bcmp in ofw_bus_node_status_okay
Otherwise this matches any two-character status except for ok.
Fixes: e5e94d2de987 ("Expand OpenFirmware API with ofw_bus_node_status_okay method")
MFC after: 1 week
(cherry picked from commit e1060f6dfd80b34cab6d439bf7420ad686ddc8f1)
Commit: 4d425d4e6522ec957cebfcaf2cc9e5f9e0e4d5ff
https://github.com/MidnightBSD/src/commit/4d425d4e6522ec957cebfcaf2cc9e5f9e0e4d5ff
Author: Jessica Clarke <jrtc27 at FreeBSD.org>
Date: 2026-01-18 (Sun, 18 Jan 2026)
Changed paths:
M lib/libc/gen/tls.c
Log Message:
-----------
libc: Don't bias DTV entries by TLS_DTV_OFFSET
PowerPC and RISC-V have a non-zero TLS_DTV_OFFSET. The intent behind
this in the design is that DTV entries are biased by this, as are (in
the other direction) the DTPOFF/DTPREL entries in the GOT. However, this
is pretty pointless in practice, and both FreeBSD and glibc's run-time
linkers don't bother to bias DTV entries, instead just adding the bias
back on at the end in __tls_get_addr. In libc we also have a minimal
implementation of this for statically-linked binaries, which is only in
practice used for code compiled with -fPIC (not -fPIE) that is also
linked without TLS relaxation support. PowerPC supports linker
relaxation for TLS sequences, so this likely never gets hit there, but
RISC-V does not, and so easily does if you compile an executable with
-fPIC. In this implementation we add TLS_DTV_OFFSET both to the DTV
entries in __libc_allocate_tls and to the result of __tls_get_addr,
meaning that any TLS accesses using the General Dynamic model in static
binaries on RISC-V end up off by 0x800.
Historically this also did not matter as __tls_get_addr was a stub that
always returned NULL, so although 6e16d0bc4376 ("Rework alignment
handling in __libc_allocate_tls() for Variant I of TLS layout.") added
this DTV implementation, nothing actually read the entries. However, now
it's a real implementation, and dl_iterate_phdr also now relies on it,
it does matter.
Fix this by not biasing the DTV entries, just like RTLD. We could
instead stop adding TLS_DTV_OFFSET in __tls_get_addr, but being
consistent between libc and RTLD seems better.
(Note this also applies to MIPS on stable/13)
Reviewed by: kib
Fixes: ca46b5698e8a ("libc: implement __tls_get_addr() for static binaries")
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D50181
(cherry picked from commit d04c93a2adccb4c3a17f7391126a9246326e3fea)
Commit: bd3b824ab2ecbde3acdc41587ced5c52a21bd151
https://github.com/MidnightBSD/src/commit/bd3b824ab2ecbde3acdc41587ced5c52a21bd151
Author: Jessica Clarke <jrtc27 at FreeBSD.org>
Date: 2026-01-18 (Sun, 18 Jan 2026)
Changed paths:
M lib/libc/gen/dlfcn.c
Log Message:
-----------
libc: Fix dl_iterate_phdr's dlpi_tls_data for PowerPC and RISC-V
The implementation of dl_iterate_phdr for statically-linked binaries
abuses __tls_get_addr to get to the start of the TLS block. For most
architectures, tls_index's ti_offset (relocated by DTPOFF/DTPREL for GOT
entries) is just the offset within that module's TLS block. However, for
PowerPC and RISC-V, which have a non-zero TLS_DTV_OFFSET and thus are
designed assuming DTV entries are biased by that value, ti_offset
normally has TLS_DTV_OFFSET pre-subtracted. By using an offset of zero
here we end up getting a pointer TLS_DTV_OFFSET past what __tls_get_addr
would return for the first TLS variable.
Fix this by using -TLS_DTV_OFFSET to mirror what the General Dynamic GOT
entry for the first TLS variable would be.
(Note this also applies to MIPS on stable/13)
Reviewed by: kib
Fixes: dbd2053026a6 ("libc dl_iterate_phdr(): dlpi_tls_data is wrong")
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D50182
(cherry picked from commit 78b99f369f75f5df49b506ae750659b07ab34362)
Commit: 0cb99433d81600376bc764bd8dbf8269f29c6944
https://github.com/MidnightBSD/src/commit/0cb99433d81600376bc764bd8dbf8269f29c6944
Author: Jessica Clarke <jrtc27 at FreeBSD.org>
Date: 2026-01-18 (Sun, 18 Jan 2026)
Changed paths:
M libexec/rtld-elf/rtld.c
Log Message:
-----------
rtld-elf: Fix dlsym(3) for TLS symbols on PowerPC and RISC-V
The implementation here is meant to mirror what a GOT entry for the
given symbol would use for ti_offset. However, on PowerPC and RISC-V,
TLS_DTV_OFFSET is non-zero, and so the GOT entries are normally biased
by this, but we fail to do so here. As a result we end up getting a
pointer TLS_DTV_OFFSET past where the variable actually is.
(Note this also applies to MIPS on stable/13)
Reviewed by: kib
Fixes: 5ceeeba90c6c ("Import DragonFly BSD commit")
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D50183
(cherry picked from commit 8ad9cec3a2cc643020a286ee68f70eb01225fbdd)
Commit: 72b1cc0b8ebd46108fc2cb11ba3cbd5c8b282961
https://github.com/MidnightBSD/src/commit/72b1cc0b8ebd46108fc2cb11ba3cbd5c8b282961
Author: Jessica Clarke <jrtc27 at FreeBSD.org>
Date: 2026-01-18 (Sun, 18 Jan 2026)
Changed paths:
M libexec/rtld-elf/rtld.c
Log Message:
-----------
rtld-elf: Fix dl_iterate_phdr's dlpi_tls_data for PowerPC and RISC-V
The implementation of dl_iterate_phdr abuses tls_get_addr_slow to get to
the start of the TLS block, inlining the implementation of
__tls_get_addr as if the tls_index's ti_offset were 0 (historically it
called __tls_get_addr itself but changed due to locking issues). For
most architectures, tls_index's ti_offset (relocated by DTPOFF/DTPREL
for GOT entries) is just the offset within that module's TLS block.
However, for PowerPC and RISC-V, which have a non-zero TLS_DTV_OFFSET
and thus are designed assuming DTV entries are biased by that value,
ti_offset normally has TLS_DTV_OFFSET pre-subtracted, but it's
__tls_get_addr's responsibility to compensate for that. By using an
offset of zero here, tls_get_addr_slow will return a pointer to the
start of the TLS block itself, so by adding TLS_DTV_OFFSET we will point
TLS_DTV_OFFSET past the module's TLS block.
Fix this by removing the extra bias (the alternative would be to pass
-TLS_DTV_OFFSET and keep the addition, which would more closely follow
what __tls_get_addr does, but this is more direct).
(Note this also applies to MIPS on stable/13)
Reviewed by: kib
Fixes: d36d68161517 ("rtld dl_iterate_phdr(): dlpi_tls_data is wrong")
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D50184
(cherry picked from commit c02aaba1b4549c1c3b1481f7c935f6cc80b98e8d)
Commit: a9569beaabf8eb8cfbaad71b44a3616cf80a0e2f
https://github.com/MidnightBSD/src/commit/a9569beaabf8eb8cfbaad71b44a3616cf80a0e2f
Author: Jessica Clarke <jrtc27 at FreeBSD.org>
Date: 2026-01-18 (Sun, 18 Jan 2026)
Changed paths:
M libexec/rtld-elf/rtld.c
Log Message:
-----------
rtld-elf: Fix UB for direct exec with no extra rtld arguments
If no extra rtld arguments are provided, rtld_argc will be 1 (for
argv[0] and so we are shifting the entire memory range down by a single
pointer. However, unlike argv and envp, auxp's entries are two pointers
in size, not one, and so in this case the source and destination
overlap, meaning simple assignment is UB (C99 6.5.16.1p3). On many
architectures this ends up being harmless as the compiler will emit
double machine word loads and stores, or if it splits them it may still
schedule them such that it works in this case, but our RISC-V baseline
does not include such instructions and LLVM ends up picking a schedule
that copies the second word before the first word, thereby replacing the
first word with a copy of the second word. This results in direct exec
mode segfaulting on RISC-V when given no arguments.
Fix this by using a temporary in the source and let the compiler safely
elide its use.
Reviewed by: kib
Fixes: 0fc65b0ab82c ("Make ld-elf.so.1 directly executable.")
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D50185
(cherry picked from commit 2b04ba6e08b983d8756552286846059507bca7a3)
Commit: 69728b7b09a8577c830e15234e145efc9d14befb
https://github.com/MidnightBSD/src/commit/69728b7b09a8577c830e15234e145efc9d14befb
Author: Jessica Clarke <jrtc27 at FreeBSD.org>
Date: 2026-01-18 (Sun, 18 Jan 2026)
Changed paths:
M libexec/rtld-elf/map_object.c
M libexec/rtld-elf/rtld.c
M libexec/rtld-elf/rtld.h
Log Message:
-----------
rtld-elf: Fix executable's TLS module index for direct exec
For direct exec mode we reuse map_object, but tls_max_index is
initialised to 1. As a result, the executable ends up being assigned
module 2 (and the generation is pointlessly incremented, unlike in
digest_phdr for the normal case). For most architectures this is
harmless, since TLS linker relaxation will optimise General Dynamic
accesses to Initial Exec or Local Exec for executables, but on RISC-V
this relaxation does not exist, yet the linker will initialise the
tls_index in the GOT with module 1, and at run time the call to
__tls_get_addr will fail with:
ld-elf.so.1: Can't find module with TLS index 1
Fix this by making map_object use 1 for obj->tlsindex when it's loading
the main executable, and don't bother to increment tls_dtv_generation
either, matching digest_phdr (though that one is harmless).
(Note this also applies to MIPS on stable/13)
Reviewed by: kib
Fixes: 0fc65b0ab82c ("Make ld-elf.so.1 directly executable.")
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D50186
(cherry picked from commit a08d92def20a41243d4afc97cf4a2124be5386b9)
Commit: 82a9daf420a3a6858699b6f789773c68d676d768
https://github.com/MidnightBSD/src/commit/82a9daf420a3a6858699b6f789773c68d676d768
Author: Jessica Clarke <jrtc27 at FreeBSD.org>
Date: 2026-01-18 (Sun, 18 Jan 2026)
Changed paths:
M libexec/rtld-elf/riscv/reloc.c
Log Message:
-----------
rtld-elf/riscv: Don't allocate static TLS for dynamic TLS relocations
Provided you don't run out of extra static TLS space this should work,
but it's wholly unnecessary and not how things are supposed to be done.
Only static TLS relocations should allocate static TLS.
Reviewed by: kib
Fixes: 4b1859c0e943 ("Add support for RISC-V architecture.")
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D50563
(cherry picked from commit 03801d449a3731cb643a51625c8c4d5d07b2e54c)
Commit: 0dc7ff1d06fb454c6aca4e94e8cf4508fb6a20bb
https://github.com/MidnightBSD/src/commit/0dc7ff1d06fb454c6aca4e94e8cf4508fb6a20bb
Author: Jessica Clarke <jrtc27 at FreeBSD.org>
Date: 2026-01-18 (Sun, 18 Jan 2026)
Changed paths:
M lib/libc/riscv/static_tls.h
Log Message:
-----------
libc/riscv: Fix initial exec TLS mode for dynamically loaded shared objects
The offset here is relative to the TCB, not whatever the thread pointer
points to, so as with powerpc and powerpc64 we need to account for that.
However, rather than using hard-coded offsets as they did, due to
predating machine/tls.h, we can just re-use _tcb_get().
Note that if libthr is used, and its initialiser has been called, it
will take a different path that uses _get_static_tls_base, which works
just fine on riscv (adding the offset to thr->tcb). This only affects
programs that aren't linked against libthr (or that are but manage to
dlopen before the initialiser is called, if that's even possible).
In future this code should be made MI by just reusing _tcb_get() and
checking the TLS variant (since the offset here is positive even for
variant II, where it should be subtracted), but this is a targeted fix
that makes it clear what's changing.
Reviewed by: kib
Fixes: 5d00c5a6571c ("Fix initial exec TLS mode for dynamically loaded shared objects.")
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D50564
(cherry picked from commit 0e3dbc64d9f6c95cbb16dba60a32136ae116dada)
Commit: 4c81ff72533947dd11569b9eae9964d24567871f
https://github.com/MidnightBSD/src/commit/4c81ff72533947dd11569b9eae9964d24567871f
Author: Jessica Clarke <jrtc27 at FreeBSD.org>
Date: 2026-01-18 (Sun, 18 Jan 2026)
Changed paths:
Log Message:
-----------
libc/riscv: Fix initial exec TLS mode for dynamically loaded shared objects
The offset here is relative to the TCB, not whatever the thread pointer
points to, so as with powerpc and powerpc64 we need to account for that.
However, rather than using hard-coded offsets as they did, due to
predating machine/tls.h, we can just re-use _tcb_get().
Note that if libthr is used, and its initialiser has been called, it
will take a different path that uses _get_static_tls_base, which works
just fine on riscv (adding the offset to thr->tcb). This only affects
programs that aren't linked against libthr (or that are but manage to
dlopen before the initialiser is called, if that's even possible).
In future this code should be made MI by just reusing _tcb_get() and
checking the TLS variant (since the offset here is positive even for
variant II, where it should be subtracted), but this is a targeted fix
that makes it clear what's changing.
Reviewed by: kib
Fixes: 5d00c5a6571c ("Fix initial exec TLS mode for dynamically loaded shared objects.")
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D50564
(cherry picked from commit 0e3dbc64d9f6c95cbb16dba60a32136ae116dada)
Commit: c3686d55bc6ba827a238d01067cc3bca00851a84
https://github.com/MidnightBSD/src/commit/c3686d55bc6ba827a238d01067cc3bca00851a84
Author: Jessica Clarke <jrtc27 at FreeBSD.org>
Date: 2026-01-18 (Sun, 18 Jan 2026)
Changed paths:
M libexec/rtld-elf/rtld.c
Log Message:
-----------
Revert "rtld: fix allocate_module_tls() variant I fallback to static allocation"
This was applying a NetBSD fix to FreeBSD. However, the original code
was correct for FreeBSD. NetBSD's obj->tlsoffset is relative to the end
of the TCB, not the TCB itself, whilst ours is relative to the TCB[1]
itself. For example, our allocate_tls uses (char *)tcb + obj->tlsoffset
for the memcpy and memset calls.
Without this reverted, for dynamically loaded shared objects, Initial
Exec accesses to TLS variables on variant I architectures (non-x86) use
the correct address, whilst General Dynamic and dlsym(3) use the
incorrect address (TLS_TCB_SIZE past the start). Note that, on arm64,
LLVM only supports TLSDESC (including LLD) and TLSDESC will use the
static resolver if the variable ends up allocated to the static TLS
block, even in the presence of dlopen(3), so only dlsym(3) shows the
discrepancy there.
Whilst here, add a comment to explain this difference to try and avoid
the same mistake being made in future.
[1] In the case of variant II, it's the amount to subtract, so still
positive
This reverts commit e9a38ed2fa61fd264a80f24ceb35f39b0ac6463d.
Reviewed by: kib (prior version)
Fixes: e9a38ed2fa61 ("rtld: fix allocate_module_tls() variant I fallback to static allocation")
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D50565
(cherry picked from commit ccfb1c50e45dbb7fcadf7e1932f63cf1702ef13a)
Commit: aabf3781dbc556204d5f48da0e0fa3a57456c850
https://github.com/MidnightBSD/src/commit/aabf3781dbc556204d5f48da0e0fa3a57456c850
Author: Lucas Holt <luke at foolishgames.com>
Date: 2026-01-18 (Sun, 18 Jan 2026)
Changed paths:
M ObsoleteFiles.inc
M share/examples/Makefile
R share/examples/drivers/make_device_driver.sh
M tools/build/mk/OptionalObsoleteFiles.inc
Log Message:
-----------
Remove dead driver example. no longer valid
Commit: f0cf82124a95dc1e2914e15a6acd603184119267
https://github.com/MidnightBSD/src/commit/f0cf82124a95dc1e2914e15a6acd603184119267
Author: Jessica Clarke <jrtc27 at FreeBSD.org>
Date: 2026-01-18 (Sun, 18 Jan 2026)
Changed paths:
M sys/sys/elf_common.h
Log Message:
-----------
sys: Delete stale comments in sys/elf_common.h
Originally the relocations for RISC-V were partitioned into dynamic and
static (with those that are both being classed as dynamic), but they
were packed next to each other, and so as new relocations were added
they were allocated sequentially, at the end of the static block, even
if really dynamic, R_RISCV_IRELATIVE being the first such case (and only
one we currently have a definition for). Delete the misleading comments.
Fixes: 4b88ccbc79cc ("Sync relocation definitions")
MFC after: 1 week
(cherry picked from commit d26f481bcdfec9354614ccc0f7f694bd7bcc5a6c)
Commit: faa1436f833b38a45bd470c840dab26b936f17ae
https://github.com/MidnightBSD/src/commit/faa1436f833b38a45bd470c840dab26b936f17ae
Author: Jessica Clarke <jrtc27 at FreeBSD.org>
Date: 2026-01-18 (Sun, 18 Jan 2026)
Changed paths:
M sys/sys/elf_common.h
Log Message:
-----------
elf: Remove R_RISCV_[GT]PREL_[IS] relocation defines
These were internal binutils relocations that have no way to be
generated in assembly nor will ever be seen in the output, and so should
never have been defined in the psABI in the first place. They have
therefore been removed from the spec as of [1], so do so here too.
[1] https://github.com/riscv/riscv-elf-psabi-doc/commit/44f98e0fd8104def00f2a5a8d94b23dd647d18fb
(cherry picked from commit f221000127767d33ea06d3a00e731c0164f9a70f)
Commit: f538e2e9d63329f2afad4bc559a15366ede7a1aa
https://github.com/MidnightBSD/src/commit/f538e2e9d63329f2afad4bc559a15366ede7a1aa
Author: Jessica Clarke <jrtc27 at FreeBSD.org>
Date: 2026-01-18 (Sun, 18 Jan 2026)
Changed paths:
M sys/sys/elf_common.h
Log Message:
-----------
sys: Sync RISC-V relocations
MFC after: 1 week
(cherry picked from commit 65bd6c7acd1fba38ce0b234d5d777a2ebad7e807)
Commit: 69d174860ed026420fc99d273cfda0c222130259
https://github.com/MidnightBSD/src/commit/69d174860ed026420fc99d273cfda0c222130259
Author: Jessica Clarke <jrtc27 at FreeBSD.org>
Date: 2026-01-18 (Sun, 18 Jan 2026)
Changed paths:
M sys/sys/elf_common.h
Log Message:
-----------
sys: Various whitespace style(9) fixes for sys/elf_common.h
MFC after: 1 week
(cherry picked from commit 22ae840b9f0ff290cb08edacf975a99d264d3a0d)
Compare: https://github.com/MidnightBSD/src/compare/1374db1c188d...69d174860ed0
To unsubscribe from these emails, change your notification settings at https://github.com/MidnightBSD/src/settings/notifications
More information about the Midnightbsd-cvs
mailing list