breakpoint commands and finish

breakpoint commands and finish

[Matt Thomas]

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

Re: breakpoint commands and finish

[Joel Brobecker]

> 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

Re: breakpoint commands and finish

[Joel Brobecker]

[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

Re: breakpoint commands and finish

[Doug Evans]

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.]

Re: breakpoint commands and finish

[Matt Thomas]

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

Re: breakpoint commands and finish

[Joel Brobecker]

> 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

Re: breakpoint commands and finish

[Doug Evans]

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.

Re: breakpoint commands and finish

[Michael Snyder]

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.

Re: breakpoint commands and finish

[Matt Thomas]

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

Re: breakpoint commands and finish

[Daniel Jacobowitz]

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

Re: breakpoint commands and finish

[Doug Evans]

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").

?

Re: breakpoint commands and finish

[Daniel Jacobowitz]

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

Re: breakpoint commands and finish

[Doug Evans]

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.

Re: breakpoint commands and finish

[Daniel Jacobowitz]

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

return value of a gdb command

[Smita]

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

Re: return value of a gdb command

[Daniel Jacobowitz]

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

Re: return value of a gdb command

[Bob Rossi]

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

Re: return value of a gdb command

[Daniel Jacobowitz]

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

Re: return value of a gdb command

[Andrew Cagney]

> 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