From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31663 invoked by alias); 8 Sep 2009 05:20:42 -0000 Received: (qmail 31611 invoked by uid 22791); 8 Sep 2009 05:20:41 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_37,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 08 Sep 2009 05:20:34 +0000 Received: (qmail 4259 invoked from network); 8 Sep 2009 05:20:30 -0000 Received: from unknown (HELO wind.localnet) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 8 Sep 2009 05:20:30 -0000 From: Vladimir Prus To: Matt Rice Subject: Re: Simplify MI breakpoint setting Date: Tue, 08 Sep 2009 05:20:00 -0000 User-Agent: KMail/1.11.90 (Linux/2.6.24-24-generic; KDE/4.2.90; i686; svn-979530; 2009-06-10) Cc: Tom Tromey , gdb-patches@sources.redhat.com References: <200908011113.32939.vladimir@codesourcery.com> <200909010916.41171.vladimir@codesourcery.com> <8ba6bed40909071600g1d423d05oa18b4adcfc97153a@mail.gmail.com> In-Reply-To: <8ba6bed40909071600g1d423d05oa18b4adcfc97153a@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200909080920.27288.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: 2009-09/txt/msg00184.txt.bz2 On Tuesday 08 September 2009 Matt Rice wrote: > On Mon, Aug 31, 2009 at 10:16 PM, Vladimir > Prus wrote: > > On Tuesday 01 September 2009 Tom Tromey wrote: > > > >> >>>>> "Volodya" == Vladimir Prus writes: > >> > >> Volodya> And, progressing recursively, what is the point of not exposing > >> Volodya> all the parameters of break_command_really? > >> > >> I don't actually know. But if I had to guess, I would say it is because > >> providing wrappers ensures you can't pass in some forms of nonsense. > >> > >> If you really want to do it, and nobody objects, then I guess I don't > >> care all that much. This whole API seems a bit nuts, any time you have > >> 13 arguments you should just assume you've done something wrong already. > >> > >> I do care about not exporting a function named "break_command_really" > >> though. > > > > Ok. I imagine that break_command_really can be renamed to set_breakpoint :-) > > > > here are my thoughts, > > I don't like how break_command_really looks for the symbol first, then > if it fails to find one and > pending breakpoints are enabled it will set a pending breakpoint, I > think it might sometimes make sense > to set a pending breakpoint even though there may be a match. I am missing something. Pending breakpoint, by definition, is a breakpoint that has zero locations. And breakpoint can have zero locations if and only if we have failed to find any location that corresponds to the string that user has specified. Therefore, pending breakpoint for a found symbol or line seems just impossible. > > though I do think that the break_command_really behaviour is good for > the 'break command' > if we were to introduce a 'pbreak', or pending breakpoint command, I > could imagine pbreak_command_really or something calling something > named set_breakpoint, but that is not just renaming > break_command_really. > > similarly, there is currently no way to do 'set multiple-symbols > pending' or all+pending, > and making 'set multiple-symbols ask' respond like this: > > [0] cancel > [1] all > [2] pending > > (note that you could select (1 2) get all, and a pending > or 2 and just set a pending breakpoint. > (now you'll have to ignore all the rest of the stuff you can think of > required to make this behaviour anything but annoying) It is true that interaction of the 'set multiple breakpoints for each overloaded function' functionality with the multiple-location functionality is not much designed. - Volodya