notes from 2008-06-18 - vfork and debuginfo

[Andrew Cagney <cagney@redhat.com>]

debuginfo:

bauerman, live from the gcc summit, gave an update of the debug-info 
presentation.  While nothing was immediately resolved, there was a good 
consensus that the problems with debug-info quality from GCC needed to 
be addressed, more in the future.  One key highlight was general 
recognition that GCC would need to locally check test the quality of its 
debug info.

vfork:

pmuldoon and cagney had a lively (at least for them :-) discussion on vfork.

pmuldoon identified the essential issue being that after a vfork, the 
vchild (so you don't get confused with a fork's child, groan :-) and 
parent share a common address space; more specifically that common 
address space contains breakpoints from both the parent and the vchild.  
This in turn means:

-> the vchild can hit any parent breakpoint (since they are still 
inserted in memory)
-> the parent could hit any vchild breakpoint (unless they are removed 
after the vchild execs/exits)

Comparing the existing fork and clone models, the discussion concluded 
that vfork is closer to clone in that the parent and vchild share a common:

-> memory address spaces
In particular the LogicalMemoryBuffer and AddressSpaceByteBuffer which 
ensures that, to the user, the inserted breakpoints are not visible.  
This relying on ...

-> breakpoint tables
The combination of BreakpointAddresses and Breakpoint that tracks where 
breakpoints are inserted, and which Task[s] each belongs to.

which is on par with parent/clone.

This leads to the aproach:

-> at the vfork

Like for clone, vchild's process shares the parent's 
memory-address-space and breakpoint-table (a.k.a. BreakpointAddresses?) 
(not a clone or copy).  This ensures that any breakpoints inserted for 
the vchild are reflected in the parent's breakpoint table / memory. And 
similarly, when a parent breakpoint is hit by the vchild's thread[s] the 
breakpoint logic can recognize this.

-> at the exec/exit

The vchild creates a new breakpoint-table and memory-address-space, 
while also telling the parent's breakpoint-table to remove any 
breakpoints belonging to the vchild

Notes:

- an aternative, to model more like fork, would be to pull all 
breakpoints at the vfork, and then re-instate them when the vchild 
exits/execs (assuming there isn't a race with the parent), but 
conversely ...

- the above approach could perhaps be applied to simple fork, instead of 
pulling all breakpoints in the child, leave them in place and ignore 
them - less i/o :-)

- an example of a vchild breakpoint is during a "next" where a temporary 
per-thread breakpoint is inserted; of course an easier example is to 
explicitly insert a breakpoint

:-)