* 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)
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
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
- 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).