public inbox for frysk@sourceware.org
 help / color / mirror / Atom feed
* vfork thoughts
@ 2008-06-16 13:14 Phil Muldoon
  2008-06-18 23:12 ` Andrew Cagney
  2008-06-20 13:45 ` Tom Tromey
  0 siblings, 2 replies; 3+ messages in thread
From: Phil Muldoon @ 2008-06-16 13:14 UTC (permalink / raw)
  To: frysk

I've bee reading about vfork challenges for the past week. Here are my 
thoughts.

Mark when he fixed an issue related to breakpoints I think crystallized 
the issue with vfork in this thread:

http://article.gmane.org/gmane.comp.monitoring.frysk.general/1072

While at first the issue of breakpoints might seem to be nothing to do 
with vfork(), it is very relevant. Literature suggests that the use of 
vfork for any purpose other than an immediate prelude to an exec call is 
not advisable. However, there could - and probably are - examples of 
where this is not the case. Also as detailed in Mark's email this makes 
the usage of breakpoints troublesome, as child and parent share memory.

If we model vfork transparently though the fork observer then there is a 
danger of the user (be that an actual user, or an api call) assuming 
that the it is a true fork and not a vfork. Is it more sensible to model 
a completely separate set of observers to model vfork? This way, if 
there are breakpoints set in the child (and therefore the parent) we can 
uninstall them after the child execs. However this approach burdens the 
state machine with additional states that would essentially duplicate 
the fork states. Is the replication of code to deal with the vfork 
specific issues warranted here?

If anyone has a real life use case for debugging a vfork scenario we 
could model, that would help also.

Regards

Phil


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: vfork thoughts
  2008-06-16 13:14 vfork thoughts Phil Muldoon
@ 2008-06-18 23:12 ` Andrew Cagney
  2008-06-20 13:45 ` Tom Tromey
  1 sibling, 0 replies; 3+ messages in thread
From: Andrew Cagney @ 2008-06-18 23:12 UTC (permalink / raw)
  To: Phil Muldoon; +Cc: frysk

Phil Muldoon wrote:
> I've bee reading about vfork challenges for the past week. Here are my 
> thoughts.
>
> Mark when he fixed an issue related to breakpoints I think 
> crystallized the issue with vfork in this thread:
>
> http://article.gmane.org/gmane.comp.monitoring.frysk.general/1072
>
> While at first the issue of breakpoints might seem to be nothing to do 
> with vfork(), it is very relevant. Literature suggests that the use of 
> vfork for any purpose other than an immediate prelude to an exec call 
> is not advisable. However, there could - and probably are - examples 
> of where this is not the case. Also as detailed in Mark's email this 
> makes the usage of breakpoints troublesome, as child and parent share 
> memory.
Totally agree.
>
> If we model vfork transparently though the fork observer then there is 
> a danger of the user (be that an actual user, or an api call) assuming 
> that the it is a true fork and not a vfork. Is it more sensible to 
> model a completely separate set of observers to model vfork? This way, 
> if there are breakpoints set in the child (and therefore the parent) 
> we can uninstall them after the child execs. However this approach 
> burdens the state machine with additional states that would 
> essentially duplicate the fork states. Is the replication of code to 
> deal with the vfork specific issues warranted here?
>
> If anyone has a real life use case for debugging a vfork scenario we 
> could model, that would help also.

Perhaps look at the fork/daemon code.  It uses a vfork, followed by a 
fork, followed by an exec.  Stepping through that would be way cool!

>
> Regards
>
> Phil
>
>

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: vfork thoughts
  2008-06-16 13:14 vfork thoughts Phil Muldoon
  2008-06-18 23:12 ` Andrew Cagney
@ 2008-06-20 13:45 ` Tom Tromey
  1 sibling, 0 replies; 3+ messages in thread
From: Tom Tromey @ 2008-06-20 13:45 UTC (permalink / raw)
  To: Phil Muldoon; +Cc: frysk

Phil> If anyone has a real life use case for debugging a vfork scenario we 
Phil> could model, that would help also.

gcc uses vfork when spawning child processes.  And, the code that
actually does this does do some work between the vfork and the exec --
it is extremely common to move file descriptors around here.  So, if
you want to debug in this region, or just want to debug child
processes created by vfork, gcc works :).  There are probably a lot of
other examples like this.

Tom

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2008-06-18 23:12 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-06-16 13:14 vfork thoughts Phil Muldoon
2008-06-18 23:12 ` Andrew Cagney
2008-06-20 13:45 ` Tom Tromey

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