into their own sub-structure of the pcb (from 'struct savefpu').
They only (seem) to be used in some code that generates core dumps
for 32bit processes (code that might be broken as well!).
'struct safefpu' is now identical to 'struct fxsave64'. One (or both)
needs extending to support AVX - might need to be dynamically sized.
Removed all the __aligned(16) except for the one in struct pcb itself.
Only the copy used for the fsave instruction need be aligned.
Now palette initialization no longer stomps over the port table, which gives
us a fighting chance to intentionally enable the right outputs.
How on earth did this ever work?
the existing strlen for small string and once strings are 8 bytes or more in
length it starts getting significantly faster. For really long strings,
compared to the existing strlen, this uses about 1/2 of the cycles for the
non-armv6 version and about 1/3 of the cycles for the armv6 version.
diagnostic and exit with an error code. Get the interface name and flags
opportunistically to allow the code to return normally if it does not need
to do anything.
requested, which is allowed by pertinent standards, honor it instead
of bombing.
Do not do this for calloc(x, y) where x != 0 && y != 0 but x*y == 0;
in that case bomb.
it and the OS has enabled XGETBV for application use.
It might need to also check XCR0[2] (having executed XGETBV) to check that
the kernel actually supports saving the YMM registers, but I suspect the
kernel might defer setting that until the first fault.
See vol 1 section 13.5 of the Intel SDM (intel_x86_325462.pdf).
Fixes toolchain/45673
around this by returning ENOSPC in case of a short write to avoid protocol
errors. This change is based on problem analysis provided by Antti Kantee.
This fixes PR lib/45129 by myself.
2. In the clear-route-cache sendto, don't send 0 bytes (if -s was specified
with < 8, phdrlen would be 0).
3. Always send ICMP_MINLEN packets; this is what everyone else does. Makes
ping -s n where n < 8 work.
4. The condition for checking the data bytes was completely wrong. only check
the data bytes if we got all of them.
5. The condition for printing a newline was wrong; before it would not print
a newline before printing the data bytes, and it would append to the previous
error message.
cause the buffer to stay lock and we end up blocking forever in
VOP_CLOSE->spec_close->vinvalbuf->bbysy since the buffer is marked busy
but there is no I/O pending.
This caused my laptop to hang on boot_findwedge because:
findroot: unable to read block 358331527 of dev dk0 (22)
