From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 50295 invoked by alias); 19 Mar 2019 20:14:55 -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 50287 invoked by uid 89); 19 Mar 2019 20:14:55 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (209.51.188.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 19 Mar 2019 20:14:53 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:34126) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h6L8L-0003Ni-VD; Tue, 19 Mar 2019 16:14:51 -0400 Received: from [176.228.60.248] (port=2297 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h6L8E-0000eL-6l; Tue, 19 Mar 2019 16:14:43 -0400 Date: Tue, 19 Mar 2019 20:14:00 -0000 Message-Id: <83ftritydv.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves CC: tom@tromey.com, gdb-patches@sourceware.org In-reply-to: <711b6636-b02c-edb2-308d-5fddbf4c33a9@redhat.com> (message from Pedro Alves on Tue, 19 Mar 2019 19:02:43 +0000) Subject: Re: [PATCH] Readline: Cleanup some warnings References: <20190130085716.75179-1-alan.hayward@arm.com> <20190131075907.GA313@adacore.com> <3463805B-A8BF-4C20-ACE3-C21AE3F7DB62@arm.com> <20190201080533.GA31043@adacore.com> <877eejvfoq.fsf@tromey.com> <1549047248.2630.7.camel@skynet.be> <310315f8-62ab-2eff-042f-9f2ae9de07da@redhat.com> <87wokxtnlt.fsf@tromey.com> <83h8c1wdr5.fsf@gnu.org> <87imwex333.fsf@tromey.com> <711b6636-b02c-edb2-308d-5fddbf4c33a9@redhat.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-IsSubscribed: yes X-SW-Source: 2019-03/txt/msg00419.txt.bz2 > Cc: gdb-patches@sourceware.org > From: Pedro Alves > Date: Tue, 19 Mar 2019 19:02:43 +0000 > > > https://sourceware.org/ml/gdb-patches/2008-02/msg00423.html Caveat: I didn't yet read that thread myself. > Hmmm, > > Daniel wrote: > > > GDB has several SIGINT handlers which call longjmp. This is > > problematic for at least two reasons. One is that we could be in the > > middle of something unwise to longjmp out of, for instance malloc. In > > practice, this never happens because we're usually waiting for I/O > > when one of the relevant handlers is invoked, but there are a number > > of places where it could definitely happen. > > That was indeed true back then, but since then, immediate_quit > was completely eliminated, and we no longer longjmp from signal > handlers anymore, since: > https://sourceware.org/ml/gdb-patches/2016-03/msg00351.html > > Daniel wrote: > > > My goals in fixing this were to hide the Windows ugliness, and to fit > > in nicely with GDB's asynchronous event loop. Since we do not return > > to the primary event loop during target actions (for the current, > > non-async GDB), I couldn't rely on the event loop entirely. But I > > could use the same token mechanism and thus share the bodies of > > handlers for async mode with the Windows case. > > > > The new interface is gdb_call_async_signal_handler. SIGINT handlers, > > This interface he mentioned, gdb_call_async_signal_handler, was > eliminated by that series too: > > https://sourceware.org/ml/gdb-patches/2016-03/msg00347.html > > So all that's left is that little readline hack, it seems: > > /* With multi-threaded SIGINT handling, there is a race between the > readline signal handler and GDB. It may still be in > rl_prep_terminal in another thread. Do not return until it is > done; we can check the state here because we never longjmp from > signal handlers on Windows. */ > while (RL_ISSTATE (RL_STATE_SIGHANDLER)) > Sleep (1); > > (Curiously, that bit only appeared in a later version of Dan's patch, > here: https://sourceware.org/ml/gdb-patches/2008-03/msg00034.html) > > I'm not seeing why we'd still need that bit, but then again, > I'm not seeing why it was needed in the first place. > The signal handler could run concurrently with gdb at any other > point in the gdb code, not just here, so at any point we > call into readline, we can be running readline code in parallel > with a signal handler touching readline's state. It sounds like > that should be a readline problem to worry about. > > That could be related to the fact that readline's signal handler > overrides gdb's, does its thing, and then calls gdb's signal > handler manually? If the WaitForSingleObject call had already > woken up, then gdb's signal handler has already run and SetEvent > on sigint_event. Then the code would go and run the deferred > signal handler. In the remote case, that handler would > issue prompt "Give up (and stop debugging it)? (y or n)" prompt, > and if that is running in parallel with readline's signal > handler still calling rl_prep_terminal, bad things would happen. Not sure if the above refers to what I wanted to say, but: as I'm sure you know, SIGINT handlers on Windows run in a separate thread, created by the OS, so a Readline SIGINT handler could ruin in parallel both with Readline's other code and in parallel with GDB's code, depending on when exactly did the user type Ctrl-C. In a few cases where it was important to emulate Posix behavior in order not to step on the troes of the mainline code, I needed to stop the main thread while the SIGINT handler was running. Could it be that the code we are discussing does something similar? > But again, why isn't that a readline problem, instead of > a gdb problem? I agree: the right solution would be for the Readline's SIGINT handler to stop the main thread (e.g., by using SuspendThread). > I'm still puzzled on why this isn't a readline issue. Shouldn't > readline's Windows signal handler be synchronizing with mainline > code such that if a signal handler is running, mainline calls into > readline would block? Yes, I think so. > I think there must be something else to this. Maybe. I will try to read that discussion soon. Thanks.