From: Yao Qi <yao@codesourcery.com>
To: <donb@codesourcery.com>, <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Fix for gdb/PR 14808, vfork/exec inferior problem
Date: Thu, 15 May 2014 07:08:00 -0000 [thread overview]
Message-ID: <5374675C.3000907@codesourcery.com> (raw)
In-Reply-To: <1399937655-29577-1-git-send-email-donb@codesourcery.com>
05/13/2014 07:34 AM, donb@codesourcery.com wrote:
> @@ -649,6 +649,7 @@ handle_vfork_child_exec_or_exit (int exec)
> struct cleanup *old_chain;
> struct program_space *pspace;
> struct address_space *aspace;
> + struct inferior *parent_inf;
>
Local parent_inf is only used in the "if (exec)" block below, so better
to declare it there.
> /* follow-fork child, detach-on-fork on. */
>
> @@ -665,27 +666,39 @@ handle_vfork_child_exec_or_exit (int exec)
> else
> old_chain = save_current_space_and_thread ();
>
> - /* We're letting loose of the parent. */
> + /* Make the parent the current inferior for target_detach. */
> tp = any_live_thread_of_process (inf->vfork_parent->pid);
> switch_to_thread (tp->ptid);
>
> - /* We're about to detach from the parent, which implicitly
> - removes breakpoints from its address space. There's a
> - catch here: we want to reuse the spaces for the child,
> - but, parent/child are still sharing the pspace at this
> - point, although the exec in reality makes the kernel give
> - the child a fresh set of new pages. The problem here is
> - that the breakpoints module being unaware of this, would
> - likely chose the child process to write to the parent
> - address space. Swapping the child temporarily away from
> - the spaces has the desired effect. Yes, this is "sort
> - of" a hack. */
> -
> + /* The child inferior INF may be dead, so avoid giving the
> + breakpoints module the option to write through to it
> + by swapping the child temporarily away from the spaces
> + (cloning a program space resets breakpoints). */
> pspace = inf->pspace;
> aspace = inf->aspace;
> inf->aspace = NULL;
> inf->pspace = NULL;
>
> + if (exec)
> + {
> + /* The parent and child inferiors have been sharing
> + program and address space structures from the point
> + where the parent called vfork. Now that the child has
> + called exec and we are detaching from the parent, the
> + parent inferior needs to have its own pspace and aspace
parent inferior has its own pspace, but may not have its own aspace,
depending on gdbarch_has_shared_address_space.
> + so that changes in the child don't affect it. We have
> + to give the new spaces to the parent since we saved the
> + child's spaces as the current spaces above. Even though
> + we are detaching the parent, we want to keep the
> + corresponding entry in the inferiors list intact. */
> + parent_inf = current_inferior ();
> + parent_inf->aspace = new_address_space ();
Rather than creating a new address space, use maybe_new_address_space, like
> + parent_inf->pspace = add_program_space (parent_inf->aspace);
parent_inf->pspace
= add_program_space (maybe_new_address_space ());
parent_inf->aspace = parent_inf->pspace->aspace;
> + parent_inf->removable = inf->removable;
Field removable of parent inferior should be unchanged, IMO.
> + set_current_program_space (parent_inf->pspace);
> + clone_program_space (parent_inf->pspace, pspace);
Do we need to unlink parent and child? I am not very sure.
/* Break the bonds. */
inf->vfork_parent->vfork_child = NULL;
--
Yao (é½å°§)
next prev parent reply other threads:[~2014-05-15 7:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-12 23:34 donb
2014-05-15 7:08 ` Yao Qi [this message]
2014-05-15 20:43 Don Breazeal
2014-05-24 0:59 ` Yao Qi
2014-05-27 17:01 ` Breazeal, Don
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5374675C.3000907@codesourcery.com \
--to=yao@codesourcery.com \
--cc=donb@codesourcery.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).