From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21394 invoked by alias); 3 May 2008 14:25:06 -0000 Received: (qmail 21376 invoked by uid 22791); 3 May 2008 14:25:05 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 03 May 2008 14:24:40 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 5C586983D9; Sat, 3 May 2008 14:24:38 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 2E9AE98150; Sat, 3 May 2008 14:24:38 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1JsIfF-0004bj-Gl; Sat, 03 May 2008 10:24:37 -0400 Date: Sat, 03 May 2008 14:25:00 -0000 From: Daniel Jacobowitz To: Bjarke Viksoe Cc: gdb@sourceware.org Subject: Re: FW: [MI] -break-delete with several breakpoints Message-ID: <20080503142437.GA17120@caradoc.them.org> Mail-Followup-To: Bjarke Viksoe , gdb@sourceware.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-12-11) X-IsSubscribed: yes 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 X-SW-Source: 2008-05/txt/msg00037.txt.bz2 On Sat, May 03, 2008 at 08:56:07AM +0200, Bjarke Viksoe wrote: > > > > >> Vladimir wrote: > > For reference, which IDE are you using this behaviour in? > > - Volodya > > BVRDE; a personal project of mine, yet hosted on sourceforge. > http://sourceforge.net/projects/bvrde/ Thanks for the link; I decided to start a list of front ends on the wiki. So you're running the front end on Windows and the GDB on the remote Unix system, rather than GDB on Windows and gdbserver on the remote system? > I don't have the luxury of installing the latest GDB with my tool, and > because of network latency, small and concise MI messages are > important. That doesn't sound quite right... small and concise messages are important for throughput. If you are prepared to pipeline multiple requests latency can be less of an issue. -- Daniel Jacobowitz CodeSourcery