From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19962 invoked by alias); 9 Feb 2012 19:02:48 -0000 Received: (qmail 19934 invoked by uid 22791); 9 Feb 2012 19:02:46 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 09 Feb 2012 19:02:30 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q19J2Quh008743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Feb 2012 14:02:26 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q19J2PYp031998; Thu, 9 Feb 2012 14:02:25 -0500 Message-ID: <4F341840.8070709@redhat.com> Date: Thu, 09 Feb 2012 19:02:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120131 Thunderbird/10.0 MIME-Version: 1.0 To: Yao Qi CC: gdb-patches@sourceware.org Subject: Re: [patch 0/8] GDB/GDBserver talks with agents References: <4F1D55D7.7030506@codesourcery.com> In-Reply-To: <4F1D55D7.7030506@codesourcery.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2012-02/txt/msg00154.txt.bz2 On 01/23/2012 12:43 PM, Yao Qi wrote: > When I am working on the new agent library [1], I found that only > gdbserver is able to interact with agent on static tracepoints only. > There are two limitations here, 1) only gdbserver is able to talk with > agent, 2) only static tracepoint operations can be performed by agent. This was a result of some consideration. I thought of two main options when I was first designing the IPA: - have gdbserver peek/poke at the IPA memory directly. Requires some way for gdbserver to know where to poke etc., but, this was it's possible for the inferior to be completely (or virtually completely) unaffected by the IPA. - spawn a thread in the IPA, and use it as a communication gate with gdbserver. The upside of this solution you can come up with some protocol for the communication, which is simpler than caring about ABIs and layouts of objects. The downsides are that spawning a thread in the inferior makes non-threaded programs suddenly become threaded; and, you need to come up with a way to run the IPA communication thread a while behind gdb/gdbserver's back, so it can process the commands. The IPA only gained static tracepoints support later. I had to pick one approach and move on, so I picked the first. Later on, the only way to communicate with ust was by calling some of its functions, which implies the second approach... -- Pedro Alves