* follow-on{fork|clone}
@ 2008-03-03 14:32 Phil Muldoon
2008-03-03 14:58 ` follow-on{fork|clone} Andrew Cagney
2008-03-03 16:27 ` follow-on{fork|clone} Tom Tromey
0 siblings, 2 replies; 3+ messages in thread
From: Phil Muldoon @ 2008-03-03 14:32 UTC (permalink / raw)
To: frysk, Tom Tromey
Tom
This is something you have brought up before on at various times, and
lists, and I thought once and for all to collate some knowledge here.
Given that you turn off follow-on-fork sometimes (in GDB) is that
mechanic useful for Frysk as well? Why do you turn it off? Is it because
of bugs, or more of a focus?
I ask mainly to collate user experience here and see if it's a valid
feature. In writing watchpoints I personally cannot see why
follow-on-{fork|clone} would ever be turned off, but it occurs to me
then that the mechanic might be desirable elsewhere.
What do you think?
Regards
Phil
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: follow-on{fork|clone}
2008-03-03 14:32 follow-on{fork|clone} Phil Muldoon
@ 2008-03-03 14:58 ` Andrew Cagney
2008-03-03 16:27 ` follow-on{fork|clone} Tom Tromey
1 sibling, 0 replies; 3+ messages in thread
From: Andrew Cagney @ 2008-03-03 14:58 UTC (permalink / raw)
To: Phil Muldoon; +Cc: frysk, Tom Tromey
Phil,
Consider:
(fhpd) load gcc
(fhpd) break cc1.c#foo
(fhpd) run test.c -o test
which involves forks, and possibly execs. From the user's point-of-view
that should "just work". This means automatically (no interaction)
following forks and execs. This has always been our goal.
An option to disable the automatic behavior may be interesting, but can
be added later.
Andrew
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: follow-on{fork|clone}
2008-03-03 14:32 follow-on{fork|clone} Phil Muldoon
2008-03-03 14:58 ` follow-on{fork|clone} Andrew Cagney
@ 2008-03-03 16:27 ` Tom Tromey
1 sibling, 0 replies; 3+ messages in thread
From: Tom Tromey @ 2008-03-03 16:27 UTC (permalink / raw)
To: Phil Muldoon; +Cc: frysk
Phil> Given that you turn off follow-on-fork sometimes (in GDB) is
Phil> that mechanic useful for Frysk as well? Why do you turn it off?
Phil> Is it because of bugs, or more of a focus?
In gdb it is off by default. Or, more precisely, gdb just has one
setting -- follow the parent or follow the child -- and it defaults to
follow the parent.
At least on FC-6, with the distro gdb, it is also buggy. I don't
think I've had it work successfully.
With CVS gdb it seems a bit better.
So, it is a combo: partly bugs but partly because usually I want to
follow the parent. This latter thing is a false dichotomy, my hope
for frysk is that I won't have to choose.
Phil> In writing watchpoints I personally cannot see why
Phil> follow-on-{fork|clone} would ever be turned off
One might imagine the debugger using too much memory as it attaches to
and loads debug info for every application in a big hierarchy of
fork/execs. (I have no idea how fhpd scales here.) In a situation
like this you'd want to be able to control things more tightly.
For the kind of debugging I'm doing right now, yeah, I would like to
simply watch all the processes started from "gcc" and have fhpd show
me when any of them crashes. That would be delightful and is really
not possible with gdb today.
Tom
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2008-03-03 16:27 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-03-03 14:32 follow-on{fork|clone} Phil Muldoon
2008-03-03 14:58 ` follow-on{fork|clone} Andrew Cagney
2008-03-03 16:27 ` follow-on{fork|clone} 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).