Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Burgess <andrew.burgess@embecosm.com>
To: Andreas Schwab <schwab@linux-m68k.org>
Cc: Alan Hayward <Alan.Hayward@arm.com>,
	"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
	nd <nd@arm.com>, Pedro Alves <palves@redhat.com>
Subject: Re: [PATCH] Supress SIGTTOU when handling errors
Date: Sun, 19 May 2019 22:06:00 -0000	[thread overview]
Message-ID: <20190519220622.GB2568@embecosm.com> (raw)
In-Reply-To: <87y333ev6j.fsf@igel.home>

* Andreas Schwab <schwab@linux-m68k.org> [2019-05-18 15:41:56 +0200]:

> On Mai 16 2019, Alan Hayward <Alan.Hayward@arm.com> wrote:
> 
> > [I've seen this on and off over many months on AArch64 and Arm, and am
> > assuming it isn't the intended behaviour. Not sure if this should be at
> > tcdrain or it should be done at a higher level - eg in the terminal
> > handling code]
> >
> > Calls to error () can cause SIGTTOU to send gdb to the background.
> >
> > For example, on an Arm build:
> >   (gdb) b main
> >   Breakpoint 1 at 0x10774: file /build/gdb/testsuite/../../../src/binutils-gdb/gdb/testsuite/gdb.base/watchpoint.c, line 174.
> >   (gdb) r
> >   Starting program: /build/gdb/testsuite/outputs/gdb.base/watchpoint/watchpoint
> >
> >   [1]+  Stopped                 ../gdb ./outputs/gdb.base/watchpoint/watchpoint
> 
> e671cd59d74cec9f53e110ce887128d1eeadb7f2 is the first bad commit
> commit e671cd59d74cec9f53e110ce887128d1eeadb7f2
> Author: Pedro Alves <palves@redhat.com>
> Date:   Tue Jan 30 14:23:51 2018 +0000
> 
>     Per-inferior target_terminal state, fix PR gdb/13211, more
> 
> Andreas.

Andreas,

Thanks for tracking this down.

It appears that the change in this patch that seems to be responsible
would correspond to Alan's patch #2 option.

I wonder if we should just apply something like the below to revert
part of Pedro's patch?  This will fix this problems we're seeing (as
Alan already pointed out) as this effectively makes 'ours_for_output
()' the same as 'ours ()' again.

My concern would be whether there's going to be some place in GDB that
calls 'ours_for_output ()' and assumes Ctrl-C / Ctrl-Z will be
automatically passed to the inferior.  This change means they are now
passed to GDB instead, will GDB always forward these to the inferior
correctly?

Thanks,
Andrew



--

diff --git a/gdb/inflow.c b/gdb/inflow.c
index 339b55c0bc6..6ed22c14b6b 100644
--- a/gdb/inflow.c
+++ b/gdb/inflow.c
@@ -506,10 +506,11 @@ child_terminal_ours_1 (target_terminal_state desired_state)
       /* Set tty state to our_ttystate.  */
       serial_set_tty_state (stdin_serial, our_terminal_info.ttystate);
 
-      /* If we only want output, then leave the inferior's pgrp in the
-	 foreground, so that Ctrl-C/Ctrl-Z reach the inferior
-	 directly.  */
-      if (job_control && desired_state == target_terminal_state::is_ours)
+      /* If might be tempting to think that we can leave the inferior's
+	 pgrp in the foreground if we only want ours_for_output, however,
+	 calls to tcdrain within GDB will result in SIGTTOU unless GDB's
+	 process group is in the foreground.  */
+      if (job_control)
 	{
 #ifdef HAVE_TERMIOS_H
 	  result = tcsetpgrp (0, our_terminal_info.process_group);
@@ -526,7 +527,7 @@ child_terminal_ours_1 (target_terminal_state desired_state)
 #endif /* termios */
 	}
 
-      if (!job_control && desired_state == target_terminal_state::is_ours)
+      if (!job_control)
 	{
 	  signal (SIGINT, sigint_ours);
 #ifdef SIGQUIT


  reply	other threads:[~2019-05-19 22:06 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-16 15:51 Alan Hayward
2019-05-16 18:06 ` Andrew Burgess
2019-05-16 18:30   ` Andrew Burgess
2019-05-23 20:33     ` Pedro Alves
2019-05-17 12:47   ` Alan Hayward
2019-05-18  9:10     ` Andrew Burgess
2019-05-23 20:32   ` Pedro Alves
2019-05-24  8:54     ` Alan Hayward
     [not found]       ` <7483f478-44d2-b2ce-b0cb-3e984054305a@redhat.com>
2019-05-24 12:36         ` Alan Hayward
2019-05-24 13:15           ` Pedro Alves
2019-05-26 22:43           ` Andrew Burgess
2019-05-27 18:03             ` Pedro Alves
2019-05-28  9:39               ` Alan Hayward
2019-08-02 16:05                 ` [8.3 backport] " Tom de Vries
2019-08-05 10:59                   ` Alan Hayward
2019-08-05 17:33                   ` Tom Tromey
2019-05-18 13:42 ` [PATCH] " Andreas Schwab
2019-05-19 22:06   ` Andrew Burgess [this message]
2019-05-20  8:44     ` Alan Hayward
     [not found]       ` <20190520091157.GC2568@embecosm.com>
2019-05-20  9:49         ` Pedro Alves
2019-05-23 20:35         ` 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=20190519220622.GB2568@embecosm.com \
    --to=andrew.burgess@embecosm.com \
    --cc=Alan.Hayward@arm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=nd@arm.com \
    --cc=palves@redhat.com \
    --cc=schwab@linux-m68k.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