>> However, is it
>> _really_ worth doing such the thing in such the way after all?
>
>  I don't know about signal delivery, but I think I had that added to deal
> with gdb modifying process memory for inserting and removing breakpoints.

I failed to consider of modifying instructions in text segment.

pmap_procwr() is called every time when sys_execve()::sys/kern_exec.c
is about to run a new process.  It does 16B write-back operation on
user stack location 2GB - 32B.  I think it's unnecessary to do so
either for R3000 or R4000 case.

pmap_prowr() is also called mips/mips/procfs_mem.c and I see software
breakpointing is a trouble source.  I suspect the issue can be solved
in other ways.  pmap_procwr() could be reduced into the simpler form
of VA->PA->KSEG0 for both cases.

> Part of the problem with that is that the current process (gdb) is
> modifying a different process's memory, which complicates dealing with the
> virually indexed cache.  Since the user page has been mapped into the
> current process's address space [kernel address space, I think], the
> virtual address won't be correct and you can't simply use the hit cache
> op.  Before pmap_procwr() was implemented, there were lots of strange
> problems setting breakpoints.

Tohru Nishimura