From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13847 invoked by alias); 23 Jan 2020 02:34:06 -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 13839 invoked by uid 89); 23 Jan 2020 02:34:06 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 spammy=responding, disconnected, Sending X-HELO: esa4.hgst.iphmx.com Received: from esa4.hgst.iphmx.com (HELO esa4.hgst.iphmx.com) (216.71.154.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 23 Jan 2020 02:34:05 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=wdc.com; i=@wdc.com; q=dns/txt; s=dkim.wdc.com; t=1579746845; x=1611282845; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=Pmf6TZ6M3/b7e1vjXWln10BpqiiFVHg3T/jfyU6HQ/s=; b=juEYkr6abaalhkQk0QEnlMDC31C1HVhbC50abN1d8jae65EUYMraGmAh Oac+xDnboGILWKildsppqYp+znvA+RSkwBVsGQQB0GEuU558oIgBuwgDm TocWj3TqXd2VTgzCF+TRMB/QkxwmwU0p6srjBRJXtBLnW+7/s0NoQhsLg SsPH8O4j0/cV1zPVUPpLZKIn1wuz7edg3M9vtMiVvrZ5FB5YygXYCskJl FyMn3GAl3XMFgChNV8dNbhv+FZX01G2CWq4Gbi2anW5dP5izXrjjRf1LK +yZbw2cllKmWE5w0hHDHOTkClInvY3h0n1192Veizk4WV3hCglgsdMYg/ A==; IronPort-SDR: Ounpi3tnjovCATD9x4V75NzB0qqNbKF/Z87GnOst0uRBJ4Mu44B06I5fRYX47FidzKbrZKzl55 y6/uzBH6BpbdzVTH2thJ10UPChChbekSLeOzYPd6qv8iQWktScD57j64YQoKS3ml93frLOSAQo COUcABbM9AJNOun526Vt4cTXCidlu/T9FBgk2lG42eZOdl637GNUw97+ipGk8MvRN2ad67WogV oS8qJxwgDLTURsPa9USORVyCSTkDuzEv2tCbFyYq+hkMfj30hpYxC7yx7DntbUdRMno3WdhAmf bDQ= Received: from uls-op-cesaip01.wdc.com (HELO uls-op-cesaep01.wdc.com) ([199.255.45.14]) by ob1.hgst.iphmx.com with ESMTP; 23 Jan 2020 10:34:03 +0800 IronPort-SDR: LlHWrs/1kAn2UXFDfAaMIMn+rLy17lJH4BkOSHOZyvHNlOSN1lNPjZp0n71OA6i2j4USIMuMGd s2FuRni2H8oSCp0FAo3joQnwxiVGa2+A/O2LJOjWBa3zajnue94f8fSwSV7qkl8yCIDElC/3tM fhQ6Xl2bmliPaUj3huUT34qKjhKwoqDPlOJrWah61dXa7P5y4Fg6ENkNdj3ruXzxYeErg1QEwx SZD+j8DUhVFRMxIyeOXpz9DRkCg/CnqYUI9vxQxeUTQhaMhzTVKuUlYthszouB78679n+UomQi 8zULqQhJE9AA2sagoUbmcmmw Received: from uls-op-cesaip01.wdc.com ([10.248.3.36]) by uls-op-cesaep01.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Jan 2020 18:27:27 -0800 IronPort-SDR: 0Bdnf+Q3vqS6+L2izh/9emkZF0zZkkId0R3uIq0RQcFDSlwSs3ikqI5Mj+Kz12w6c2TDnfdlvt FhT0TNNk/kSfWgzNueb6QkFNcOw35tZsvJAvmIIxuyY2mZFwC02eLIsz/4+qRSKIt8szN4NHlv yVIuv8VbipxsinHxKzV3dUHHbt2sKiIVBppfva42ic8MOMTRhh5S4K23LcC2Tq91gjToP56VBB OGtL7Z4z/Pio6cosWLRaL00adJ1omghKd6wS9TsbdI6byhjJuKbqlIBDLVnBZiZqBvt8/K71G+ bPc= WDCIronportException: Internal Received: from unknown (HELO redsun52) ([10.149.66.28]) by uls-op-cesaip01.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Jan 2020 18:34:01 -0800 Date: Thu, 23 Jan 2020 05:39:00 -0000 From: "Maciej W. Rozycki" To: Simon Marchi cc: Pedro Alves , gdb-patches@sourceware.org, Jim Wilson Subject: Re: [PATCH v2 2/4] Unregister the last inferior from the event loop In-Reply-To: Message-ID: References: <2f8d9a63-db38-e5c0-d221-dd9b1e151e1b@simark.ca> <323e416c-f0a9-ec14-c279-508c0245a479@simark.ca> User-Agent: Alpine 2.21 (LFD 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SW-Source: 2020-01/txt/msg00729.txt.bz2 On Thu, 23 Jan 2020, Maciej W. Rozycki wrote: > This change (2/4) can therefore be dropped as no longer required. Again, > thank you, Simon, for your assistance! On second thoughts and having experimented a bit I take my conclusion back. I think we do want to include my proposed change so as not to have the value of 1 linger in `infrun_is_async' after an abrupt termination of the target connection. This is because it is not the case if a remote stub behaves in an orderly manner, where `infrun_is_async' is reset to 0 every time execution stops in the debuggee (in the scenario concerned, that is). Therefore I think we want the state of GDB to be consistently the same regardless of whether the remote connection has been ended with `detach', `disconnect', `kill' or abruptly, even though we currently do not know (anymore) of any observable difference in behaviour resulting from this discrepancy. OK to go ahead with this change then? NB the current session log looks like: (gdb) continue Continuing. infrun: clear_proceed_status_thread (Thread 2061.2061) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) Sending packet: $Z0,1555560ad8,2#7c...Packet received: Packet Z0 (software-breakpoint) is NOT supported Sending packet: $m1555560ad8,2#33...Packet received: 8280 Sending packet: $X1555560ad8,0:#56...Packet received: OK binary downloading supported by target Sending packet: $X1555560ad8,2:\002\220#ea...Packet received: OK infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 2061.2061] at 0x1555556ef0 Sending packet: $QPassSignals:e;10;14;17;1a;1b;1c;21;24;25;2c;4c;97;#0a...Packet received: OK Sending packet: $vCont?#49...Packet received: vCont;c;C;t Packet vCont (verbose-resume) is supported Sending packet: $vCont;c:p80d.-1#aa...infrun: infrun_async(1) infrun: prepare_to_wait ^Cremote_pass_ctrlc called remote_interrupt called ^Cremote_pass_ctrlc called infrun: infrun_async(0) The target is not responding to interrupt requests. Stop debugging it? (y or n) y infrun: infrun_async(1) Disconnected from target. (gdb) Maciej