From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1785 invoked by alias); 7 Jan 2003 04:31:51 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 1778 invoked from network); 7 Jan 2003 04:31:50 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 209.249.29.67 with SMTP; 7 Jan 2003 04:31:50 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18VnHb-00058J-00 for ; Tue, 07 Jan 2003 00:32:15 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18VlP9-0001Wf-00 for ; Mon, 06 Jan 2003 23:31:55 -0500 Date: Tue, 07 Jan 2003 04:31:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: [RFA/PATCH] breakpoint.c: fix until command Message-ID: <20030107043155.GA5806@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com References: <3E14F768.DA13CB07@redhat.com> <15893.40776.758960.171190@localhost.redhat.com> <3E1621FF.A822AD5C@redhat.com> <15894.9086.849437.238762@localhost.redhat.com> <3E162537.63F529DF@redhat.com> <20030104015356.GA23728@nevyn.them.org> <15897.65265.595543.449396@localhost.redhat.com> <3E1A2CE3.9325A6F@redhat.com> <15898.12832.906305.726378@localhost.redhat.com> <3E1A36AD.78DAFA63@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E1A36AD.78DAFA63@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-01/txt/msg00267.txt.bz2 On Mon, Jan 06, 2003 at 06:08:45PM -0800, Michael Snyder wrote: > Elena Zannoni wrote: > > > > Michael Snyder writes: > > > Elena Zannoni wrote: > > > > > > > > Daniel Jacobowitz writes: > > > > > On Fri, Jan 03, 2003 at 04:05:11PM -0800, Michael Snyder wrote: > > > > > > Well then... > > > > > > 1) Use find_pc_partial_function to determine bounds and > > > > > > distinguish between in-bounds and out-of-bounds locations. > > > > > > 2) For func_start > loc >= func_end, use a frame-relative bp. > > > > > > 3) For func_start == loc or loc < func_start or loc > func_end, > > > > > > use a frameless bp. > > > > > > 4) document, document, document! > > > > > > Including the recursive corner case. > > > > > > > > > > > > Agreed, Elena? > > > > > > > > > > So you're saying: > > > > > - if the PC is in this function, only stop when this frame reaches it. > > > > > > > > yes > > > > > > > > > - if the PC is the _beginning_ of a function (what about prologue > > > > > skipping, does that come into this? I don't remember if > > > > > decode_line_1 will skip the prologue, but I think it will.) or in > > > > > some other function, stop in any frame. > > > > > > > > yes, but every time I think about this, I can find an example for > > > > which we get in trouble. Another case that comes to mind is until > > > > 0x12345 where the address is in the prologue of the same function. > > > > What to do in this case. > > > > > > We've got to draw a line in the sand. ;-) > > > Making "until factorial" an exception is a big enough concession. > > > I don't think the user can expect to do "until some-address-in-the-prologue" > > > and expect it to have a special meaning. > > > > > > My suggestion remains: > > > if func_start > location >= func_end then frame_relative. > > > > > > > > > > > > Daniel? Michael? > > > > > > > > > > I'd be happier if those two behaviors had different names, but the > > > > > logical name I'd give to both of them is "until", so I guess we'll just > > > > > have to live with this. (3) is meaningful when inside the function > > > > > too, and with this scheme there's no way to express that without using > > > > > breakpoints; but I think that's a small loss. > > > > > > > > > > > > > Actually I start to believe that we need 2 separate commands. One > > > > would do the current behavior the other would be w/o frame check. We > > > > already have 'jump' (and it means something different). Maybe 'goto'? > > > > I can't think of a decent name. 'reach', 'get to'? > > > > > > run-to? > > > I like the idea of restricting "until" to the current function, > > > and using a separate command for locations outside the current function. > > > (or inside, if you want the effect of a temporary breakpoint). > > > This would remove the ambiguity. > > > > I think that if we can find a decent name, there is more agreement > > towards separating the behaviors. Except that 'run' in gdb means start > > from the beginning, so runto can be ambiguous (it is also used in the > > testsuite a lot with the meaning of start over). > > Ah, that's right. I was thinking of that usage, but I forgot > that it starts from the beginning. > > Doesn't the testsuite also have a similar command that means > "set a breakpoint here and continue till you get there"? Yes, it's gdb_continue_to_breakpoint, but it's not quite the same. I asked my official layperson for ideas on what to call this, and got back: "until first foo.c:40" "until current foo.c:40" With a little massaging, how about one of: "until first " "until-first " "until -first " ? Me, I'm partial to the third form; then you can have: until -first func until -current func And make one of those the default. But this is risks starting the argument about syntax of options to CLI commands all over again. It seems to me that these are both logical things to do for "until", so why not call them both "until", if we can agree on a syntax? Just a thought. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer