From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29759 invoked by alias); 13 May 2014 16:07:18 -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 29747 invoked by uid 89); 13 May 2014 16:07:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mexforward.lss.emc.com Received: from mailuogwhop.emc.com (HELO mexforward.lss.emc.com) (168.159.213.141) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 13 May 2014 16:07:15 +0000 Received: from hop04-l1d11-si01.isus.emc.com (hop04-l1d11-si01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id s4DG793K002632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 May 2014 12:07:12 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Tue, 13 May 2014 12:06:58 -0400 Received: from usendtaylorx2l.lss.emc.com (usendtaylorx2l.lss.emc.com [10.243.10.188]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id s4DG6wcV007488 for ; Tue, 13 May 2014 12:06:58 -0400 Received: by usendtaylorx2l.lss.emc.com (Postfix, from userid 26043) id 857815CA86D; Tue, 13 May 2014 12:06:56 -0400 (EDT) Received: from usendtaylorx2l (localhost [127.0.0.1]) by usendtaylorx2l.lss.emc.com (Postfix) with ESMTP id F0CCC5CA350 for ; Tue, 13 May 2014 12:06:56 -0400 (EDT) From: David Taylor To: "gdb@sourceware.org" Subject: qXfer:threads questions Date: Tue, 13 May 2014 16:07:00 -0000 Message-ID: <10717.1399997216@usendtaylorx2l> X-EMM-MHVC: 1 X-RSA-Classifications: DLM_1, public X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00021.txt.bz2 Some of these questions aren't specific to qXfer:threads:read, but are inspired by it. And for some of these, they can probably be answered by either a detailed study of the GDB source code or by running experiments. But, that merely tells you what GDB currently does. Not what the intent is. I'd like to know the intent -- that is less likely to change from release to release than the source code. The qXfer:threads:read message is underspecified in the documentation. And to the extent that it is specified, it surprises me. We have a box with a fair number of threads / processes running in it. It's a shared address space. All threads / processes run in the same address space. The threads / processes running varies over time. If you ask me right now what processes / threads are running on the box and ask again in a minute, the answer will likely be different. The bulk will be the same -- most get started when the box is brought up and remain around until it is brought down. But, some threads / processes come and go so there *WILL* be differences. Reading the spec for qXfer:threads:read I get the impression that it is meant to solve the problem of a system with a large but static list of threads. I suspect that typically when the list is static, it is small and when it is large, it is dynamic. It takes both an offset and a length. So, if I'm a gdb stub and I recieve the qXfer request, if I don't currently have an XML string to satisfy the request, I create one. And then I send a reply. Now, about that reply: . if at offset + length I am in the middle of an XML token, what should I do? . suppose that I back up to a boundary between ... and end the reply there, is that allowed? is it okay for the receiver (typically GDB) to consider that to be an EOF? is it an error? if it is not an error and is not an EOF (after all, I didn't send the 'trailer' yet), what offset will the next request use? old offset + old length? old offset + returned lenth? something else? . what if 'offset' is in the middle of an XML token? To like to not have to pad the message out to 'offset' bytes with spaces just to avoid errors / confusion. Also, there's nothing in the documentation that requires that the reads be in order nor that the next read start at any given boundary. Given that the list is dynamic and consequently changes this is a problem. . how do I know when to 'throw away' the old data and compute new data? For data that is dynamic and computed on the fly, I much prefer the qfThreadInfo / qsThreadInfo model. The 'f' (first) starts at the beginning and gives information on one or more 'items' (threads in this case) up to a maximum of PacketSize; the 's' (subsequent) ones start where the previous 'f' or 's' packet left off and return information on one or more 'items' up to PacketSize. And there is an EOF marker -- so the caller knows when to stop (though with XML the 'tailer' is all you really need to know whether to stop). With the 'f' / 's' model, I don't need to keep the XML structure around. I only need to remember where in the process / thread table I was at the end of the last message. Next 's' message I start from there; next 'f' message I start over at the beginning. Simple and straightforward. *IF* we were adding a new message, I'd probably suggest either: qXfer:threads:read:first::length qXfer:threads:read:next::length That is give the 'annex' the value 'first' or 'next', require that 'offset' be omitted and that 'length' be greater than zero. Or, qXfer:threads:read::first,length qXfer:threads:read::next,length That is, keep the annext empty, give two 'offsets' with special meanings, and again require that 'length' be greater than zero. Or, qXfer:threads:readf:::length qXfer:threads:reads:::length Or ... ? Just throwing out possibilities. Given the current existence of qXfer:threads:read I'd prefer a solution that allows the stub to say 'I support the new qXfer threads message' without any confusion about support for the old message -- so I would tend to disfavor the first two for that reason. And I'd prefer to not list two messages in qSupported to get one feature, so I would tend to disfavor the third for that reason. So, I'd really prefer some 4th solution.