kk_KZ.PT154 locale: Add missing toupper/tolower mappings.
This was missing a tolower mapping (MAPLOWER) from the lower case
(ASCII) letters into themselves (which is required to work), and worse
was also missing a toupper mapping (MAPUPPER) from the lower case (ASCII)
letters into their upper case equivalents.
Whether the actual (non ASCII) letter upper/lower mappings are all
correct, I am not sure, but I very much doubt it.
Detected and reported by RVP@ in:
https://mail-index.netbsd.org/tech-userlevel/2026/08/15/msg015003.html
bsd.own.mk: Respect USE_FORT even if defined after bsd.own.mk.
Using (a chain of logic that boils down to)
.if ${USE_FORT:Uno} != "no"
CPPFLAGS+= -D_FORTIFY_SOURCE=2
.endif
expands USE_FORT eagerly, so if USE_FORT was not already defined before
including <bsd.own.mk>, it's too late after.
Using (a chain of logic that boils down to)
CPPFLAGS+= ${${USE_FORT:Uno} != "no":?-D_FORTIFY_SOURCE=2:}
expands USE_FORT lazily, so it's only when CPPFLAGS itself is expanded
-- usually in a recipe, after all variable assignments, prerequisite
lists, and .directives have been processed -- that USE_FORT is
expanded.
[9 lines not shown]
ssp.h: Stop creating references to useless __ssp_protected_* symbols.
The ssp wrappers are useful _only_ when they are actually used for
inline function call expansion; if the function is used for anything
else like a function pointer, only the underlying library symbol
should be used.
To pacify linker complaints about spurious references to
__ssp_protected_getcwd/read/readlink, we added equally spurious
definitions of those symbols to libc without understanding why; it
turns out it only happened because the ssp wrappers declared, e.g.:
extern inline read(...) __RENAME(__ssp_protected_read);
extern inline read(...) { <ssp check>; return __ssp_real_read(...); }
The declaration with __RENAME caused the compiler to generate
references, required by the linker to be resolved, to the symbol
`__ssp_protected_read' when compiling code that takes the address of
the function read() to pass around a function pointer. Instead, the
[15 lines not shown]
zaurus: MOve COPTS="-Os" from INSTALL to GENERIC.
INSTALL includes GENERIC, so no change to INSTALL. But the reason
for -Os (a size limitation of the bootloader, checked at build-time)
appears to apply just as well to any kernel, not just INSTALL, and
the recent change to flip on -ftrivial-auto-var-init bumped GENERIC
over the limit too:
Checking kernel size...
Fatal: kernel size must be less than 5MB.
Fatal: kernel size: 5247920, max kernel size: 5242880
--- netbsd ---
*** Failed target: netbsd
*** In directory: /home/builds/ab/HEAD/zaurus/20261006081837Z-obj/home/source/ab/HEAD/src/sys/arch/zaurus/compile/GENERIC
Setting COPTS="-Os" both tells the compiler to make smaller code, and
turns off the -ftrivial-auto-var-init logic in Makefile.kern.inc,
which with any luck should help fix the zaurus build.
[2 lines not shown]
mips: declare SPL stub functions in intr.h
Move the .stub section attributes for the MIPS SPL functions from
spl_stubs.c to intr.h, and add the splcheck declaration with __noubsan.
sys: Disable -ftrivial-auto-var-init if -Os is in play.
This should help avoid the code expansion that broke the zaurus and
ews4800mips builds.
PR kern/60839: use -ftrivial-auto-var-init
pipe(2): Restore kevent EVFILT_READ/WRITE success on wrong pipe end.
Missed a spot when gathering the hunks in the previous change for
this.
PR kern/60851: change in pipe kevent EVFILT_READ/WRITE on wrong end
Revert "pipe(2): Add memory safety diagnostics."
This was rather sloppily done (from my local tree, not cleaned up
before committing in haste in an attempt to help diagnose the spate
of crashes that have been seen today). Will redo this a little more
tidily.
PR kern/59056: poll POLLHUP bugs
pipe(2): Plug mutex_obj leak.
This was introduced in what was supposed to be mere refactoring in
rev. 1.170 (pipe(2): Split new function pipefree out of pipeclose.) as
part of
PR kern/59056: poll POLLHUP bugs
I missed a spot, the mutex_obj_free in pipeclose, which should have
been moved into pipefree.
Noticed by mlelstv@.
pipe(2): Restore kevent EVFILT_READ/WRITE success on wrong pipe end.
In rev. 1.174, while cleaning up various issues in select/poll/kqueue
logic for pipes, I changed the behaviour of kevent when adding an
EVFILT_READ event for the write side of a pipe, or an EVFILT_WRITE
event for the read side of a pipe, to fail with EINVAL; previously it
would quietly be accepted and do nothing, which struck me, without much
thought, as uncontroversially wrong and unhelpful. But apparently
that's what FreeBSD and OpenBSD do too, and it seems that applications
such as mail/dovecot2 rely on it. So put it back.
PR kern/60851: change in pipe kevent EVFILT_READ/WRITE on wrong end
cpuctl(8): update Transmeta identification for Efficeon (TM8000 series).
It uses family 15 and it has a new way to decode processor revision, so update
family > 6 default to "Efficeon" and call transmeta_cpu_info() for it.
Decode processor revision from leaf leaf 0x80860002 EAX
when leaf 0x80860001 EBX contains 0x02000000.
Untested on the actual hardware (I don't have one).
Verified by the CPUID dump available online.
PR port-mips/60780 UBSan: long int << fix (src/common/lib/libc/string/memset2.c)
The comments say that memword_t is intended to be unsigned, but
presume that __register_t will provide that attribute. It usually
doesn't, so we need an unsigned type for building the fill value.
Thanks to Alexander Schreiber for running the UBSan built system
and reporting this (and others), and hopefully, in advance for
testing that this one is now fixed.
XXX - pullup -11 -10 (probably, it cannot possibly hurt)
End libc Makefile .${PARSEDIR} abuse
It is pointless assigning ${.PARSEDIR) to a variable using '='
as when that variable is later expanded, ${.PARSEDIR} will not
have a value, and we end up with things like:
.... -I. -I/home/source/ab/HEAD/src/lib/libc/arch/mips/softfloat
-I -DSOFTFLOAT_FOR_GCC
-I/home/source/ab/HEAD/src/lib/libc/arch/mips/softfloat
-I -DSOFTFLOAT_FOR_GCC
-DSOFTFLOAT -I/home/source/ab/HEAD/src/sys ....
That exxtracted from a failing command from the autobuilds (which I
first saw on my local system attempting a mips64eb build). That is
all part of one (long) command line from which I extracted that piece
(and then manually line wrapped it for this log message).
Note the 2nd and 4 lines ... those are meant to have ${.PARSEDIR}
between the -I and -D (I doubt there is a "./-DSOFTFLOAT_FOR_GCC"
[12 lines not shown]
