public inbox for
 help / color / mirror / Atom feed
* notes from 2008-06-18 - vfork and debuginfo
@ 2008-06-21 14:18 Andrew Cagney
  0 siblings, 0 replies; only message in thread
From: Andrew Cagney @ 2008-06-21 14:18 UTC (permalink / raw)
  To: frysk


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.


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


- 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


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2008-06-21 14:14 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-06-21 14:18 notes from 2008-06-18 - vfork and debuginfo Andrew Cagney

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).