From: Pedro Alves <palves@redhat.com>
To: gdb-patches <gdb-patches@sourceware.org>
Cc: Doug Evans <dje@google.com>
Subject: [PUSHED] infcmd.c: Remove stale TODO
Date: Thu, 21 Aug 2014 16:34:00 -0000 [thread overview]
Message-ID: <53F61FA6.5050506@redhat.com> (raw)
In-Reply-To: <CADPb22TYEXfSVmgDKFTOqmfEH3soSJyUkmUY84yypRYfQ5qKXw@mail.gmail.com>
This TODO has been stale for over 2 years. In bd5635a1 (1991), we
already see the comment, when we only had a bare attach_command:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/*
* TODO:
* Should save/restore the tty state since it might be that the
* program to be debugged was started on this tty and it wants
* the tty in some state other than what we want. If it's running
* on another terminal or without a terminal, then saving and
* restoring the tty state is a harmless no-op.
* This only needs to be done if we are attaching to a process.
*/
/*
* attach_command --
* takes a program started up outside of gdb and ``attaches'' to it.
* This stops it cold in its tracks and allows us to start tracing it.
* For this to work, we must be able to send the process a
* signal and we must have the same effective uid as the program.
*/
void
attach_command (args, from_tty)
char *args;
int from_tty;
{
target_attach (args, from_tty);
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Later in b5a3d2aa (1992) target_terminal_init, etc. calls are added to
attach_command, and in 7e97eb28 (1992) we see:
+ /* If we attached to the process, we might or might not be sharing
+ a terminal. Avoid printing error msg if we are unable to set our
+ terminal's process group to his process group ID. */
+ if (!attach_flag) {
+ OOPSY ("ioctl TIOCSPGRP");
Clearly the TODO has been stale for a long while.
I considered preserving the text elsewhere, but then thought the
comments in inflow.c already have all the necessary info.
gdb/ChangeLog:
* infcmd.c (attach_command): Remove comment.
---
gdb/ChangeLog | 4 ++++
gdb/infcmd.c | 10 ----------
2 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index fae78e5..bf7f618 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,7 @@
+2014-08-21 Pedro Alves <palves@redhat.com>
+
+ * infcmd.c (attach_command): Remove comment.
+
2014-08-21 Bin Cheng <bin.cheng@arm.com>
* aarch64-linux-nat.c (dr_changed_t): Change the type from
diff --git a/gdb/infcmd.c b/gdb/infcmd.c
index bc42cea..b6aba04 100644
--- a/gdb/infcmd.c
+++ b/gdb/infcmd.c
@@ -2365,16 +2365,6 @@ proceed_after_attach (int pid)
do_cleanups (old_chain);
}
-/*
- * TODO:
- * Should save/restore the tty state since it might be that the
- * program to be debugged was started on this tty and it wants
- * the tty in some state other than what we want. If it's running
- * on another terminal or without a terminal, then saving and
- * restoring the tty state is a harmless no-op.
- * This only needs to be done if we are attaching to a process.
- */
-
/* attach_command --
takes a program started up outside of gdb and ``attaches'' to it.
This stops it cold in its tracks and allows us to start debugging it.
--
1.9.3
next prev parent reply other threads:[~2014-08-21 16:34 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-23 20:59 [PATCH v6 0/2] enable target-async by default Pedro Alves
2014-05-23 20:59 ` [PATCH v6 1/2] Make display_gdb_prompt CLI-only Pedro Alves
2014-05-23 20:59 ` [PATCH v6 2/2] enable target async by default; separate MI and target notions of async Pedro Alves
2014-05-24 7:03 ` Eli Zaretskii
2014-05-29 13:49 ` Pedro Alves
2014-07-30 18:40 ` Doug Evans
2014-05-29 13:44 ` [pushed] Re: [PATCH v6 0/2] enable target-async by default Pedro Alves
2014-07-01 16:28 ` Regression for attach from stdin [Re: [pushed] Re: [PATCH v6 0/2] enable target-async by default] Jan Kratochvil
2014-07-02 8:59 ` Mark Wielaard
2014-07-02 9:16 ` Pedro Alves
2014-07-03 15:39 ` Pedro Alves
2014-07-04 13:48 ` [PATCH] Fix "attach" command vs user input race [Re: Regression for attach from stdin [Re: [pushed] Re: [PATCH v6 0/2] enable target-async by default]] Pedro Alves
2014-07-04 21:13 ` Mark Wielaard
2014-07-07 16:39 ` Doug Evans
2014-07-08 15:24 ` Pedro Alves
2014-07-09 16:37 ` Doug Evans
2014-07-09 17:09 ` [pushed+7.8] " Pedro Alves
2014-07-29 22:03 ` Doug Evans
2014-07-29 23:10 ` Doug Evans
2014-07-30 12:46 ` Pedro Alves
2014-07-30 12:38 ` Pedro Alves
2014-07-30 16:59 ` Doug Evans
2014-08-21 16:34 ` Pedro Alves [this message]
2014-09-03 7:59 ` Regression: GDB stopped on run with attached process (PR 17347) [Re: [pushed+7.8] Re: [PATCH] Fix "attach" command vs user input race [Re: Regression for attach from stdin [Re: [pushed] Re: [PATCH v6 0/2] enable target-async by default]]] Jan Kratochvil
2014-09-03 20:11 ` Regression: GDB stopped on run with attached process (PR 17347) [Re: [pushed+7.8] Re: [PATCH] Fix "attach" command vs user input race Pedro Alves
2014-09-07 19:28 ` Jan Kratochvil
2014-09-08 16:19 ` [PATCH 1/2] testsuite: refactor spawn and wait for attach (was: Re: Regression: GDB stopped on run with attached process) Pedro Alves
2014-09-09 17:29 ` Jan Kratochvil
2014-09-09 17:35 ` [PATCH 1/2] testsuite: refactor spawn and wait for attach Pedro Alves
2014-09-10 21:25 ` Pedro Alves
2014-09-11 12:34 ` Pedro Alves
2014-09-08 16:27 ` Regression: GDB stopped on run with attached process (PR 17347) [Re: [pushed+7.8] Re: [PATCH] Fix "attach" command vs user input race Pedro Alves
2014-09-09 18:25 ` Jan Kratochvil
2014-09-11 12:36 ` Pedro Alves
2014-09-12 7:34 ` [testsuite patch] runaway attach processes [Re: Regression: GDB stopped on run with attached process (PR 17347)] Jan Kratochvil
2014-09-12 10:14 ` Pedro Alves
2014-09-12 11:40 ` [commit] " Jan Kratochvil
2014-07-07 17:02 ` [PATCH] Fix "attach" command vs user input race [Re: Regression for attach from stdin [Re: [pushed] Re: [PATCH v6 0/2] enable target-async by default]] Jan Kratochvil
2014-10-05 14:00 ` Crash regression for annota1.exp w/vDSO debuginfo [Re: [pushed] Re: [PATCH v6 0/2] enable target-async by default] Jan Kratochvil
2014-10-05 14:14 ` Jan Kratochvil
2014-10-05 16:43 ` Jan Kratochvil
2014-10-09 15:48 ` Pedro Alves
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=53F61FA6.5050506@redhat.com \
--to=palves@redhat.com \
--cc=dje@google.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).