a softint from the network stack.
Don't recurse through scsipi_command() when we have multiple packets
in the send queue - use a loop instead. This means that we no longer
need sestart(), as we can now handle everything in sedone().
Fix a couple of XXX's.
Rework the locking logic slightly from the previous revision.
Now this works with DIAGNOSTIC+LOCKDEBUG.
division by zero is not correctly trapped for i386 and amd64:
https://bugs.launchpad.net/qemu/+bug/1668041
Make trigger_fpe() cause integer division by zero for x86, and
floating-point one for other architectures. Also, assertions for
si_code in *_crash_fpe tests are commented out for now. They
should be cleaned up after the bug is fixed.
Now, *_crash_fpe tests are working also on powerpc.
Suggested by kamil.
- Respect destination directory specified by -d option.
- Accept check and fix options. For the former, do not modify anything as
users normally expect.
http://mail-index.netbsd.org/source-changes-d/2020/06/21/msg012745.html
- Revive __lwp_settcb(), and call _lwp_setprivate(2) from it.
- Keep l_private opaque pointer for kernel; store raw value of %r2 in it.
In the previous commit message, I wrote,
http://mail-index.netbsd.org/source-changes/2020/06/21/msg118524.html
> - Make sure that, like other ports, l_private represents address of tcb,
> not biased one as in %r2.
but, it turned out to be wrong. mips stores a biased address, at least.
It is userland responsibility to interpret returned values from
lwp_getprivate(2).
until QEMU bug #1668041 is fixed:
https://bugs.launchpad.net/qemu/+bug/1668041
by which floating-point division by zero is not trapped correctly
both on amd64 and i386.
Skip *_crash_fpe tests on powerpc, where integer division by zero
is never trapped.
Revert my recent 1.85 revision that fixed "make tags". It causes too
much build breakage elsewhere in the tree that needs to be resolved first.
Issues include:
- Directories using TESTS_CXX with .cpp and .cxx extension instead of the
default .cc extension (see bsd.prog.mk). Most of these have been fixed.
- external/gpl3/gcc build of .cc files. (No idea what's wrong there).
Disable events on entry to be safe.
It should have been mostly safe for most cases, but for FPU traps
we need to reload the FPU state if we got interrupted at trap entry.
Hopefully fixes:
panic: kernel diagnostic assertion "curlwp->l_md.md_flags & MDL_FPU_IN_CPU" failed: file "/home/source/ab/HEAD/src/sys/arch/x86/x86/fpu.c", line 524
when running tests.
Otherwise the ABSENT_NUMERIC(-1) or CANCELLED_NUMERIC(-2) will be converted
incorrectly to size_t and then down to uint16/32_t.
Picked up by DIAGNOSTIC builds.
Thanks to Michael Forney for the fix for PR lib/52293.
t_cabsl source is in t_cabsl.cxx not t_cabsl.cc - the latter
is what bsd.tests.mk defaults to.
This only broke after my commit of share/mk/bsd.dep.mk rev 1.85
but I don't know why it didn't cause a problem previously.
Fix "make tags" to actually build a tags file:
- Use !commands() instead of !target(), so that the rule actually works
- Write to ${.OBJDIR}/tags for read-only source (don't know why ${.TARGET}
isn't sufficient).
- Only match *.[cly] from ${.ALLSRCS} - just excluding *.h causes failures
because of ${targ}: subdir-${targ} in bsd.subdir.mk.
Thanks to uwe@ for assistance.
inconsistency whether it is biased or not in kernel.
- Obsolete __lwp_settcb() in order to let kernel know new TLS address via
_lwp_setprivate(2). Alternatively, we can call _lwp_setprivate(2) within
__lwp_settcb() like mips, but it is just double handling; we adjust %r2
appropriately in _lwp_setprivate(2) via cpu_lwp_setprivate().
- Make sure that, like other ports, l_private represents address of tcb,
not biased one as in %r2. This guarantees that the returned values from
_lwp_getprivate(2) and __lwp_getprivate_fast() are always same. Also,
we can obsolete PTRACE_LWP_GETPRIVATE() macro.
Now, *_pl_private tests in tests/lib/libc/sys successfully pass, while
no other tests become newly falling.
Found by tests/lib/libc/sys/t_sigaltstack, which passes now, while
no other tests are not falling newly.
XXX
Shouldn't we turn _UC_{SET,CLR}STACK into MI?
