From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9214 invoked by alias); 13 Jun 2016 18:35:42 -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 9188 invoked by uid 89); 13 Jun 2016 18:35:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 13 Jun 2016 18:35:40 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5517F154E3; Mon, 13 Jun 2016 18:35:39 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5DIZbBu012886; Mon, 13 Jun 2016 14:35:38 -0400 Subject: Re: why I dislike qXfer To: David Taylor , gdb@sourceware.org References: <31527.1465841753@usendtaylorx2l> From: Pedro Alves Message-ID: <7ee87c44-2fe7-741b-d134-49e9a56a966c@redhat.com> Date: Mon, 13 Jun 2016 18:35:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <31527.1465841753@usendtaylorx2l> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-06/txt/msg00021.txt.bz2 On 06/13/2016 07:15 PM, David Taylor wrote: > With the qT{f,s}{STM,P,V} q{f,s}ThreadInfo (and possibly others) > interfaces, nothing needs to be precomputed, and I either start at the > beginning (f -- first) or where the previous request left off (s -- > subsequent). > I have to store, per connection, my location. But, there is no random > reading. The next request of that flavor will either start at the > beginning (f) or where the last one left off (s). Reads are sequential. If you support non-stop mode, the target is running and list of threads changes as gdb is iterating. The "location" thread can exit and you're left not knowing where to continue from, for example. To get around that, generate a stable snapshot when you get the f requests, and serve gdb requests from that snapshot. > With the offset,length interface I don't know that reads will be > sequential so I need to pad and leave gaps. > > What do people do? Generate a snapshot when gdb requests offset 0. Then serve requests from that snapshot. See handle_qxfer_threads in gdbserver's sources. Thanks, Pedro Alves