From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15146 invoked by alias); 16 Mar 2006 16:40:51 -0000 Received: (qmail 15138 invoked by uid 22791); 16 Mar 2006 16:40:51 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 16 Mar 2006 16:40:50 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1FJvWN-0003JC-Lw for gdb@sources.redhat.com; Thu, 16 Mar 2006 17:40:19 +0100 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Mar 2006 17:40:19 +0100 Received: from ghost by zigzag.lvk.cs.msu.su with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 16 Mar 2006 17:40:19 +0100 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: MI: changing breakpoint location Date: Thu, 16 Mar 2006 16:46:00 -0000 Message-ID: References: <20060316160521.GA13476@nevyn.them.org> <200603161911.55098.ghost@cs.msu.su> <20060316161556.GA14155@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.8.2 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-03/txt/msg00098.txt.bz2 Daniel Jacobowitz wrote: > On Thu, Mar 16, 2006 at 07:11:54PM +0300, Vladimir Prus wrote: >> > How much trouble is it, really, to remove and recreate the breakpoint? >> >> In code, something line 28 lines, 7 lines of actual code exclusing >> comments. In development time -- something like an hour, including two >> failed attempts. And this assumes the current version is bug free and >> nobody will break it in future. >> >> How much trouble is it to change breakpoint location in gdb? > > A whole lot more than that. We'd have to destroy most of the existing > breakpoint. I trust you on that, though I don't understand why GUI is in better position to emit "-break-delete" + "-break-insert" then gdb itself, internally. >> > Almost all of the work of the "break" command is figuring out where the >> > breakpoint should go. I don't see an advantage in having more commands >> > that need to be able to work that out. >> >> Can't that logic be factored out into a function? > > Of course, it already is. But that's not the point; I don't want a > proliferation of commands with similar functionality, when they aren't > needed. The larger the MI interface grows, the harder it is to test > and maintain. I think there's a tradeoff here -- in this specific case, all frontend authors will have to implement the same functionality, likely with bugs. If this is done right once in gdb, all frontends will work correctly. Of course, frontend maintainers and gdb maintainers are different groups, so if you mean adding this to gdb will move work from frontend maintainers to gdb maintainers and you don't like that idea, I understand. Or you object to the idea even if it will backed up by a patch eventually? - Volodya