* Move the user stack from VM_MAXUSER_ADDRESS to a place below the 32bit
boundary (needed to support 32bit OSF programs). This should also save
one pagetable per process.
* Add cvtqlsv to the set of instructions handled by the floating point
software completion code.
* Disable all floating point exceptions by default.
* A minor change to execve to allow the OSF1 image activator to support
dynamic loading.
default for BINDIR. The default BINDIR of /usr/mdec can't be overridden
yet because libdisk still uses /usr/mdec and installing in /boot might
clobber the new boot blocks.
Don't install links to bootxx or xxboot.
Install boot1 and boot2 in 1 step.
Don't delete the boot.help source file on installing it when ${COPY} is
null.
"dying daemons" problem. (I thought this code was introduced in rev.1.80,
but it just relaxed the condition.)
Also, kill related "suggest more swap space" warning (also introduced in
1.80). It was confusing, to say the least...
Requested by: msmith
Not objected by: dg
It just replace u_long with u_int32_t and shouldn't affect on i386.
Without this patch,
- unaligned accesses occur
- permission denied randomly
Submitted by: Hidetoshi Shimokawa <simokawa@sat.t.u-tokyo.ac.jp>
There's something that's been bugging me for a while, so I decided to fix it.
FreeBSD now will DTRT WRT DDB and DDB_UNATTENDED (!debugger_on_panic), at least
in my opinion. The behavior change is such that:
1. Nothing changes when debugger_on_panic != 0.
2. When DDB_UNATTENDED (!debugger_on_panic), if a panic occurs, the
machine will reboot. Also, if a trap occurs, the machine will
panic and reboot, unlike how it broke to DDB before. HOWEVER,
a trap inside DDB will not cause a panic, allowing full use
of DDB without having to worry about the machine being stuck
at a DDB prompt if something goes wrong during the day.
Patches for this behavior follow my signature, and it would
be a boon to anyone (like me) who uses DDB_UNATTENDED, but
actually wants the machine to panic on a trap (otherwise,
what's the use, if the machine causes a fatal trap rather than
a true panic, of debugger_on_panic?). The changes cause no
adverse behavior, but do involve two symbols becoming global
Submitted by: Brian Feldman <green@unixhelp.org>
