* breakpoint commands and finish @ 2003-04-14 20:56 Matt Thomas 2003-04-14 21:00 ` Joel Brobecker 2003-04-17 17:47 ` Michael Snyder 0 siblings, 2 replies; 19+ messages in thread From: Matt Thomas @ 2003-04-14 20:56 UTC (permalink / raw) To: gdb What should be the behavour of the following? break function commands finish continue end Should finish cause gdb to stop and wait for a prompt or should gdb act on the continue? (gdb5.x does the former while gdb4.x did the latter) -- Matt Thomas Internet: matt@3am-software.com 3am Software Foundry WWW URL: http://www.3am-software.com/bio/matt/ Cupertino, CA Disclaimer: I avow all knowledge of this message ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: breakpoint commands and finish 2003-04-14 20:56 breakpoint commands and finish Matt Thomas @ 2003-04-14 21:00 ` Joel Brobecker 2003-04-14 21:04 ` Joel Brobecker 2003-04-17 17:47 ` Michael Snyder 1 sibling, 1 reply; 19+ messages in thread From: Joel Brobecker @ 2003-04-14 21:00 UTC (permalink / raw) To: Matt Thomas; +Cc: gdb > What should be the behavour of the following? Somebody asked the very same question maybe just a couple of days ago, on this very same mailing list. -- Joel ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: breakpoint commands and finish 2003-04-14 21:00 ` Joel Brobecker @ 2003-04-14 21:04 ` Joel Brobecker 2003-04-14 21:11 ` Doug Evans 2003-04-14 21:23 ` Matt Thomas 0 siblings, 2 replies; 19+ messages in thread From: Joel Brobecker @ 2003-04-14 21:04 UTC (permalink / raw) To: Matt Thomas; +Cc: gdb [Grrr, sorry, this is what happens when you are in a hurry, and try taking a few shortcuts to save some time :-(. Here is the complete answer I wanted to send:] > What should be the behavour of the following? Somebody asked the very same question maybe just a couple of days ago, on this very same mailing list. To get the answer to your question, you should search the mailing list archives, or read the GDB documentation. -- Joel ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: breakpoint commands and finish 2003-04-14 21:04 ` Joel Brobecker @ 2003-04-14 21:11 ` Doug Evans 2003-04-14 21:33 ` Joel Brobecker 2003-04-14 21:23 ` Matt Thomas 1 sibling, 1 reply; 19+ messages in thread From: Doug Evans @ 2003-04-14 21:11 UTC (permalink / raw) To: Joel Brobecker; +Cc: Matt Thomas, gdb Joel Brobecker writes: > Somebody asked the very same question maybe just a couple of days ago, > on this very same mailing list. To get the answer to your question, you > should search the mailing list archives, or read the GDB documentation. fwiw, over time one hopes documentation gets larger and larger. This has the consequence of reducing the signal/noise ratio of "RTFM" more and more. It'd be nice if people got in the habit of specifying where exactly in the documentation to look. e.g. bash$ info -f gdb.info -n foobar and grep for baz. is more than sufficient. [I'm not suggesting you should know what to replace foobar and baz with. Rather, that it would have been nice if the original response did.] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: breakpoint commands and finish 2003-04-14 21:11 ` Doug Evans @ 2003-04-14 21:33 ` Joel Brobecker 2003-04-14 22:27 ` Doug Evans 0 siblings, 1 reply; 19+ messages in thread From: Joel Brobecker @ 2003-04-14 21:33 UTC (permalink / raw) To: Doug Evans; +Cc: Matt Thomas, gdb > fwiw, over time one hopes documentation gets larger and larger. > This has the consequence of reducing the signal/noise ratio of > "RTFM" more and more. Generally speaking, I can only agree with you. One of the nice things about GDB is that the maintainers take the documentation very seriously and any new feature is documented. However, in this particular case, I think that it was very easy to find the information. The person was asking what the behavior of a "commands" should be: the answer to his question is right there in the section documenting the commands lists. > It'd be nice if people got in the habit of specifying where exactly > in the documentation to look. e.g. I disagree, unless the information is buried somewhere not obvious. One very important lesson I learnt at university is how to find the information myself. In this particular cases, all you have to do is check the index, click on the name of the command you are interested in "commands" in that case, and voila! The answer is right there. I believe that actually letting people search themselves the location of the information they are looking for is helpful. (BTW: I did give the answer to the question when it was asked a few days ago) -- Joel ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: breakpoint commands and finish 2003-04-14 21:33 ` Joel Brobecker @ 2003-04-14 22:27 ` Doug Evans 0 siblings, 0 replies; 19+ messages in thread From: Doug Evans @ 2003-04-14 22:27 UTC (permalink / raw) To: Joel Brobecker; +Cc: Matt Thomas, gdb Joel Brobecker writes: > However, in this particular case, I think that it was very easy to find > the information. The person was asking what the behavior of a "commands" > should be: the answer to his question is right there in the section > documenting the commands lists. > > > It'd be nice if people got in the habit of specifying where exactly > > in the documentation to look. e.g. > > I disagree, unless the information is buried somewhere not obvious. > One very important lesson I learnt at university is how to find the > information myself. In this particular cases, all you have to do is > check the index, click on the name of the command you are interested > in "commands" in that case, and voila! The answer is right there. > I believe that actually letting people search themselves the location > of the information they are looking for is helpful. Nice in theory (and academia ...). In practice it often just annoys people. ("You had the answer right in front of you." (*1)) Sure, learning the info program (s/info/favorite/) is a useful thing to encourage. It's the forcing of when to spend the time that I question, it may be an inopportune time for the asker (otherwise s/he might have spent more time rtfm-ing ...). And the obvious place to look isn't necessarily obvious to the person asking the question (leading to more time spent). Whether such things apply in this particular case I dunno. Clearly Matt's first guess of where to look didn't work. At what point one should give up and ask for help (and the inevitable retribution for giving up too early) is always a minefield. > (BTW: I did give the answer to the question when it was asked a few days ago) Well, one can quibble over this but no matter. One can certainly argue this meta-discussion has gone on too long already. --- bash$ info -f gdb.info -n 'Break Commands' and grep for ignored. --> Any other commands in the command list, after a command that resumes execution, are ignored. This is because any time you resume execution (even with a simple `next' or `step'), you may encounter another breakpoint--which could have its own command list, leading to ambiguities about which list to execute. --- (*1): No suggestion is made that that was necessarily the case here. And no claim is made that one should always find the place in the manual first. But if you know it or know how to trivially find it, holding it back is what I'm questioning. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: breakpoint commands and finish 2003-04-14 21:04 ` Joel Brobecker 2003-04-14 21:11 ` Doug Evans @ 2003-04-14 21:23 ` Matt Thomas 1 sibling, 0 replies; 19+ messages in thread From: Matt Thomas @ 2003-04-14 21:23 UTC (permalink / raw) To: Joel Brobecker; +Cc: gdb At 02:04 PM 4/14/2003, Joel Brobecker wrote: >[Grrr, sorry, this is what happens when you are in a hurry, and try >taking a few shortcuts to save some time :-(. Here is the complete >answer I wanted to send:] > > > What should be the behavour of the following? > >Somebody asked the very same question maybe just a couple of days ago, >on this very same mailing list. To get the answer to your question, you >should search the mailing list archives, or read the GDB documentation. I did read the GDB documentation and the documentation for finish does not describe the behavior. From http://sources.redhat.com/gdb/current/onlinedocs/gdb_6.html#SEC29 finish Continue running until just after function in the selected stack frame returns. Print the returned value (if any). It would be nice if you could point out in the documentation where the restriction is noted. I missed the previous message when scanning the archive, sorry. -- Matt Thomas Internet: matt@3am-software.com 3am Software Foundry WWW URL: http://www.3am-software.com/bio/matt/ Cupertino, CA Disclaimer: I avow all knowledge of this message ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: breakpoint commands and finish 2003-04-14 20:56 breakpoint commands and finish Matt Thomas 2003-04-14 21:00 ` Joel Brobecker @ 2003-04-17 17:47 ` Michael Snyder 2003-04-17 18:48 ` Matt Thomas 1 sibling, 1 reply; 19+ messages in thread From: Michael Snyder @ 2003-04-17 17:47 UTC (permalink / raw) To: Matt Thomas; +Cc: gdb Matt Thomas wrote: > > What should be the behavour of the following? > > break function > commands > finish > continue > end > > Should finish cause gdb to stop and wait for a prompt > or should gdb act on the continue? (gdb5.x does the > former while gdb4.x did the latter) Consistant with your observations, the traditional behavior has been that gdb would stop and prompt for a new command. I believe that recently someone has changed it so that it would at least try to execute the finish and the continue. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: breakpoint commands and finish 2003-04-17 17:47 ` Michael Snyder @ 2003-04-17 18:48 ` Matt Thomas 2003-04-17 20:19 ` Daniel Jacobowitz 0 siblings, 1 reply; 19+ messages in thread From: Matt Thomas @ 2003-04-17 18:48 UTC (permalink / raw) To: Michael Snyder; +Cc: gdb At 10:47 AM 4/17/2003, Michael Snyder wrote: >Matt Thomas wrote: > > > > What should be the behavour of the following? > > > > break function > > commands > > finish > > continue > > end > > > > Should finish cause gdb to stop and wait for a prompt > > or should gdb act on the continue? (gdb5.x does the > > former while gdb4.x did the latter) > >Consistant with your observations, the traditional behavior >has been that gdb would stop and prompt for a new command. >I believe that recently someone has changed it so that it >would at least try to execute the finish and the continue. Well, I just rebuilt gdb from the latest on sources.redhat.com and the behavior is unchanged. I was wondering (as an alternative) whether it would be possible to get a variant of the break command which would place a breakpoint at the return of a function (and print the return value like finish does). rbreak (or ebreak). I find I often was to place a breakpoint at the end of a function; it'd be nice if gdb could do that automaticly. -- Matt Thomas Internet: matt@3am-software.com 3am Software Foundry WWW URL: http://www.3am-software.com/bio/matt/ Cupertino, CA Disclaimer: I avow all knowledge of this message ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: breakpoint commands and finish 2003-04-17 18:48 ` Matt Thomas @ 2003-04-17 20:19 ` Daniel Jacobowitz 2003-04-17 20:44 ` Doug Evans 0 siblings, 1 reply; 19+ messages in thread From: Daniel Jacobowitz @ 2003-04-17 20:19 UTC (permalink / raw) To: Matt Thomas; +Cc: Michael Snyder, gdb On Thu, Apr 17, 2003 at 11:47:23AM -0700, Matt Thomas wrote: > At 10:47 AM 4/17/2003, Michael Snyder wrote: > >Matt Thomas wrote: > >> > >> What should be the behavour of the following? > >> > >> break function > >> commands > >> finish > >> continue > >> end > >> > >> Should finish cause gdb to stop and wait for a prompt > >> or should gdb act on the continue? (gdb5.x does the > >> former while gdb4.x did the latter) > > > >Consistant with your observations, the traditional behavior > >has been that gdb would stop and prompt for a new command. > >I believe that recently someone has changed it so that it > >would at least try to execute the finish and the continue. > > Well, I just rebuilt gdb from the latest on sources.redhat.com > and the behavior is unchanged. > > I was wondering (as an alternative) whether it would be possible > to get a variant of the break command which would place a breakpoint > at the return of a function (and print the return value like finish > does). > > rbreak (or ebreak). I find I often was to place a breakpoint at the > end of a function; it'd be nice if gdb could do that automaticly. It's too darned hard :) Debug info does not represent the exit point of the function. It's not always at the end; modern gcc's can emit multiple exit edges, too. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: breakpoint commands and finish 2003-04-17 20:19 ` Daniel Jacobowitz @ 2003-04-17 20:44 ` Doug Evans 2003-04-17 20:50 ` Daniel Jacobowitz 0 siblings, 1 reply; 19+ messages in thread From: Doug Evans @ 2003-04-17 20:44 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Matt Thomas, Michael Snyder, gdb Daniel Jacobowitz writes: > > rbreak (or ebreak). I find I often was to place a breakpoint at the > > end of a function; it'd be nice if gdb could do that automaticly. > > It's too darned hard :) Debug info does not represent the exit point > of the function. It's not always at the end; modern gcc's can emit > multiple exit edges, too. And if a tail-call optimization has been done, it gets even harder. OTOH, if one stops at the first instruction of a function, presumably it'd then be easy to set a breakpoint at the return address. I wonder if gdb's macro facility is sufficient to write a macro that would make this almost user-friendly: it would set a breakpoint at the start of the function (pre-prologue) then have commands that first sets a tbreak breakpoint at the return address and then continues. You couldn't already be in the function of course (but if you were presumably you'd use "finish"). ? ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: breakpoint commands and finish 2003-04-17 20:44 ` Doug Evans @ 2003-04-17 20:50 ` Daniel Jacobowitz 2003-04-17 21:19 ` Doug Evans 0 siblings, 1 reply; 19+ messages in thread From: Daniel Jacobowitz @ 2003-04-17 20:50 UTC (permalink / raw) To: Doug Evans; +Cc: Matt Thomas, Michael Snyder, gdb On Thu, Apr 17, 2003 at 01:42:58PM -0700, Doug Evans wrote: > Daniel Jacobowitz writes: > > > rbreak (or ebreak). I find I often was to place a breakpoint at the > > > end of a function; it'd be nice if gdb could do that automaticly. > > > > It's too darned hard :) Debug info does not represent the exit point > > of the function. It's not always at the end; modern gcc's can emit > > multiple exit edges, too. > > And if a tail-call optimization has been done, it gets even harder. > > OTOH, if one stops at the first instruction of a function, > presumably it'd then be easy to set a breakpoint at the return address. > I wonder if gdb's macro facility is sufficient to write a macro > that would make this almost user-friendly: it would set a > breakpoint at the start of the function (pre-prologue) then have > commands that first sets a tbreak breakpoint at the return address > and then continues. You couldn't already be in the function of > course (but if you were presumably you'd use "finish"). > > ? The macro facility isn't, but a command could be added to do this without much trouble. I would rather us discuss the semantics of commands lists containing commands which resume the inferior. There must be a more user-useful way to approach it than we do now. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: breakpoint commands and finish 2003-04-17 20:50 ` Daniel Jacobowitz @ 2003-04-17 21:19 ` Doug Evans 2003-04-17 21:44 ` Daniel Jacobowitz 2003-04-17 23:11 ` return value of a gdb command Smita 0 siblings, 2 replies; 19+ messages in thread From: Doug Evans @ 2003-04-17 21:19 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Matt Thomas, Michael Snyder, gdb Daniel Jacobowitz writes: > The macro facility isn't, but a command could be added to do this > without much trouble. For my own education, what's missing? > I would rather us discuss the semantics of > commands lists containing commands which resume the inferior. There > must be a more user-useful way to approach it than we do now. What if you allowed multiple "resume" commands in the "top level" breakpoint only, and allowed "nested" breakpoints only if they either stopped execution (in which case execution stops) or if the only "resume" they did was a tail-call-like continue. If a nested breakpoint's command list does a resumption with a non-tail-continue, execution stops. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: breakpoint commands and finish 2003-04-17 21:19 ` Doug Evans @ 2003-04-17 21:44 ` Daniel Jacobowitz 2003-04-17 23:11 ` return value of a gdb command Smita 1 sibling, 0 replies; 19+ messages in thread From: Daniel Jacobowitz @ 2003-04-17 21:44 UTC (permalink / raw) To: Doug Evans; +Cc: Matt Thomas, Michael Snyder, gdb On Thu, Apr 17, 2003 at 02:18:07PM -0700, Doug Evans wrote: > Daniel Jacobowitz writes: > > The macro facility isn't, but a command could be added to do this > > without much trouble. > > For my own education, what's missing? A way to get at the return address in a convenience variable. > > I would rather us discuss the semantics of > > commands lists containing commands which resume the inferior. There > > must be a more user-useful way to approach it than we do now. > > What if you allowed multiple "resume" commands in the "top level" > breakpoint only, and allowed "nested" breakpoints only if they > either stopped execution (in which case execution stops) or if > the only "resume" they did was a tail-call-like continue. > If a nested breakpoint's command list does a resumption with a > non-tail-continue, execution stops. That might do it. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 19+ messages in thread
* return value of a gdb command 2003-04-17 21:19 ` Doug Evans 2003-04-17 21:44 ` Daniel Jacobowitz @ 2003-04-17 23:11 ` Smita 2003-04-17 23:13 ` Daniel Jacobowitz 1 sibling, 1 reply; 19+ messages in thread From: Smita @ 2003-04-17 23:11 UTC (permalink / raw) To: gdb Hi, Is it possible to capture return value of a gdb command (status=error or success)? What I want to do is: (gdb) <gdb-command> (gdb) if status of <gdb-command> == SUCCESS then do-something else do-something-else end (gdb) Is it posible to do this? Thanks Smita ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: return value of a gdb command 2003-04-17 23:11 ` return value of a gdb command Smita @ 2003-04-17 23:13 ` Daniel Jacobowitz 2003-04-18 12:10 ` Bob Rossi 2003-04-21 20:55 ` Andrew Cagney 0 siblings, 2 replies; 19+ messages in thread From: Daniel Jacobowitz @ 2003-04-17 23:13 UTC (permalink / raw) To: Smita; +Cc: gdb On Thu, Apr 17, 2003 at 04:11:38PM -0700, Smita wrote: > Hi, > Is it possible to capture return value of a gdb command (status=error or > success)? > What I want to do is: > (gdb) <gdb-command> > (gdb) if status of <gdb-command> == SUCCESS > then > do-something > else > do-something-else > end > (gdb) > > Is it posible to do this? Not right now, no. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: return value of a gdb command 2003-04-17 23:13 ` Daniel Jacobowitz @ 2003-04-18 12:10 ` Bob Rossi 2003-04-18 13:38 ` Daniel Jacobowitz 2003-04-21 20:55 ` Andrew Cagney 1 sibling, 1 reply; 19+ messages in thread From: Bob Rossi @ 2003-04-18 12:10 UTC (permalink / raw) To: Smita, gdb On Thu, Apr 17, 2003 at 07:13:45PM -0400, Daniel Jacobowitz wrote: > On Thu, Apr 17, 2003 at 04:11:38PM -0700, Smita wrote: > > Hi, > > Is it possible to capture return value of a gdb command (status=error or > > success)? > > What I want to do is: > > (gdb) <gdb-command> > > (gdb) if status of <gdb-command> == SUCCESS > > then > > do-something > > else > > do-something-else > > end > > (gdb) > > > > Is it posible to do this? > > Not right now, no. > > -- > Daniel Jacobowitz > MontaVista Software Debian GNU/Linux Developer That was something I thought would be useful also. Would it be a difficult patch? Bob Rossi ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: return value of a gdb command 2003-04-18 12:10 ` Bob Rossi @ 2003-04-18 13:38 ` Daniel Jacobowitz 0 siblings, 0 replies; 19+ messages in thread From: Daniel Jacobowitz @ 2003-04-18 13:38 UTC (permalink / raw) To: Smita, gdb On Fri, Apr 18, 2003 at 08:09:55AM -0400, Bob Rossi wrote: > On Thu, Apr 17, 2003 at 07:13:45PM -0400, Daniel Jacobowitz wrote: > > On Thu, Apr 17, 2003 at 04:11:38PM -0700, Smita wrote: > > > Hi, > > > Is it possible to capture return value of a gdb command (status=error or > > > success)? > > > What I want to do is: > > > (gdb) <gdb-command> > > > (gdb) if status of <gdb-command> == SUCCESS > > > then > > > do-something > > > else > > > do-something-else > > > end > > > (gdb) > > > > > > Is it posible to do this? > > > > Not right now, no. > > > > -- > > Daniel Jacobowitz > > MontaVista Software Debian GNU/Linux Developer > > That was something I thought would be useful also. Would it be a > difficult patch? Yes, probably - we don't really have a concept of "status". -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: return value of a gdb command 2003-04-17 23:13 ` Daniel Jacobowitz 2003-04-18 12:10 ` Bob Rossi @ 2003-04-21 20:55 ` Andrew Cagney 1 sibling, 0 replies; 19+ messages in thread From: Andrew Cagney @ 2003-04-21 20:55 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Smita, gdb > On Thu, Apr 17, 2003 at 04:11:38PM -0700, Smita wrote: > >> Hi, >> Is it possible to capture return value of a gdb command (status=error or >> success)? >> What I want to do is: >> (gdb) <gdb-command> >> (gdb) if status of <gdb-command> == SUCCESS >> then >> do-something >> else >> do-something-else >> end >> (gdb) >> >> Is it posible to do this? > > > Not right now, no. There is a try/catch patch lurking though (which makes more sense). Someone should dust it off. Andrew ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2003-04-21 20:55 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-04-14 20:56 breakpoint commands and finish Matt Thomas 2003-04-14 21:00 ` Joel Brobecker 2003-04-14 21:04 ` Joel Brobecker 2003-04-14 21:11 ` Doug Evans 2003-04-14 21:33 ` Joel Brobecker 2003-04-14 22:27 ` Doug Evans 2003-04-14 21:23 ` Matt Thomas 2003-04-17 17:47 ` Michael Snyder 2003-04-17 18:48 ` Matt Thomas 2003-04-17 20:19 ` Daniel Jacobowitz 2003-04-17 20:44 ` Doug Evans 2003-04-17 20:50 ` Daniel Jacobowitz 2003-04-17 21:19 ` Doug Evans 2003-04-17 21:44 ` Daniel Jacobowitz 2003-04-17 23:11 ` return value of a gdb command Smita 2003-04-17 23:13 ` Daniel Jacobowitz 2003-04-18 12:10 ` Bob Rossi 2003-04-18 13:38 ` Daniel Jacobowitz 2003-04-21 20:55 ` Andrew Cagney
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).