From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22661 invoked by alias); 18 Apr 2007 13:06:26 -0000 Received: (qmail 22650 invoked by uid 22791); 18 Apr 2007 13:06:25 -0000 X-Spam-Check-By: sourceware.org Received: from ug-out-1314.google.com (HELO ug-out-1314.google.com) (66.249.92.175) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 18 Apr 2007 14:06:21 +0100 Received: by ug-out-1314.google.com with SMTP id m3so860333uge for ; Wed, 18 Apr 2007 06:06:18 -0700 (PDT) Received: by 10.66.242.20 with SMTP id p20mr1259072ugh.1176901577750; Wed, 18 Apr 2007 06:06:17 -0700 (PDT) Received: from coin ( [82.237.12.13]) by mx.google.com with ESMTP id m1sm1795029ugc.2007.04.18.06.06.16; Wed, 18 Apr 2007 06:06:17 -0700 (PDT) Date: Wed, 18 Apr 2007 13:06:00 -0000 From: Dodji Seketeli To: Daniel Jacobowitz Cc: Nick Roberts , GDB Discuss Subject: Re: question about -file-exec-and-symbols gdbmi command Message-ID: <20070418150615.71a53225@coin> In-Reply-To: <20070418121137.GA19685@caradoc.them.org> References: <20070418111206.45c55d72@coin> <17957.60377.419260.20236@farnswood.snap.net.nz> <20070418121124.36ccd4fa@coin> <17957.62645.824183.252961@farnswood.snap.net.nz> <20070418105813.GA6857@caradoc.them.org> <17958.2099.694416.221119@farnswood.snap.net.nz> <20070418121137.GA19685@caradoc.them.org> X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; i486-pc-linux-gnu) X-Operating-System: Debian GNU/Linux Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: 2007-04/txt/msg00118.txt.bz2 On Wed, 18 Apr 2007 08:11:37 -0400 Daniel Jacobowitz wrote: > Nope. The difference is that the front end has some knowledge of > "this is a new program" versus "this is the same program being > reloaded", because it issued the command in response to some user > stimulus. GDB has no way to know why the command was issued; in one > case deleting breakpoints is appropriate, in the other it is not. > > So if the front end wants breakpoints deleted, I think it's reasonable > for it to do so explicitly. Indeed. I noticed this whilst writing a front end, actually. I got hard time fuguring why I was seeing breakpoints from another binary being returned by -break-list :-) I understand your point and felt back on what you suggest. Thank you for that. So, there is no IRC channel where you guys can be reached ? :-) Cheers, -- Dodji Seketeli http://www.seketeli.org/dodji