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]
gtmr: simplify the checking of the parent device properties.
The code still looks for the "physical" property on the device and the
parent device, but it's more obvious now.
Fix a whitespace issue in the process.
etc/etc.evbarm/Makefile.inc: follow-on hash generation fix
Revs. 141 & 142 introduced a guard that tried to prevent checksum
consolidation from running in contexts where there's nothing to process
-- that is, images aren't created at all. However, it then also
prevented clean builds that do include images from consolidating their
checksums as intended, since the "exists" check that was added reflects
too early a file system state on clean builds ("gzimg" doesn't exist
yet). It also didn't address the fact that there can be targets that
do in fact create and populate a "gzimg" directory, yet don't actually
generate any images as presently construed/defined are relevant for
hash generation, as happens with the evbearmv4-el arch.
Another fix for PR install/59195. Tested with earmv5hf (no images, no
"gzimg" directory created), evbearmv4-el (no images, "gzimg" directory
is created), and aarch64 (images and "gzimg" directory are created),
with clean builds into new directory structures and subsequent update
builds tested for each arch.
Prefer using ${.PARSEDIR} over assuming that ${.CURDIR} is src/lib/libc.
Mostly this changes ${.CURDIR} refs into either ${.PARSEDIR}, ${LIBCDIR},
or ${NETBSDSRCDIR} refs.
Set LIBCDIR earlier to ensure it's available always.
This will be used to build a smaller libc (eg, with no assert strings.)
Tested builds on atari, x86-64, arm64, and vax.
Yet another printf format fix...
Use PRI[diuoxX]PTR for [u]intptr_t types rather than PRId64.
Pointers (and hence [u]intptr_t's) are not 64 bits in ILP32 systems.
I picked 'x', well, just because ...
And this time I verified it builds on i386!
Fix wacky printf usage - hopefully unbreak 32 bit builds
Rather than converting an int type to a (void *) and then
printing using %p (one presumes to obtain hex), use the PRIx64
(the value is int64_t) macro (just like previous output lines do)
instead. (Use the '#' printf flag as well, to get the 0x when
needed, and just 0 if the value is 0).
As it was, 32 bit builds would complain about converting between
a pointer and an integer of a different size - converting it to
intptr_t before void * would have fixed that, but would lose the
top 32 bits of the value on 32 bit systems.
kqueue/kernel/t_pipe: Fix newly failing test.
If the read side of a pipe has been closed, then for the write side:
- poll will set POLLOUT, not POLLNVAL (nor fail with EBADF), and
- select will report writable, not fail with EBADF,
because the write side is immediately writable and will fail with
EPIPE/SIGPIPE -- it won't block if you try to write.
So surely kqueue with EVFILT_WRITE should simply report immediately
writable too, not fail with EBADF. And that is what I caused to
happen by simplifying and clarifying the code and fixing various edge
cases. (The bad response that this test was added to check is a
kernel crash on null pointer dereference; that, fortunately, has not
regressed.)
PR kern/59056: poll POLLHUP bugs
pipe(2): Don't cv_wait_sig in a loop without breaking on signal.
If a signal does arrive, it will turn into a busy wait! Not helpful.
But this wait should be limited to scheduling delays for other
threads anyway, not for general I/O, so there's no need to be
interruptible by a signal.
Prompted by:
PR kern/59056: poll POLLHUP bugs
