From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 119811 invoked by alias); 23 Aug 2017 15:01:53 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 119701 invoked by uid 89); 23 Aug 2017 15:01:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=quality X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 23 Aug 2017 15:01:47 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1B1141F58B; Wed, 23 Aug 2017 15:01:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 1B1141F58B Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=palves@redhat.com Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 429156031C; Wed, 23 Aug 2017 15:01:43 +0000 (UTC) Subject: Re: Host GDB disconnect while waiting for tracee status change To: Dmitry Antipov , Yao Qi References: <5febbe3e-926f-78bb-db88-901b44e2e258@nvidia.com> <867exusnn8.fsf@gmail.com> <98251d5d-646b-296c-acf6-43ec4accd4e0@nvidia.com> Cc: gdb@sourceware.org, Ryan Bissell , Mikhail Filimonov From: Pedro Alves Message-ID: Date: Wed, 23 Aug 2017 15:01:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-08/txt/msg00064.txt.bz2 On 08/23/2017 02:55 PM, Dmitry Antipov wrote: > On 08/23/2017 04:10 PM, Pedro Alves wrote: > >> Right, because in non-stop mode, linux-low.c doesn't >> usually block inside mywait....sigsuspend. See server.c:resume. >> In non-stop mode, gdbserver waits for both socket events and >> target events at the same time in the event loop. The >> non-stop variant of the RSP is asynchronous. > > Thanks. So, is it mandatory to use non-stop mode if I want to be able to > restart gdb without loosing the debugging session controlled by gdbserver? In all-stop/sync mode, you can only exit gdb if the target is stopped, in which case you can't get into the problem case. If you're considering "restarting gdb" manually, then no. This is about the server robustly handling the case of the connection unexpectedly closing, like GDB crashing. And gdbserver could be fixed, somehow. This is a quality of implementation issue, not a fundamental insurmountable design problem. Thanks, Pedro Alves