kernel and bootloader for 68010.
They requires a special calling convention to udivsi3, and cannot to be
mixed up in normal routines provided by libgcc or compiler_rt. Although,
there's no problem for using them in a controlled situation, i.e., kernel
and standalone programs.
Note that this does not affect at all m68k ports other than sun2, since
codes generated by gcc do not call these routines.
Assembler files are moved from common/lib/libc/arch/m68k/gen to
sys/lib/libkern/arch/m68k in order not to be compiled in libc.
Revert hack introduced to lib/libc/compiler_rt/Makefile.inc rev 1.37:
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/compiler_rt/Makefile.inc#rev1.37
Proposed on port-sun2@ with no response...
(Again, this does not affect m68k ports other than sun2.)
http://mail-index.netbsd.org/port-sun2/2020/03/10/msg000102.html
Optimistically check whether the key has been used by this thread
already and avoid locking in that case. This avoids the atomic operation
in the hot path. When the value is set to non-NULL for the first time,
put the entry on the to-be-freed list and keep it their until
destruction or thread exit. Setting the key to NULL and back is common
enough and updating the list is more expensive than the extra check on
the final round.
Problems in the previous code include returning values in the 0-255
range NetBSD uses instead of the 0-100 range OSSv4 expects, using
AUDIO_GETBUFINFO (which doesn't even return the mixer bits), and
not encoding channels as specified: "level=(left)|(right << 8)".
In reality, setting the gain in this way (through /dev/audio rather
than /dev/mixer) doesn't seem to work properly, and the mixer-set
value seems to be retained.
However, these changes at least ensure that the return values are
correct and the balance is set correctly.
I've only found one application using this API (audio/audacious), and
OSSv4 support in it is currently disabled precisely because it breaks
when it attempts to set the track volume using it.
rtld and libc use different storage, so the initial version would
incorrectly report the failure reason for fork().
There is still a small race condition inside ld.elf_so as it doesn't use
thread-safe errno internally, but that's a more contained internal
issue.
in a consistent state. This most importantly avoids races between dlopen
and friends and fork, potentially resulting in dead locks in the child
when it itself tries to acquire locks.
The OSSv4 spec says we shouldn't really error if an invalid format is
chosen by an application. Things are especially likely to be confused
if we return MULAW, since in OSSv4 terms that means that's the native
hardware format. Instead, set and return the current hardware format
if an invalid format is chosen.
For the 24-bit sample formats, note that the NetBSD kernel currently
can't handle them in its default configuration, and will return an error
code if you attempt to use them. So, if an applicaton requests 24-bit PCM,
promote it to 32-bit PCM. According to the spec, this is valid and
applications should be checking the return value anyway.
In the Linux compat layer, we just use S16LE as a fallback. The OSSv3
headers that are still being shipped with Linux don't contain definitions
for fancier formats and we can reasonably expect all applications to
support S16LE.
From the perspective of reading the OSSv4 specification, NetBSD's
behaviour when an invalid sample rate is set makes no sense at all:
AUDIO_SETINFO simply returns an error code, and then we immediately
fall through to getting the sample rate, which is still set to the
legacy default of 8000 Hz.
Instead, what OSS applications generally expect is that they will be
able to receive the actual hardware sample rate. This is very, very
unlikely to be 8000 Hz on a modern machine.
No functional change when setting a sample rate between the supported
rates of 1000 and 192000 Hz. When a rate outside this range is requested,
the hardware rate is returned (on modern hardware, generally always 48000
Hz or a multiple of 48000 Hz).
Reading from a database is now optional.
Compiling terminfo descriptions (including from $TERMINFO) is now optional.
Compat support is now optional.
This removes 17k on amd64 from the binary size, which allows it to be used
again on space constrained ramdisks.
This bug was reported by UBSan runs.
lib/libusbhid/parse.c:246:20
Can result in left shift changes signedness bit as a side effect positive number
can go negative, cast it to unsigned for the operation and silence the issue.
Reviewed by: kamil@
This bug was reported by UBSan runs.
lib/libusbhid/usage.c:247:27
lib/libusbhid/usage.c:244:28
lib/libusbhid/usage.c:235:13
Can result in left shift changes signedness bit as a side effect positive number
can go negative, cast it to unsigned for the operation and silence the issue.
Reviewed by: kamil@
This bug was reported by UBSan runs.
lib/libusbhid/data.c:58:25
lib/libusbhid/data.c:91:7
lib/libusbhid/data.c:92:7
Can result in left shift changes signedness bit as a side effect positive number
can go negative, cast it to unsigned for the operation and silence the issue.
Reviewed by: kamil@
Blindly scanning the capabilities for # and checking that the following
number is bigger than a short isn't reliable because this could be a
string value:
SomeString#1234
Instead, if we process the numeric as normal and if it's value is too big
for v1 then promote the record to v3.
