Subject: Re: pmap_procwr() for signal trampoline
To: None <port-mips@netbsd.org>
From: Toru Nishimura <nisimura@itc.aist-nara.ac.jp>
List: port-mips
Date: 09/27/2001 12:01:50
>> 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