From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6238 invoked by alias); 7 Jun 2010 16:35:53 -0000 Received: (qmail 6086 invoked by uid 22791); 7 Jun 2010 16:35:52 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 07 Jun 2010 16:35:46 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 9D4802BAC22; Mon, 7 Jun 2010 12:35:44 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MBuA6HjF6q3W; Mon, 7 Jun 2010 12:35:44 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 408162BAC21; Mon, 7 Jun 2010 12:35:44 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 9BEA7F58FA; Mon, 7 Jun 2010 09:35:30 -0700 (PDT) Date: Mon, 07 Jun 2010 16:35:00 -0000 From: Joel Brobecker To: Michael Snyder Cc: Pedro Alves , "gdb-patches@sourceware.org" Subject: Re: [gdbserver] x86 agent expression bytecode compiler (speed up conditional tracepoints) Message-ID: <20100607163529.GM3019@adacore.com> References: <201006071700.28706.pedro@codesourcery.com> <4C0D1868.9080308@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C0D1868.9080308@vmware.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2010-06/txt/msg00176.txt.bz2 > gdbserver has sure come a long way from the simple remote debug agent > that it started out to be. Is anybody at all worried about the ever > increasing complexification of gdbserver? I personally am not. I am a little preoccupied with the fact that we seem to be duplicating more and more code between the gdbserver and GDB, and one of these days we'll probably want to bite the bullet and make the GDB code use the gdbserver target-side of the code (read/write memory, step/run/continue, etc). But in the meantime, Pedro and others seem to be well on top of things :). -- Joel