From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105469 invoked by alias); 23 May 2019 20:35:32 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 105459 invoked by uid 89); 23 May 2019 20:35:32 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=H*f:sk:87y333e, HX-Received:a1c, HX-Languages-Length:1174, H*f:sk:2DDEE8D X-HELO: mail-wm1-f65.google.com Received: from mail-wm1-f65.google.com (HELO mail-wm1-f65.google.com) (209.85.128.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 23 May 2019 20:35:31 +0000 Received: by mail-wm1-f65.google.com with SMTP id x64so7152359wmb.5 for ; Thu, 23 May 2019 13:35:30 -0700 (PDT) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:4eeb:42ff:feef:f164? ([2001:8a0:f913:f700:4eeb:42ff:feef:f164]) by smtp.gmail.com with ESMTPSA id j206sm940474wma.47.2019.05.23.13.35.28 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Thu, 23 May 2019 13:35:28 -0700 (PDT) Subject: Re: [PATCH] Supress SIGTTOU when handling errors To: Andrew Burgess , Alan Hayward References: <20190516155150.71826-1-alan.hayward@arm.com> <87y333ev6j.fsf@igel.home> <20190519220622.GB2568@embecosm.com> <2DDEE8DB-726F-466B-AB69-593351102ECB@arm.com> <20190520091157.GC2568@embecosm.com> Cc: Andreas Schwab , "gdb-patches@sourceware.org" , nd From: Pedro Alves Message-ID: <4adc2dd1-4b5b-f650-dad2-7ddf1433ab85@redhat.com> Date: Thu, 23 May 2019 20:35:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20190520091157.GC2568@embecosm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-05/txt/msg00550.txt.bz2 On 5/20/19 10:11 AM, Andrew Burgess wrote: > I share your concern, but... > > If you check the comment on 'child_terminal_ours_for_output' you'll > see a little note left from before Pedro's commit e671cd59d74cec9f > which says: > > /* Put some of our terminal settings into effect, > enough to get proper results from our output, > but do not change into or out of RAW mode > so that no input is discarded. > > After doing this, either terminal_ours or terminal_inferior > should be called to get back to a normal state of affairs. > > This next bit is interesting.... > > N.B. The implementation is (currently) no different than > child_terminal_ours. See child_terminal_ours_1. */ > > void > child_terminal_ours_for_output (struct target_ops *self) > { > child_terminal_ours_1 (1); > } Yeah. Whooops, I meant to fix that comment, clearly I forgot... > > So, until Pedro's change 'ours ()' and 'ours_for_output ()' were the > same. Now that doesn't mean we should go back, but I think it means > I'd be willing to consider it (hence why I originally came our against > it, then changed my mind). > Thanks, Pedro Alves