This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Fix foll-fork.exp foll-vfork.exp fork-child-threads.exp
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: pedro at codesourcery dot com (Pedro Alves)
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 20 Nov 2008 19:24:27 +0100 (CET)
- Subject: Re: Fix foll-fork.exp foll-vfork.exp fork-child-threads.exp
Pedro Alves wrote:
> On Thursday 20 November 2008 16:36:58, Ulrich Weigand wrote:
> > As a separate question, I'm wondering why this is the right place to
> > put the follow-fork logic anyway (and not in handle_inferior_event
> > like follow-exec ...). Do you know the history of this?
>
> To be able to decide if you want to follow a child or a parent
> when you catch a fork with "catch fork".
Ah, I see. Makes sense.
However, even given that we need to do it in "resume" -- why so late
in resume, after e.g. displaced stepping or software single-step
was already set up? For example, isn't singlestep_ptid set to the
wrong value if we later decide to follow the child?
It seems to me it would make more sense to have that decision come
*first* -- and then we could use the correct thread_info and regcache
etc. pointers throughout. I guess there may have been a good reason
to place the call where it is, but I don't see it off-hand ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com