From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29565 invoked by alias); 23 Sep 2010 22:12:35 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 29483 invoked by uid 22791); 23 Sep 2010 22:12:35 -0000 X-SWARE-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Tom Tromey X-Fcc: ~/Mail/utrace Cc: Oleg Nesterov , utrace-devel@redhat.com, archer@sourceware.org Subject: Re: gdbstub initial code, v11 In-Reply-To: Tom Tromey's message of Wednesday, 22 September 2010 13:09:12 -0600 References: <20100922022226.GA27400@redhat.com> Message-Id: <20100923212423.B4EF540048@magilla.sf.frob.com> Date: Thu, 23 Sep 2010 22:12:00 -0000 X-SW-Source: 2010-q3/txt/msg00219.txt.bz2 > I think it would be good to implement a feature that shows how this > approach is an improvement over the current state of gdb+ptrace or > gdb+gdbserver. > > Exactly what feature this should be... I don't know :-) > I would imagine something performance-related. My vague notion was that we'd get it working well enough to have basic parity with native or gdbserver on some realish test cases, and then just look at the protocol interaction log to see cases where we could reduce round-trips between gdb and the stub. Some of those are bound to entail protocol extensions and gdb changes to exploit them. Off hand, the Z cases might be the only things that won't need that. Thanks, Roland