Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Hui Zhu <hui_zhu@mentor.com>
To: gdb-patches ml <gdb-patches@sourceware.org>
Cc: Eli Zaretskii <eliz@gnu.org>
Subject: [PATCH/doc] Remove fixme of packet "k"
Date: Fri, 14 Mar 2014 07:22:00 -0000	[thread overview]
Message-ID: <5322AE41.4050008@mentor.com> (raw)

Current introduction of 'k' is:
‘k’
Kill request.
FIXME: There is no description of how to operate when a specific thread context has been selected (i.e. does 'k' kill only that thread?).

I checked the code about this part:
In GDB side:
static void
remote_kill (struct target_ops *ops)
{
   volatile struct gdb_exception ex;

   /* Catch errors so the user can quit from gdb even when we
      aren't on speaking terms with the remote system.  */
   TRY_CATCH (ex, RETURN_MASK_ERROR)
     {
       putpkt ("k");
     }
   if (ex.reason < 0)
     {
       if (ex.error == TARGET_CLOSE_ERROR)
	{
	  /* If we got an (EOF) error that caused the target
	     to go away, then we're done, that's what we wanted.
	     "k" is susceptible to cause a premature EOF, given
	     that the remote server isn't actually required to
	     reply to "k", and it can happen that it doesn't
	     even get to reply ACK to the "k".  */
	  return;
	}

	/* Otherwise, something went wrong.  We didn't actually kill
	   the target.  Just propagate the exception, and let the
	   user o:r higher layers decide what to do.  */
	throw_exception (ex);
     }

   /* We've killed the remote end, we get to mourn it.  Since this is
      target remote, single-process, mourning the inferior also
      unpushes remote_ops.  */
   target_mourn_inferior ();
}

static void
extended_remote_kill (struct target_ops *ops)
{
   int res;
   int pid = ptid_get_pid (inferior_ptid);
   struct remote_state *rs = get_remote_state ();

   res = remote_vkill (pid, rs);
   if (res == -1 && !(rs->extended && remote_multi_process_p (rs)))
     {
       /* Don't try 'k' on a multi-process aware stub -- it has no way
	 to specify the pid.  */

       putpkt ("k");
#if 0
       getpkt (&rs->buf, &rs->buf_size, 0);
       if (rs->buf[0] != 'O' || rs->buf[0] != 'K')
	res = 1;
#else
       /* Don't wait for it to die.  I'm not really sure it matters whether
	 we do or not.  For the existing stubs, kill is a noop.  */
       res = 0;
#endif
     }

   if (res != 0)
     error (_("Can't kill process"));

   target_mourn_inferior ();
}

In gdbserver side:
      fprintf (stderr, "Killing all inferiors\n");
       for_each_inferior (&all_processes, kill_inferior_callback);

       /* When using the extended protocol, we wait with no program
	 running.  The traditional protocol will exit instead.  */
       if (extended_protocol)
	{
	  last_status.kind = TARGET_WAITKIND_EXITED;
	  last_status.value.sig = GDB_SIGNAL_KILL;
	  return 0;
	}
       else
	exit (0);

So make a patch update doc of 'k' to:
‘k’
Kill all processes.

The ‘k’ packet has no reply.

Thanks,
Hui

2014-03-14  Hui Zhu  <hui@codesourcery.com>

	* gdb.texinfo (Packets): Update introduction of 'k'.

--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -33952,11 +33952,9 @@ step packet}.
  
  @item k
  @cindex @samp{k} packet
-Kill request.
+Kill all processes.
  
-FIXME: @emph{There is no description of how to operate when a specific
-thread context has been selected (i.e.@: does 'k' kill only that
-thread?)}.
+The @samp{k} packet has no reply.
  
  @item m @var{addr},@var{length}
  @cindex @samp{m} packet


             reply	other threads:[~2014-03-14  7:22 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-14  7:22 Hui Zhu [this message]
2014-03-14  8:14 ` Eli Zaretskii
2014-03-18 20:52 ` Stan Shebs
2014-03-19  8:02   ` Hui Zhu
2014-03-19 16:12     ` Eli Zaretskii
2014-03-20  3:44       ` Hui Zhu
2014-03-20 13:07         ` Pedro Alves
2014-03-20 17:30           ` Eli Zaretskii
2014-03-20 16:05         ` Eli Zaretskii
2014-03-21  8:26           ` Hui Zhu
2014-03-21  8:38             ` Eli Zaretskii
2014-03-21  9:00               ` Hui Zhu

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=5322AE41.4050008@mentor.com \
    --to=hui_zhu@mentor.com \
    --cc=eliz@gnu.org \
    --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