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]
