From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6229 invoked by alias); 16 Nov 2007 10:34:50 -0000 Received: (qmail 6218 invoked by uid 22791); 16 Nov 2007 10:34:50 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 16 Nov 2007 10:34:48 +0000 Received: (qmail 15371 invoked from network); 16 Nov 2007 10:34:46 -0000 Received: from unknown (HELO 172.16.unknown.plus.ru) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 16 Nov 2007 10:34:46 -0000 From: Vladimir Prus To: Eli Zaretskii Subject: Re: delete_breakpoint: don't try to insert other breakpoints Date: Fri, 16 Nov 2007 10:34:00 -0000 User-Agent: KMail/1.9.6 Cc: gdb-patches@sources.redhat.com References: <200711142324.11319.vladimir@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711161334.40641.vladimir@codesourcery.com> 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: 2007-11/txt/msg00332.txt.bz2 On Friday 16 November 2007 13:13:24 Eli Zaretskii wrote: > > From: Vladimir Prus > > Date: Thu, 15 Nov 2007 08:59:19 +0300 > > > > > I think you are assuming that this code does and will always run > > > synchronously. Is that a valid assumption? > > > > At the moment, I'm not aware of any way to invoke delete_breakpoint > > while existing breakpoints are inserted. Is there one? > > (In particular, "target async" does not seem to work at all). > > > > In future, this situation might be possible. However, in general > > I think it's better to start by making code clear while still > > working for current GDB, and then adjust it as needed for future GDB. > > In this particular case, a call to insert_breakpoints, together > > with some adjustments, would be much better for any future async code, > > as it won't duplicate code logic. > > I'm okay with making the code cleaner, but on at a price of removing > features, even if they are currently unused. Let me clarify -- I'm not aware of *any* way that this code can affect anything in the current GDB, it's not excercised by any tests, and therefore is essentially a dead code. Therefore, I don't think it's fair to say this code is a "feature". Removing it will simplify current code, and the removed part will still be in CVS, so should we ever need to consult it, it's quite possible. Why keep unused code in HEAD? - Volodya