While working on the GDB import, and prodded a bit by one of the GDB
developers, I started looking into why the GDB testsuite has many more
failures on macppc systems than it does on most other systems. The
general problem is programs continuing when they're supposed to hit a
breakpoint; this happens more often in the automated testsuite than it
does manually, but I can reproduce it by hand on my G4 by loading up a
program ("ls" makes a good test), setting a breakpoint at main(), and
repeadly entering "run". More often than not, the program will finish
instead of hitting the breakpoint.

It's not powerpc-general, since a ibm440 evbppc system does much
better. The symptoms generally point to an icache synchronization
issue.

Some tracing later, the problem appears to be with process_domem(),
uvm_io(), and pmap_procwr().

GDB sets a breakpoint with ptrace(PT_WRITE_D) or ptrace(PT_IO), which
invokes process_domem(). In turn, that does its data move with
uvm_io(), which maps the relevant section of the target process into
the kernel's address space, writes to it, and then unmaps
it. process_domem() then calls pmap_procwr() to do any writeback/cache
flushing necessary, passing the virtual address and length. The OEA
pmap looks up that VA in the target process's map, but finds that it's
not there - gdb is writing to the page before it's been executed by
the process. So it punts, the icache is left with the old contents,
and the breakpoint isn't hit.

The problem can be fixed in a pretty clunky way by calling:

   uvm_fault(&vm->vm_map, trunc_page(addr), VM_PROT_EXECUTE);

before pmap_procwr() in process_domem(), thus ensuring that the page
is present in the target pmap, but this seems like the wrong layer; I
think pmap_procwr() should do something different to get at the
underlying physical page even if it's not currently in the PTEGs.

Suggestions?

        - Nathan