support it in the kernel yet. If we don't do this, GDB arbitrarily
assumes we wanted it to be 9, which is silly.
In the kernel, leave it undefined so that sys_process.c doesn't
generate code for it.
the instruction we used with GDB 4.x. The new instruction has the advantage
of fitting the pattern that ARM recommend using for instructions that need to
stay undefined.
(eg ARM920), the mode in which the processor operates is governed by
the use of both the PT_C and PT_B bits:
PT_C=1,PT_B=1 -> Write-back
PT_C=1,PT_B=0 -> Write-through
To support this define pte_cache_mode (initialized to PT_C|PT_B) and
use that when enabling cacheing for a page.
to allocate a L1 pt is often enough to bring the system to its knees:
so make the messages PDEBUG(0,...).
However, even with this step having more than a small number of
processes searching for a L1 pt can still be enough to bring the system
down, since they all run at high priority and sleep for very little time,
thus blocking out user code from completing. So implement an exponential
backoff when waiting for a page table, so that we don't hog the CPU when
memory is scarce.
Tested by running a make of the C compiler with "gnumake -j30" (and plenty
of swap space).
1: Don't include arm-convert.o. arm-convert.s contains only comments, and our
build procedure can't cope with .s files.
2: Add "check_format" and "core_sniffer" entries to netbsd_core_fns, the same
as in i386nbsd_nat.c.
The first of these will need toolchain2netbsd to be re-run. While these
changes let GDB compile, I haven't tried running it on an ARM ELF system yet.
is shared with another process (as can happen if vfork is being used),
then that other process will end up not having a page 0, which is bad
news indeed, since then there is no way back into the kernel.
Found this using a multi-ice box, so they are useful after all!
This seems to fix pr port-arm32/11921 and (possibly) kern/9859.
lukem