public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
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 (齐尧)

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