From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25907 invoked by alias); 4 Oct 2013 18:55:39 -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 25897 invoked by uid 89); 4 Oct 2013 18:55:38 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: elasmtp-masked.atl.sa.earthlink.net Received: from elasmtp-masked.atl.sa.earthlink.net (HELO elasmtp-masked.atl.sa.earthlink.net) (209.86.89.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 04 Oct 2013 18:55:36 +0000 Received: from [68.96.200.16] (helo=macbook2.local) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1VSAXG-0004Zk-K3 for gdb-patches@sourceware.org; Fri, 04 Oct 2013 14:55:34 -0400 Message-ID: <524F0F1E.7050409@earthlink.net> Date: Fri, 04 Oct 2013 18:55:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: Re: RFA [PATCH v4] Implement 'catch syscall' for gdbserver (was Re: RFA [PATCH v3] Implement 'catch syscall' for gdbserver) References: <1379796907.5980.20.camel@soleil> <1380467062.3567.52.camel@soleil> <524E428B.4010508@codesourcery.com> <524EFD7F.3060903@redhat.com> In-Reply-To: <524EFD7F.3060903@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ELNK-Trace: ae6f8838ff913eba0cc1426638a40ef67e972de0d01da94079eaf4a02670b7f079454bedae20ffc7350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-IsSubscribed: yes X-SW-Source: 2013-10/txt/msg00153.txt.bz2 On 10/4/13 10:40 AM, Pedro Alves wrote: > [...] Unless perhaps we make GDB > send a unique id along as well... I think the RSP used to always send > a sequence number with each packet, and that has been removed a long > time ago. I wish I know why it was removed. It would solve these > issues. Maybe we should add it back. I researched this a bit, since I had the same vague memory, but the situation is odd. In 1994, Jim Kingdon documented a $cc: at the top of remote.c, as an option that stubs accept, and to this day the example stubs have their bit of code, but I don't see any evidence that anything was done in GDB before or since. (The rationale may simply have been that the stubs needed to be extended first, this being before the days of qSupported.) Sequence numbers don't seem like a great idea, though, potentially introducing brittleness of various sorts. Although we didn't really think about it explicitly at the outset, the remote protocol has generally evolved in the direction of being stateless; for instance, we don't send a half-dozen vCont packets that must all be applied together, we send one packet that includes everything. Philosophically, this makes sense because real targets are quite unpredictable - two reads in a row can return different results, a single-step can result in a dozen new threads, etc. Another well-known stateless protocol is HTTP, needed due to its own unpredictabilities (as we all experience every day :-) ). Now there are situations where statefulness is useful, which they solve by using cookies. In the remote protocol, our analogous situation is where the target needs to be more like an agent, such as with tracing, and in those cases we do have identifiers that are coordinated between host and target, though in a somewhat adhoc way right now. I think we could develop the id concept into more of a generic mechanism that is available for target-side commands, actionpoints in general, and so forth, perhaps with everything using a single numeric (or textual?) space, so that "231" can be unambiguously a catchpoint, rather than either a catchpoint or a trace state variable, depending on context. Stan stan@codesourcery.com