tests/libc: test long double operations more thoroughly
For lint, the tests msg_380.c and msg_381.c fail, which is probably due
to a bug in the softfloat implementation.
The tests are intended to yield the same results on all platforms, as
they do not exercise any tricky rounding details.
Re-factor the simple "basic 4BSD disklabel scheme" into kern/subr_disk_4bsd.c,
the implementation itself lifted verbatim from hp300. virt68k differed
only by RCS IDs, news68k differed in older copyright notice plus some
whitespace differences in 2 diffrent source lines.
If BUS_DMA_24BIT is defined, clear it from the flags passed to
_bus_dmamem_alloc_common(), since we've already constrained the
allocation based on the window configured for the selected VME
address space.
Merge mvme68k and virt68k bus_dma into the common m68k bus_dma and
remove their local copies. Minor cleanup tweaks to other platforms
that already use the common version.
Pull up following revision(s) (requested by yamt in ticket #241):
etc/etc.amd64/MAKEDEV.conf: revision 1.38
amd64 MAKEDEV: create 8 nvme (nvme0-nvme7) by default
why 8?
- match ld, sd, wd
- my machine has 6 of them
Pull up following revision(s) (requested by skrll in ticket #250):
tests/lib/libc/setjmp/t_sigstack.c: revision 1.26
lib/libc/compat/arch/arm/gen/compat_setjmp.S: revision 1.7
arm: fix PR/57946 for compat
Make longjmp restore stack first before restoring signal mask for
arm/compat.
arm is fixed.
Pull up following revision(s) (requested by yamt in ticket #249):
lib/libkvm/kvm_proc.c: revision 1.102
lib/libkvm/kvm_proc.c: revision 1.103
lib/libkvm/kvm_proc.c: revision 1.104
libkvm _kvm_ureadm: remove a redundant check
libkvm _kvm_ureadm: fix anon address calculation
this has been broken since the initial uvm support in 1998.
libkvm _kvm_ureadm: fix an integer overflow
this has been broken since the initial uvm supporT in 1998.
I suppose it was rare to use >2GB swap in that era.
Pull up following revision(s) (requested by hgutch in ticket #248):
lib/libcurses/addbytes.c: revision 1.71
lib/libcurses/attributes.c: revision 1.37
lib/libcurses/insdelln.c: revision 1.25
lib/libcurses/add_wch.c: revision 1.11
lib/libcurses/touchwin.c: revision 1.36
lib/libcurses/refresh.c: revision 1.131
libcurses: fix wrong NULL guard
Move the NULL guard in _cursesi_waddbytes() out of #ifdef DEBUG .
Delay initialization of all variables that require dereferencing pointers
that might be NULL until after the NULL guards. This is what KNF calls
for anyway.
Fixes PR lib/60153 .
Pull up following revision(s) (requested by mrg in ticket #247):
external/gpl3/gcc.old/dist/gcc/genmatch.cc: revision 1.2
(applied to external/gpl3/gcc/dist/gcc/genmatch.cc)
tools/gcc/gcc-version.mk: revision 1.32 (via patch)
genmatch.cc: bring across several enhancements from mainline GCC.
in my testing this reduces the size of the emitted "gimple-match.cc"
by about 35%, reduces the code section sise about 15%, and reduces
the compile time about 30%. (this file is the largest single compile
for all of GCC.)
this makes it capable of compiling on vax and sparc again, it seems,
where both were already capable for GCC 14 (which in addition to this
set, splits the emitted file into 10 sub parts for compiling both
separately and in parallel.)
(this is part 1, part 2 will be about mergig the split of the output
[25 lines not shown]
Pull up following revision(s) (requested by kre in ticket #246):
bin/sh/expand.c: revision 1.149 (partly, via patch)
While here, fix another, identical land mine, that
has been buried in the absolute wilderness for years.
Someone would have stepped on it one day.
Also fix a field splitting bug handling : or = in
IFS when generated from ${var-string1:string2} type
expansions. This one is even older.
Pull up following revision(s) (requested by yamt in ticket #245):
external/gpl3/gcc.old/dist/gcc/cfgexpand.cc: revision 1.2
(applied to external/gpl3/gcc/dist/gcc/cfgexpand.cc)
PR/59994 gcc/m68k generates bad code for stack protector
Record the alignment of the stack canary before allocating space for
it in a stack frame.
Generate an assignment expression to initialise the canary instead of
emitting a move instruction.
Pull up following revision(s) (requested by yamt in ticket #242):
sys/uvm/uvm_pdaemon.c: revision 1.135
sys/uvm/uvm_pdaemon.c: revision 1.137
sys/uvm/uvm_pdaemon.c: revision 1.138
sys/uvm/uvm_swap.c: revision 1.210
Add more debugging.
To help understand PR 56764 better.
Ok riastradh@
Disable a kassertmsg.
This triggers for me quite reliably over years now, and has been
tracked in PR 56764, with no resolution.
It seems the asserted inequality just is not correct.
uvmpd_scan_queue: remove ENABLE_UNRELIABLE_CHECK_PR_56764 block
while this condition is true in most of times, we can't
[8 lines not shown]
Pull up following revision(s) (requested by yamt in ticket #240):
sys/dev/nvmm/x86/nvmm_x86_vmx.c: revision 1.93
nvmm_x86_vmx.c: fixes tprof stalls
the current implementation of nvmm nmi handling is
simple; just drops them. it interferes other nmi-using
components in the system, including tprof.
this commit makes nvmm try to dispatch nmis by itself.
while this is imperfect, it's good enough to give
tprof a chance to unmask LAPIC_LVT_PCINT.
i guess svm VMCB_EXITCODE_NMI needs something similar.
but i have no hardware. if someone wants to test a patch,
please let me know.
reproduce recipe:
1. run "tprof top" in a terminal. leave it running.
[2 lines not shown]
Pull up following revision(s) (requested by yamt in ticket #239):
sys/uvm/uvm_mmap.c: revision 1.189
sys_mincore: stop locking potentially huge amount of user memory
the current implementation performs uvm_vslock() on the
user-specified amount of memory. it isn't safe in general.
some might even consider it as a security issue.
this commit fixes it by splitting the user-specified range into
small ones which a temporary kernel buffer can cover. it's ok to
report potentially stale values as the mincore() api is inherently
racy in the first place.
while we still ought to invent a proper "lock user memory for
direct i/o" infrastructue, in this particular use case, it isn't
necessary or appropriate.
Pull up following revision(s) (requested by yamt in ticket #238):
sys/uvm/uvm_mmap.c: revision 1.188
uvm_mmap.c: fix overflow check
this is my best guess of the intention of the original code,
where "*addr + *size < *addr" seems always false because "*size" is 0.
