On Wed, Mar 10, 1999 at 10:27:07AM -0800, Jason Thorpe wrote:
> When you set a breakpoint, you're modifying the page.  Since text pages
> are read-only, we must map the page read-write, modify the page, and
> set it back to read-only.
> Since the text page may be shared, we must copy it before we modify it,
> and turn it into an anonymous memory page, backed by swap.  Make sure
> it's marked dirty so that it's cleaned to swap so that faulting it back
> in will work.  This is just basic copy-on-write.
 
yes, that's the way it works.  program text is mapped read-only/copy-on-write.
the ptrace code has to change the protection (temporary) to 
read-write/copy-on-write in order to write the debug info.  then it
changes it back.


> Here is my guess:
> I suspect that somewhere along the line, in the new path that UVM takes
> to do this sort of thing, the page is becoming reassociated with the
> vnode from which it originally came, so that when the fault happens when
> the process runs again, the text page is pulled from the vnode, thus
> losing your breakpoint (and maybe `leaking' a page of swap, if the COW'd
> text page was clened!)
> Are we losing `anon' entries?
> Chuck?  Insights on this?

the only way to know for sure is to check.   the thing to do when it fails
is to look at the map and see if there is an anon mapped in at the breakpoint
address or not.  if there is, then i'd check the page for modified data.
given that the arm32 has seperate I/D VAC caches it is possible that the 
data could have gotten lost in the cache handling code.   if it is not there,
then it is possible that we are losing anon entries.

ddb "show map/f" should help some, but i don't think there is a call
to examine an amap (?).


chuck