rescue/ldd: Add a couple new symbols for recent rtld changes.
Should fix:
# link rescue/rescue
...
/tmp/build/2026.07.01.20.39.44-i386/tools/lib/gcc/i486--netbsdelf/14.3.0/../../../../i486--netbsdelf/bin/ld: /tmp/build/2026.07.01.20.39.44-i386/obj/usr.bin/ldd/elf32/libldd_elf32.a(load.o): in function `_rtld_load_object':
load.c:(.text+0x23b): undefined reference to `_rtld_objgen'
/tmp/build/2026.07.01.20.39.44-i386/tools/lib/gcc/i486--netbsdelf/14.3.0/../../../../i486--netbsdelf/bin/ld: load.c:(.text+0x256): undefined reference to `_rtld_objrelocpending'
PR lib/59751: dlclose is not MT-safe depending on the libraries
unloaded
ld.elf_so(1): Bump _rtld_objgen when changing, not reading, objlist.
Prompted by:
PR lib/59751: dlclose is not MT-safe depending on the libraries
unloaded
ld.elf_so(1): Resolve several races in dlopen/dlclose.
This is difficult because, although rtld generally has a single
exclusive lock, i.e., generally runs single-threaded itself, it can't
hold this lock while calling constructors/destructors (init/fini or
ifunc) -- if it did, then, for example, lazy symbol binding that
happens during the constructor/destructor would deadlock against
itself.
And whenever rtld drops the lock to call constructors/destructors,
any objects it is working on, during dlopen or dlclose, might have
been concurrently closed and invalidated by the time it gets the lock
again.
The key point is that anywhere we pass a sigset_t *mask parameter
during dlopen or dlclose, we might release the rtld lock to sleep and
then reacquire the lock. And anywhere we might release and reacquire
the lock, any objects we hold may be invalidated -- unless we hold some
reference to prevent invalidation. And any object we find in the list
[129 lines not shown]
sdmmc: remove unused cmd fields
c_dmaseg and c_dmaoff are only written using memset(&cmd, 0) when
constructing a command, so they always assume a constant value and can be
removed.
/bin/sh fix trap/jobid builtins when run from grandchild
The trap and jobid builtins are designed to allow
T=$(trap)
(etc) to see (output) the traps (or jobs for jobid) of parent shell (the one
running the assignment) to be seen from inside a subshell (here the command
substitution, which it usually would be).
But all that should be reported are the traps (jobs) of the parent of
that subshell, not recursively up the chain.
That is
( T=$(trap) )
should usually be equivalent to T='' as inside a subshell environment
all non-ignored traps are defined to be reset to their defaults
[33 lines not shown]
sh tests: builtins: add more content
Many of the t_builtins sh tests were just placeholders for things to come.
They've been that way for years...
This adds some actual content to some of them - still very primitive in
most cases, but better than was there before. There are still too many
empty tests (test the builtin exists, but that's it).
Also, add a test for the trap builtin - that wasn't there before as traps
are tested in other of the sh tests ... this new one is therefor not testing
that traps work (or not in any way that's meaningful), rather it is testing
that the various ways the trap command can be used all work.
Currently two of the sub-tests will fail, the new trap test, and the
(was previously empty) jobid test (testing a NetBSD extension builtin).
Adding those failing tests was the inspiration for all of this. The bug
they expose is exotic, and never likely to be encountered, or do any harm
[7 lines not shown]
sh tests: arithmetic: fix test for support of pre ++/-- ops
The C prefix and postfix unary ++ and -- operators are optional
in POSIX sh (supported in NetBSD's sh). To allow these tests to be
used to test other shells, the tests generally attempt to verify that
optional features are supported, before testing them.
The prefix ++ and -- tests, to see if there was support in ${TEST_SH}
were not guaranteed to work, as ++X might be preincrement X, or it
might just be + + X (ie: applying the unary + operator twice).
Fix that by testing whether ++X and + + X give the same result, if
they do, then prefix ++ is not supported (also if ++X generates an error)
Just the same for the prefix -- operator.
The postfix operator tests are OK, X-- is either X-- or an error.
NFCI for tests of the NetBSD sh. (This change has been in my local
set of sh tests for a long time now.)
Avoid stupid macro name clash: m68k/include/reg.h defines R0 and R1
as the register offsets for returning values from functions in the.
These clash with local buffers R0 and R1 here.
Rename them to cookie_R0 and cookie_R1 to make all m68k ports build again.
unbound: Install a default configuration.
This way, setting unbound=YES is enough to get a working local
recursive resolver listening on 127.0.0.1:53 and [::1]:53.
PR misc/60339: unbound=YES in rc.conf should be enough to get a
recursive resolver
Additionally, this includes the workaround for:
PR bin/60325: unbound emits warning: so-sndbuf 4194304 was not
granted
x86/efi: Bypass kASAN memcpy when copying the efi runtime.
Fixes crash at boot with `options KASAN' enabled on EFI systems.
We could try to find some way to exclude the EFI runtime mappings
from kASAN, e.g. by hacking kasan_md_unsupported. But there's a lot
of detailed exclusions to pass through to that (every entry in the
EFI memory map), and this is the only memcpy in the whole kernel that
all those details are likely to be applicable.
PR kern/60391: kernel panic in efi_init() with "options KASAN"
Introduce EFIKA_OFW_WORKAROUNDS - patch OFW trampoline for EFIKA.
Long story short, is that SmartFirmware (EFIKA's OpenFirmware) misbehaves
on every OF call from the kernel by zeroing SDR1 and messing with BATs.
In the olden days, these problems were worked around with FIRMWORKSBUGS
option. However, that option does not work currently on EFIKA. Presumaly,
something has changed between 2012 and now, which causes FIRMWORKSBUGS
to hang on SmartFirmware very early (before NetBSD copyright banner is
printed).
So we get this kludge, which only does the bare minimum to let OFW
call succeed, and the kernel continue after the call.
citrus/HZ: Be more careful about encoding buffer.
1. Use unsigned char for chlen, since it's never negative and only
needs to be big enough for the ch array.
2. Expand the ch array by space for two escape sequences, each of
which is two characters.
I don't think it is currently possible with the i18n data we ship
for it to emit two escape sequences in a row -- there is a code
path to do this, but I don't think it can be reached without
setting escape sequences for variable 1 and extending this in some
way. Nevertheless, let's err on the side of safety.
3. Sprinkle assertions everywhere.
PR 59019: various iconv issues
iconv(3): Fix printing bytes on test failure.
Don't sign-extend to a 32-bit quantity causing the left to be padded
with f's; just print the 8-bit quantity.
PR 59019: various iconv issues
