Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org
Subject: Re: remote, defer deleting the inferior until it is mourned
Date: Fri, 12 Dec 2008 13:52:00 -0000	[thread overview]
Message-ID: <200812121351.54822.pedro@codesourcery.com> (raw)
In-Reply-To: <200812120111.13658.pedro@codesourcery.com>

[-- Attachment #1: Type: text/plain, Size: 1093 bytes --]

On Friday 12 December 2008 01:11:13, Pedro Alves wrote:
> To fix this, we either set inferior_ptid to null_ptid before deleting the
> inferior when we want to prevent this, or, we defer deleting the inferior to
> generic_mourn_inferior, which does just that.  I've done the latter.

Next in queue, make the extended-remote version of mourning always
call generic_mourn_inferior, to always get rid of the current inferior,
even if there are more inferiors to debug.  This only became possible
since the change to make handle_inferior_event switch inferior_ptid to the
event ptid on a process exit (we were also discarding leftover
unprocessed events from the wrong inferior before that change, just a
bit above the generic_mourn_inferior call I'm moving).

Tested against an x86_64-linux-gnu gdbserver.  Checked in.


The next issue is that extended_remote_mourn is handling the switching
to another process itself, which was an idea borrowed from the linux
multi-fork support.  This is problematic for a few reasons, and would be
best done in common code.  More on that soon.

-- 
Pedro Alves

[-- Attachment #2: remote_mourn_2.diff --]
[-- Type: text/x-diff, Size: 1163 bytes --]

2008-12-12  Pedro Alves  <pedro@codesourcery.com>

	* remote.c (extended_remote_mourn_1): Always call
	generic_mourn_inferior.

---
 gdb/remote.c |    7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

Index: src/gdb/remote.c
===================================================================
--- src.orig/gdb/remote.c	2008-12-12 13:03:23.000000000 +0000
+++ src/gdb/remote.c	2008-12-12 13:03:52.000000000 +0000
@@ -6551,6 +6551,9 @@ extended_remote_mourn_1 (struct target_o
   /* Unlike "target remote", we do not want to unpush the target; then
      the next time the user says "run", we won't be connected.  */
 
+  /* Call common code to mark the inferior as not running.	*/
+  generic_mourn_inferior ();
+
   if (have_inferiors ())
     {
       extern void nullify_last_target_wait_ptid ();
@@ -6562,10 +6565,6 @@ extended_remote_mourn_1 (struct target_o
     }
   else
     {
-      struct remote_state *rs = get_remote_state ();
-
-      /* Call common code to mark the inferior as not running.	*/
-      generic_mourn_inferior ();
       if (!remote_multi_process_p (rs))
 	{
 	  /* Check whether the target is running now - some remote stubs

      reply	other threads:[~2008-12-12 13:52 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-12  1:11 Pedro Alves
2008-12-12 13:52 ` Pedro Alves [this message]

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=200812121351.54822.pedro@codesourcery.com \
    --to=pedro@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