Re: [RFA/PATCH] breakpoint.c: fix until command

Re: [RFA/PATCH] breakpoint.c: fix until command

[Michael Elizabeth Chastain]

I think the problem is inherent in the design.  'until' with no argument
is meant for getting past loops in the current stack frame.  (The manual
says that).  So it makes sense that it skips over all subroutine calls
and also stops if the current stack frame inadvertently exits before
getting past the end of a loop.

'until LOCATION' is quite different.  The manual says:

  `until LOCATION'
  `u LOCATION'
       Continue running your program until either the specified location
       is reached, or the current stack frame returns.  LOCATION is any of
       the forms of argument acceptable to `break' (*note Setting
       breakpoints: Set Breaks).  This form of the command uses
       breakpoints, and hence is quicker than `until' without an argument.
      
Read this way, it looks like 'until LOCATION' is mostly a synonym for
'tbreak LOCATION; continue', with one extra tbreak at the return address
in the superior frame.  (break.exp says as much but they forgot about
the case where the current stack frame returns).

I think this is bad.  We already have 'tbreak'.  I think it's weird and
redundant to have another 'until LOCATION' which is a lot like 'tbreak'
and not much like 'until'.

Also I trust Michael Snyder's interpretation of the original intent more
than this particular section of The Fine Manual.  It's bad when the manual
talks about the implementation of both 'until' and 'until LOCATION' and
points out that they are different.  It implies that the original designers 
knew they had some inconsistency between 'until' and 'until LOCATION'.

How about this:

  . require that LOCATION in 'until LOCATION' to be in the current
    function and after $PC.  If it's not, then error.

  . use the same steppy implementation for 'until LOCATION' as 'until',
    not a breakpointy implementation.  In fact, 'until' with no arguments
    simply becomes 'until LOCATION' where gdb picks a location by default.

  . change the manual to reflect this

Specifically, in Elena's case of the factorial: if the user wants to
stop at line 99 in ANY frame, they can use 'tbreak 99' or 'break 99'.
If the user wants to stop at line 99 in the CURRENT frame, they can use
'until 99'.

And in Elena's second case: what if you are in 'bar' at the moment and you
say 'until bar'?  I think that should be an error, because 'bar' is in
the current function, but it is not after $PC.

Similarly if you are currently in 'bar' and say 'until quux'.  Just error it.
Don't turn it into a tbreak.

This would make both forms of 'until' behave the same, all the time.
The user can still do whatever they want.  Want to progress a little in
the same frame?  Call 'until', with or without an argument.  Want to be
somewhere and not care if the frames change?  Call 'break' or 'tbreak'.

From the Peanut Gallery,

Michael C

Re: [RFA/PATCH] breakpoint.c: fix until command

[Daniel Jacobowitz]

On Thu, Jan 02, 2003 at 10:15:34PM -0600, Michael Elizabeth Chastain wrote:
> I think the problem is inherent in the design.  'until' with no argument
> is meant for getting past loops in the current stack frame.  (The manual
> says that).  So it makes sense that it skips over all subroutine calls
> and also stops if the current stack frame inadvertently exits before
> getting past the end of a loop.
> 
> 'until LOCATION' is quite different.  The manual says:
> 
>   `until LOCATION'
>   `u LOCATION'
>        Continue running your program until either the specified location
>        is reached, or the current stack frame returns.  LOCATION is any of
>        the forms of argument acceptable to `break' (*note Setting
>        breakpoints: Set Breaks).  This form of the command uses
>        breakpoints, and hence is quicker than `until' without an argument.
>       
> Read this way, it looks like 'until LOCATION' is mostly a synonym for
> 'tbreak LOCATION; continue', with one extra tbreak at the return address
> in the superior frame.  (break.exp says as much but they forgot about
> the case where the current stack frame returns).
> 
> I think this is bad.  We already have 'tbreak'.  I think it's weird and
> redundant to have another 'until LOCATION' which is a lot like 'tbreak'
> and not much like 'until'.
> 
> Also I trust Michael Snyder's interpretation of the original intent more
> than this particular section of The Fine Manual.  It's bad when the manual
> talks about the implementation of both 'until' and 'until LOCATION' and
> points out that they are different.  It implies that the original designers 
> knew they had some inconsistency between 'until' and 'until LOCATION'.
> 
> How about this:
> 
>   . require that LOCATION in 'until LOCATION' to be in the current
>     function and after $PC.  If it's not, then error.

With a modern compiler, "after $PC" is pretty much meaningless.  Not
going to fly.  It could be re-ordered; there can be out-of-line code in
separate sections.

>   . use the same steppy implementation for 'until LOCATION' as 'until',
>     not a breakpointy implementation.  In fact, 'until' with no arguments
>     simply becomes 'until LOCATION' where gdb picks a location by default.

I like the idea of making "until LOCATION" work like "until".  I'd not
been exposed to this little beauty until this conversation made me go
examine the manual.  I don't see any reason for that to go to a
single-steppy behavior however.  And what it means when LOCATION is not
in function is not clear.  The problem is, do we know well enough when
LOCATION is or is not in FUNCTION to make any statements?

I'm not kidding about the out-of-line code thing.  I don't know if we
care about that, though; we ignore it everywhere else.  I don't want to
start making "after $PC" assumptions though.

>   . change the manual to reflect this
> 
> Specifically, in Elena's case of the factorial: if the user wants to
> stop at line 99 in ANY frame, they can use 'tbreak 99' or 'break 99'.
> If the user wants to stop at line 99 in the CURRENT frame, they can use
> 'until 99'.

After this discussion, I think I agree with the part of the behavior
you describe above.

> And in Elena's second case: what if you are in 'bar' at the moment and you
> say 'until bar'?  I think that should be an error, because 'bar' is in
> the current function, but it is not after $PC.
> 
> Similarly if you are currently in 'bar' and say 'until quux'.  Just error it.
> Don't turn it into a tbreak.
> 
> This would make both forms of 'until' behave the same, all the time.
> The user can still do whatever they want.  Want to progress a little in
> the same frame?  Call 'until', with or without an argument.  Want to be
> somewhere and not care if the frames change?  Call 'break' or 'tbreak'.

The implicit breakpoint at the return is still somewhat useful, IMHO. 
It's not quite the same; when you hit one of the breakpoints (or stop
for some other reason), both vanish.  I don't think that's what tbreaks
do.

I'm still undecided about what to do if LOCATION is not in the
function.  Maybe you're right and we should make this an error.  What
if LOCATION is in the frame that called this one?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/PATCH] breakpoint.c: fix until command

[Michael Snyder]

Daniel Jacobowitz wrote:
> 
> On Thu, Jan 02, 2003 at 10:15:34PM -0600, Michael Elizabeth Chastain wrote:
> > I think the problem is inherent in the design.  'until' with no argument
> > is meant for getting past loops in the current stack frame.  (The manual
> > says that).  So it makes sense that it skips over all subroutine calls
> > and also stops if the current stack frame inadvertently exits before
> > getting past the end of a loop.
> >
> > 'until LOCATION' is quite different.  The manual says:
> >
> >   `until LOCATION'
> >   `u LOCATION'
> >        Continue running your program until either the specified location
> >        is reached, or the current stack frame returns.  LOCATION is any of
> >        the forms of argument acceptable to `break' (*note Setting
> >        breakpoints: Set Breaks).  This form of the command uses
> >        breakpoints, and hence is quicker than `until' without an argument.
> >
> > Read this way, it looks like 'until LOCATION' is mostly a synonym for
> > 'tbreak LOCATION; continue', with one extra tbreak at the return address
> > in the superior frame.  (break.exp says as much but they forgot about
> > the case where the current stack frame returns).
> >
> > I think this is bad.  We already have 'tbreak'.  I think it's weird and
> > redundant to have another 'until LOCATION' which is a lot like 'tbreak'
> > and not much like 'until'.
> >
> > Also I trust Michael Snyder's interpretation of the original intent more
> > than this particular section of The Fine Manual.  It's bad when the manual
> > talks about the implementation of both 'until' and 'until LOCATION' and
> > points out that they are different.  It implies that the original designers
> > knew they had some inconsistency between 'until' and 'until LOCATION'.
> >
> > How about this:
> >
> >   . require that LOCATION in 'until LOCATION' to be in the current
> >     function and after $PC.  If it's not, then error.
> 
> With a modern compiler, "after $PC" is pretty much meaningless.  Not
> going to fly.  It could be re-ordered; there can be out-of-line code in
> separate sections.
> 
> >   . use the same steppy implementation for 'until LOCATION' as 'until',
> >     not a breakpointy implementation.  In fact, 'until' with no arguments
> >     simply becomes 'until LOCATION' where gdb picks a location by default.
> 
> I like the idea of making "until LOCATION" work like "until".  I'd not
> been exposed to this little beauty until this conversation made me go
> examine the manual.  I don't see any reason for that to go to a
> single-steppy behavior however.  And what it means when LOCATION is not
> in function is not clear.  The problem is, do we know well enough when
> LOCATION is or is not in FUNCTION to make any statements?
> 
> I'm not kidding about the out-of-line code thing.  I don't know if we
> care about that, though; we ignore it everywhere else.  I don't want to
> start making "after $PC" assumptions though.
> 
> >   . change the manual to reflect this
> >
> > Specifically, in Elena's case of the factorial: if the user wants to
> > stop at line 99 in ANY frame, they can use 'tbreak 99' or 'break 99'.
> > If the user wants to stop at line 99 in the CURRENT frame, they can use
> > 'until 99'.
> 
> After this discussion, I think I agree with the part of the behavior
> you describe above.
> 
> > And in Elena's second case: what if you are in 'bar' at the moment and you
> > say 'until bar'?  I think that should be an error, because 'bar' is in
> > the current function, but it is not after $PC.
> >
> > Similarly if you are currently in 'bar' and say 'until quux'.  Just error it.
> > Don't turn it into a tbreak.
> >
> > This would make both forms of 'until' behave the same, all the time.
> > The user can still do whatever they want.  Want to progress a little in
> > the same frame?  Call 'until', with or without an argument.  Want to be
> > somewhere and not care if the frames change?  Call 'break' or 'tbreak'.
> 
> The implicit breakpoint at the return is still somewhat useful, IMHO.
> It's not quite the same; when you hit one of the breakpoints (or stop
> for some other reason), both vanish.  I don't think that's what tbreaks
> do.
> 
> I'm still undecided about what to do if LOCATION is not in the
> function.  Maybe you're right and we should make this an error.  What
> if LOCATION is in the frame that called this one?

My thoughts have run in similar grooves.  ;-)
The sticking point is "is <location> in the current function?"
I believe we can answer that, by calling find_pc_partial_function.
That will give us the function's address range, and we can then
immediately determine whether <location> is in (use frame-relative bp),
or out (don't do that).

Michael

Re: [RFA/PATCH] breakpoint.c: fix until command

[Daniel Jacobowitz]

On Fri, Jan 03, 2003 at 01:52:07PM -0800, Michael Snyder wrote:
> > I'm still undecided about what to do if LOCATION is not in the
> > function.  Maybe you're right and we should make this an error.  What
> > if LOCATION is in the frame that called this one?
> 
> My thoughts have run in similar grooves.  ;-)
> The sticking point is "is <location> in the current function?"
> I believe we can answer that, by calling find_pc_partial_function.
> That will give us the function's address range, and we can then
> immediately determine whether <location> is in (use frame-relative bp),
> or out (don't do that).

I think we're making actual progress here.... I agree.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/PATCH] breakpoint.c: fix until command

[Elena Zannoni]

Daniel Jacobowitz writes:
 > On Fri, Jan 03, 2003 at 01:52:07PM -0800, Michael Snyder wrote:
 > > > I'm still undecided about what to do if LOCATION is not in the
 > > > function.  Maybe you're right and we should make this an error.  What
 > > > if LOCATION is in the frame that called this one?
 > > 
 > > My thoughts have run in similar grooves.  ;-)
 > > The sticking point is "is <location> in the current function?"
 > > I believe we can answer that, by calling find_pc_partial_function.
 > > That will give us the function's address range, and we can then
 > > immediately determine whether <location> is in (use frame-relative bp),
 > > or out (don't do that).
 > 
 > I think we're making actual progress here.... I agree.
 > 

<rant>
but this is the opposite of what we agreed on a month ago. 
</rant>

We are giving up on the until foo behavior now.

Anyway, do an 'help until' in gdb.... the text of it goes back as
far as the frame checking code, which just shows that this whole thing
was botched from day one.

Elena


 > -- 
 > Daniel Jacobowitz
 > MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/PATCH] breakpoint.c: fix until command

[Michael Snyder]

Elena Zannoni wrote:
> 
> Daniel Jacobowitz writes:
>  > On Fri, Jan 03, 2003 at 01:52:07PM -0800, Michael Snyder wrote:
>  > > > I'm still undecided about what to do if LOCATION is not in the
>  > > > function.  Maybe you're right and we should make this an error.  What
>  > > > if LOCATION is in the frame that called this one?
>  > >
>  > > My thoughts have run in similar grooves.  ;-)
>  > > The sticking point is "is <location> in the current function?"
>  > > I believe we can answer that, by calling find_pc_partial_function.
>  > > That will give us the function's address range, and we can then
>  > > immediately determine whether <location> is in (use frame-relative bp),
>  > > or out (don't do that).
>  >
>  > I think we're making actual progress here.... I agree.
>  >
> 
> <rant>
> but this is the opposite of what we agreed on a month ago.
> </rant>
> 
> We are giving up on the until foo behavior now.

I thought we were trying to find a way to accomodate both behaviors.


> Anyway, do an 'help until' in gdb.... the text of it goes back as
> far as the frame checking code, which just shows that this whole thing
> was botched from day one.

Yep, the frame behavior has never been documented.

Maybe we should really find out whether anyone else's recollections
about this match mine...

[Yo Stan...]

Re: [RFA/PATCH] breakpoint.c: fix until command

[Elena Zannoni]

Michael Elizabeth Chastain writes:
 > I think the problem is inherent in the design.  'until' with no argument
 > is meant for getting past loops in the current stack frame.  (The manual
 > says that).  So it makes sense that it skips over all subroutine calls
 > and also stops if the current stack frame inadvertently exits before
 > getting past the end of a loop.
 > 
 > 'until LOCATION' is quite different.  The manual says:
 > 
 >   `until LOCATION'
 >   `u LOCATION'
 >        Continue running your program until either the specified location
 >        is reached, or the current stack frame returns.  LOCATION is any of
 >        the forms of argument acceptable to `break' (*note Setting
 >        breakpoints: Set Breaks).  This form of the command uses
 >        breakpoints, and hence is quicker than `until' without an argument.
 >       
 > Read this way, it looks like 'until LOCATION' is mostly a synonym for
 > 'tbreak LOCATION; continue', with one extra tbreak at the return address
 > in the superior frame.  (break.exp says as much but they forgot about
 > the case where the current stack frame returns).

See the thread from November on gdb@sources.

 > 
 > I think this is bad.  We already have 'tbreak'.  I think it's weird and
 > redundant to have another 'until LOCATION' which is a lot like 'tbreak'
 > and not much like 'until'.
 > 
 > Also I trust Michael Snyder's interpretation of the original intent more
 > than this particular section of The Fine Manual.  It's bad when the manual
 > talks about the implementation of both 'until' and 'until LOCATION' and
 > points out that they are different.  It implies that the original designers 
 > knew they had some inconsistency between 'until' and 'until LOCATION'.
 > 

Which tells me that the design was flawed. 

 > How about this:
 > 
 >   . require that LOCATION in 'until LOCATION' to be in the current
 >     function and after $PC.  If it's not, then error.
 > 
 >   . use the same steppy implementation for 'until LOCATION' as 'until',
 >     not a breakpointy implementation.  In fact, 'until' with no arguments
 >     simply becomes 'until LOCATION' where gdb picks a location by default.
 > 
 >   . change the manual to reflect this
 > 


Definitely the description in the manual needs more detail.  I prefer
the until == tbreak behavior, which seems the most intuitive, given
the replies to the November thread.

I think that using decode_line_1 may be the real problem, because that
allows all kind of arguments to be used, just like for a breakpoint.

 > Specifically, in Elena's case of the factorial: if the user wants to
 > stop at line 99 in ANY frame, they can use 'tbreak 99' or 'break 99'.
 > If the user wants to stop at line 99 in the CURRENT frame, they can use
 > 'until 99'.
 > 
 > And in Elena's second case: what if you are in 'bar' at the moment and you
 > say 'until bar'?  I think that should be an error, because 'bar' is in
 > the current function, but it is not after $PC.

My case was when bar is recursive. you will execute the beginning of
bar again, so 'until bar' would make sense in this case. I think this
is what throws a wrench in the works.

 > 
 > Similarly if you are currently in 'bar' and say 'until quux'.  Just error it.
 > Don't turn it into a tbreak.
 > 
 > This would make both forms of 'until' behave the same, all the time.
 > The user can still do whatever they want.  Want to progress a little in
 > the same frame?  Call 'until', with or without an argument.  Want to be
 > somewhere and not care if the frames change?  Call 'break' or 'tbreak'.
 > 

Don't know, I don't like it, but whatever we do we need to
disambiguate the behavior. It's just plain confusing right now.

 > >From the Peanut Gallery,
 > 
 > Michael C

Re: [RFA/PATCH] breakpoint.c: fix until command

[Michael Snyder]

Elena Zannoni wrote:
> 
> Michael Elizabeth Chastain writes:
>  > I think the problem is inherent in the design.  'until' with no argument
>  > is meant for getting past loops in the current stack frame.  (The manual
>  > says that).  So it makes sense that it skips over all subroutine calls
>  > and also stops if the current stack frame inadvertently exits before
>  > getting past the end of a loop.
>  >
>  > 'until LOCATION' is quite different.  The manual says:
>  >
>  >   `until LOCATION'
>  >   `u LOCATION'
>  >        Continue running your program until either the specified location
>  >        is reached, or the current stack frame returns.  LOCATION is any of
>  >        the forms of argument acceptable to `break' (*note Setting
>  >        breakpoints: Set Breaks).  This form of the command uses
>  >        breakpoints, and hence is quicker than `until' without an argument.
>  >
>  > Read this way, it looks like 'until LOCATION' is mostly a synonym for
>  > 'tbreak LOCATION; continue', with one extra tbreak at the return address
>  > in the superior frame.  (break.exp says as much but they forgot about
>  > the case where the current stack frame returns).
> 
> See the thread from November on gdb@sources.
> 
>  >
>  > I think this is bad.  We already have 'tbreak'.  I think it's weird and
>  > redundant to have another 'until LOCATION' which is a lot like 'tbreak'
>  > and not much like 'until'.
>  >
>  > Also I trust Michael Snyder's interpretation of the original intent more
>  > than this particular section of The Fine Manual.  It's bad when the manual
>  > talks about the implementation of both 'until' and 'until LOCATION' and
>  > points out that they are different.  It implies that the original designers
>  > knew they had some inconsistency between 'until' and 'until LOCATION'.
>  >
> 
> Which tells me that the design was flawed.

'Design'?   ;-)


>  > How about this:
>  >
>  >   . require that LOCATION in 'until LOCATION' to be in the current
>  >     function and after $PC.  If it's not, then error.
>  >
>  >   . use the same steppy implementation for 'until LOCATION' as 'until',
>  >     not a breakpointy implementation.  In fact, 'until' with no arguments
>  >     simply becomes 'until LOCATION' where gdb picks a location by default.
>  >
>  >   . change the manual to reflect this
>  >
> 
> Definitely the description in the manual needs more detail.  I prefer
> the until == tbreak behavior, which seems the most intuitive, given
> the replies to the November thread.
> 
> I think that using decode_line_1 may be the real problem, because that
> allows all kind of arguments to be used, just like for a breakpoint.

Well, but that's the stated intent.  Maybe it was over-ambitious?


>  > Specifically, in Elena's case of the factorial: if the user wants to
>  > stop at line 99 in ANY frame, they can use 'tbreak 99' or 'break 99'.
>  > If the user wants to stop at line 99 in the CURRENT frame, they can use
>  > 'until 99'.
>  >
>  > And in Elena's second case: what if you are in 'bar' at the moment and you
>  > say 'until bar'?  I think that should be an error, because 'bar' is in
>  > the current function, but it is not after $PC.
> 
> My case was when bar is recursive. you will execute the beginning of
> bar again, so 'until bar' would make sense in this case. I think this
> is what throws a wrench in the works.

What happens if you're at line 100 and you say "until 99"?


>  > Similarly if you are currently in 'bar' and say 'until quux'.  Just error it.
>  > Don't turn it into a tbreak.
>  >
>  > This would make both forms of 'until' behave the same, all the time.
>  > The user can still do whatever they want.  Want to progress a little in
>  > the same frame?  Call 'until', with or without an argument.  Want to be
>  > somewhere and not care if the frames change?  Call 'break' or 'tbreak'.
>  >
> 
> Don't know, I don't like it, but whatever we do we need to
> disambiguate the behavior. It's just plain confusing right now.

That it is, but forbidding usage that was formerly allowed
is just another way of changing the documented (or in this
case, un-documented) behavior.

Re: [RFA/PATCH] breakpoint.c: fix until command

[Elena Zannoni]

Michael Snyder writes:
 > Elena Zannoni wrote:
 > > 
 > > Michael Elizabeth Chastain writes:
 > >  > I think the problem is inherent in the design.  'until' with no argument
 > >  > is meant for getting past loops in the current stack frame.  (The manual
 > >  > says that).  So it makes sense that it skips over all subroutine calls
 > >  > and also stops if the current stack frame inadvertently exits before
 > >  > getting past the end of a loop.
 > >  >
 > >  > 'until LOCATION' is quite different.  The manual says:
 > >  >
 > >  >   `until LOCATION'
 > >  >   `u LOCATION'
 > >  >        Continue running your program until either the specified location
 > >  >        is reached, or the current stack frame returns.  LOCATION is any of
 > >  >        the forms of argument acceptable to `break' (*note Setting
 > >  >        breakpoints: Set Breaks).  This form of the command uses
 > >  >        breakpoints, and hence is quicker than `until' without an argument.
 > >  >
 > >  > Read this way, it looks like 'until LOCATION' is mostly a synonym for
 > >  > 'tbreak LOCATION; continue', with one extra tbreak at the return address
 > >  > in the superior frame.  (break.exp says as much but they forgot about
 > >  > the case where the current stack frame returns).
 > > 
 > > See the thread from November on gdb@sources.
 > > 
 > >  >
 > >  > I think this is bad.  We already have 'tbreak'.  I think it's weird and
 > >  > redundant to have another 'until LOCATION' which is a lot like 'tbreak'
 > >  > and not much like 'until'.
 > >  >
 > >  > Also I trust Michael Snyder's interpretation of the original intent more
 > >  > than this particular section of The Fine Manual.  It's bad when the manual
 > >  > talks about the implementation of both 'until' and 'until LOCATION' and
 > >  > points out that they are different.  It implies that the original designers
 > >  > knew they had some inconsistency between 'until' and 'until LOCATION'.
 > >  >
 > > 
 > > Which tells me that the design was flawed.
 > 
 > 'Design'?   ;-)
 > 
 > 
 > >  > How about this:
 > >  >
 > >  >   . require that LOCATION in 'until LOCATION' to be in the current
 > >  >     function and after $PC.  If it's not, then error.
 > >  >
 > >  >   . use the same steppy implementation for 'until LOCATION' as 'until',
 > >  >     not a breakpointy implementation.  In fact, 'until' with no arguments
 > >  >     simply becomes 'until LOCATION' where gdb picks a location by default.
 > >  >
 > >  >   . change the manual to reflect this
 > >  >
 > > 
 > > Definitely the description in the manual needs more detail.  I prefer
 > > the until == tbreak behavior, which seems the most intuitive, given
 > > the replies to the November thread.
 > > 
 > > I think that using decode_line_1 may be the real problem, because that
 > > allows all kind of arguments to be used, just like for a breakpoint.
 > 
 > Well, but that's the stated intent.  Maybe it was over-ambitious?
 > 

very likely so. If you accept the arguments that 'break' accepts, then
'until foo' should do something meaningful. Otherwise, why go through
the effort. Apparently they thought it did something useful. I tried
to build 4.16 but I cannot find a host where it builds. Maybe it
really worked both ways back then?

 > 
 > >  > Specifically, in Elena's case of the factorial: if the user wants to
 > >  > stop at line 99 in ANY frame, they can use 'tbreak 99' or 'break 99'.
 > >  > If the user wants to stop at line 99 in the CURRENT frame, they can use
 > >  > 'until 99'.
 > >  >
 > >  > And in Elena's second case: what if you are in 'bar' at the moment and you
 > >  > say 'until bar'?  I think that should be an error, because 'bar' is in
 > >  > the current function, but it is not after $PC.
 > > 
 > > My case was when bar is recursive. you will execute the beginning of
 > > bar again, so 'until bar' would make sense in this case. I think this
 > > is what throws a wrench in the works.
 > 
 > What happens if you're at line 100 and you say "until 99"?
 > 

Well, you could be at the last line in the body of a loop, and you may
want to go to the first line of the body of the loop, for instance. So
you cannot discharge that. 

 > 
 > >  > Similarly if you are currently in 'bar' and say 'until quux'.  Just error it.
 > >  > Don't turn it into a tbreak.
 > >  >
 > >  > This would make both forms of 'until' behave the same, all the time.
 > >  > The user can still do whatever they want.  Want to progress a little in
 > >  > the same frame?  Call 'until', with or without an argument.  Want to be
 > >  > somewhere and not care if the frames change?  Call 'break' or 'tbreak'.
 > >  >
 > > 
 > > Don't know, I don't like it, but whatever we do we need to
 > > disambiguate the behavior. It's just plain confusing right now.
 > 
 > That it is, but forbidding usage that was formerly allowed
 > is just another way of changing the documented (or in this
 > case, un-documented) behavior.

Well, the recursive behavior is the one that is undocumented. Look at
the output of 'help until'. I think somebody was sniffing something
powerful that day.

Elena

Re: [RFA/PATCH] breakpoint.c: fix until command

[Michael Snyder]

Elena Zannoni wrote:
> 
> Michael Snyder writes:
>  > Elena Zannoni wrote:
>  > >
>  > > Michael Elizabeth Chastain writes:
>  > >  > I think the problem is inherent in the design.  'until' with no argument
>  > >  > is meant for getting past loops in the current stack frame.  (The manual
>  > >  > says that).  So it makes sense that it skips over all subroutine calls
>  > >  > and also stops if the current stack frame inadvertently exits before
>  > >  > getting past the end of a loop.
>  > >  >
>  > >  > 'until LOCATION' is quite different.  The manual says:
>  > >  >
>  > >  >   `until LOCATION'
>  > >  >   `u LOCATION'
>  > >  >        Continue running your program until either the specified location
>  > >  >        is reached, or the current stack frame returns.  LOCATION is any of
>  > >  >        the forms of argument acceptable to `break' (*note Setting
>  > >  >        breakpoints: Set Breaks).  This form of the command uses
>  > >  >        breakpoints, and hence is quicker than `until' without an argument.
>  > >  >
>  > >  > Read this way, it looks like 'until LOCATION' is mostly a synonym for
>  > >  > 'tbreak LOCATION; continue', with one extra tbreak at the return address
>  > >  > in the superior frame.  (break.exp says as much but they forgot about
>  > >  > the case where the current stack frame returns).
>  > >
>  > > See the thread from November on gdb@sources.
>  > >
>  > >  >
>  > >  > I think this is bad.  We already have 'tbreak'.  I think it's weird and
>  > >  > redundant to have another 'until LOCATION' which is a lot like 'tbreak'
>  > >  > and not much like 'until'.
>  > >  >
>  > >  > Also I trust Michael Snyder's interpretation of the original intent more
>  > >  > than this particular section of The Fine Manual.  It's bad when the manual
>  > >  > talks about the implementation of both 'until' and 'until LOCATION' and
>  > >  > points out that they are different.  It implies that the original designers
>  > >  > knew they had some inconsistency between 'until' and 'until LOCATION'.
>  > >  >
>  > >
>  > > Which tells me that the design was flawed.
>  >
>  > 'Design'?   ;-)
>  >
>  >
>  > >  > How about this:
>  > >  >
>  > >  >   . require that LOCATION in 'until LOCATION' to be in the current
>  > >  >     function and after $PC.  If it's not, then error.
>  > >  >
>  > >  >   . use the same steppy implementation for 'until LOCATION' as 'until',
>  > >  >     not a breakpointy implementation.  In fact, 'until' with no arguments
>  > >  >     simply becomes 'until LOCATION' where gdb picks a location by default.
>  > >  >
>  > >  >   . change the manual to reflect this
>  > >  >
>  > >
>  > > Definitely the description in the manual needs more detail.  I prefer
>  > > the until == tbreak behavior, which seems the most intuitive, given
>  > > the replies to the November thread.
>  > >
>  > > I think that using decode_line_1 may be the real problem, because that
>  > > allows all kind of arguments to be used, just like for a breakpoint.
>  >
>  > Well, but that's the stated intent.  Maybe it was over-ambitious?
>  >
> 
> very likely so. If you accept the arguments that 'break' accepts, then
> 'until foo' should do something meaningful. Otherwise, why go through
> the effort. Apparently they thought it did something useful. I tried
> to build 4.16 but I cannot find a host where it builds. Maybe it
> really worked both ways back then?

I confess that it never occurred to me to say "until foo".


>  > >  > Specifically, in Elena's case of the factorial: if the user wants to
>  > >  > stop at line 99 in ANY frame, they can use 'tbreak 99' or 'break 99'.
>  > >  > If the user wants to stop at line 99 in the CURRENT frame, they can use
>  > >  > 'until 99'.
>  > >  >
>  > >  > And in Elena's second case: what if you are in 'bar' at the moment and you
>  > >  > say 'until bar'?  I think that should be an error, because 'bar' is in
>  > >  > the current function, but it is not after $PC.
>  > >
>  > > My case was when bar is recursive. you will execute the beginning of
>  > > bar again, so 'until bar' would make sense in this case. I think this
>  > > is what throws a wrench in the works.
>  >
>  > What happens if you're at line 100 and you say "until 99"?
>  >
> 
> Well, you could be at the last line in the body of a loop, and you may
> want to go to the first line of the body of the loop, for instance. So
> you cannot discharge that.

The question I meant to ask was "what does it currently/traditionally do?",
but if you're thinking of "what _should_ it do", that's a good question too.

>  > >  > Similarly if you are currently in 'bar' and say 'until quux'.  Just error it.
>  > >  > Don't turn it into a tbreak.
>  > >  >
>  > >  > This would make both forms of 'until' behave the same, all the time.
>  > >  > The user can still do whatever they want.  Want to progress a little in
>  > >  > the same frame?  Call 'until', with or without an argument.  Want to be
>  > >  > somewhere and not care if the frames change?  Call 'break' or 'tbreak'.
>  > >  >
>  > >
>  > > Don't know, I don't like it, but whatever we do we need to
>  > > disambiguate the behavior. It's just plain confusing right now.
>  >
>  > That it is, but forbidding usage that was formerly allowed
>  > is just another way of changing the documented (or in this
>  > case, un-documented) behavior.
> 
> Well, the recursive behavior is the one that is undocumented. Look at
> the output of 'help until'. I think somebody was sniffing something
> powerful that day.

I know, I know...
It could be me, since so far I seem to be the only one who
remembers it that way... but damned if I don't seem to remember
reading about it in a comment -- probably in breakpoint.c.

Re: [RFA/PATCH] breakpoint.c: fix until command

[Michael Elizabeth Chastain]

Elena Zannoni writes:
> Not as an option, I was thinking as a separate command.
> (to tell you the through, it should just be an argument to 'continue').

I like that.  Then various frobs like 'stay in the current frame'
become options in the command.

Michael C

Re: [RFA/PATCH] breakpoint.c: fix until command

[Michael Elizabeth Chastain]

Michael Snyder writes:
> Ah, that's right.  I was thinking of that usage, but I forgot
> that it starts from the beginning.

Whoa, so did somebody who worked on gdb.c++/namespace.exp and
a few other files.  That might even be me!

  #
  # set it up at a breakpoint so we can play with the variable values
  #
  if ![runto_main] then {
    perror "couldn't run to breakpoint"
    continue
  }

  if ![runto 'marker1'] then {
    perror "couldn't run to marker1"
    continue
  }

Optimization opportunity!

Michael C

Re: [RFA/PATCH] breakpoint.c: fix until command

[Michael Elizabeth Chastain]

Michael Snyder writes:
> run-to?

Psychologically, 'run-to' fits into a good niche, but it might run into
abbreviation problems.  If it doesn't run into abbreviation problems
then I like it as a new name for this sort of thing.

The original 'until' name is a bit weird.  The point is to get out of a
loop, so 'progress' or 'endloop' or 'outloop' or 'done' ... but 'until'??
Maybe somebody wanted a name that started with 'u' for easy abbreviation.

Michael C

Re: [RFA/PATCH] breakpoint.c: fix until command

[Michael Elizabeth Chastain]

Michael Snyder formulates:
> 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.

In this formulation, my proposal would have: '3) error'.  It's
actually a pretty cool formulation because it makes the diff
between elena's idea and my idea a small diff.

I think that my proposal has gotten a sufficient hearing.
So go ahead.

Michael C
loyal opposition

Re: [RFA/PATCH] breakpoint.c: fix until command

[Andrew Cagney]

> Michael Snyder formulates:
> 
>> 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.

This doesn't work.  It hightlights why the edge condition can't be 
cleanly resolved.  You can't rely on ``func_start == loc'' as an 
identifier of this special case.  The prolog analysis / skip will just 
make the behavior confusing / conunter intitive and the doco really 
messy.  Look at the heated debate that occures with ``break foo'' vs 
``break *foo'' vs ``break lineof(foo)''.

Consider for instance:

	(gdb) break foo
	(gdb) c
	Break point foo reached
	(gdb) until foo

depending on the prolog analysis (and hence the architecture), this will 
behave differently.

I personally think the decision reached several months ago should stand 
- `until foo' behaves per the documentation.

We can then separatly persue a recursive centric version of the function 
vis:

- finish LOCATION
- rbreak
(set tempoary breakpoint at return address)

...

Andrew

Re: [RFA/PATCH] breakpoint.c: fix until command

[Michael Snyder]

Andrew Cagney wrote:
> 
> I personally think the decision reached several months ago should stand
> - `until foo' behaves per the documentation.

Since that would actually change the traditional behavior,
maybe we should bring more users into the discussion?
Eg. by moving it to gdb?

Re: [RFA/PATCH] breakpoint.c: fix until command

[Michael Elizabeth Chastain]

Elena Z writes:
> this is essentially what it does now.  But instead of erroring out it
> stops at the exit from the current frame.  Because we cannot reliably
> distinguish a. from b. Roughly, your error is equivalent to exiting
> the frame.

Yes.  It is quite similar to the existing behavior, just with the
error attached.

In a way, the point of the error is to seal off an unruly possibility.
That enables 'until' and 'until LOCATION' to be simple and consistent:
they would always stop in either the current frame or the return-breakpoint.

It's up to you to decide, I just needed to voice my proposal.

I will calm down now.  :)

Michael C

Re: [RFA/PATCH] breakpoint.c: fix until command

[Michael Elizabeth Chastain]

> We support other compilers; we support other versions of GCC.  The life
> of a debugger is that making people fix the compiler isn't going to
> fly.

Yeah, I see where you are coming from.

I am talking about a mapping from file:line to source function
without going through PC's at all.  That would not handle the case
of 'until *0x12345678'.  But it would handle other cases.

In your example: the target program is on line 11, "return a * baz()".
The user asks to proceed "until 4", which is the "-complicated" part of
inline function baz().

In my design, gdb would say: "error, line 4 is not in main".  I think your
point is that code from line 4 actually is present in main() because baz()
got inlined into main.  (And in your example, line 4 is present exactly
once in main, whereas in the general case it could be present multiple
times).

What happens right now when the user types "break 4" to break inside
the inline function?  I'm experimenting, and it looks like gdb sets one
breakpoint on one caller to the inline function.  "break 4" does not
work properly.

Once we have mechanism to implement "break 4", we can use the same
mechanism for "until 4".  We can calculate the set of locations for "break
4" and intersect that with the low_pc and high_pc of the current frame.
If that set is null, then error.  Then set momentary breakpoints on those
locations, restricted to the current frame, plus a momentary breakpoint
on the return location, and proceed.

Until "break 4" works, "until 4" can at least refuse to do anything.

> [Similarly, we need to stop assuming a symbol name maps to one PC. 
   This causes us to mess up constructor breakpoints right now.  GDB has
   essentially no support for debugging inline functions, and it's a
   problem there too.]

I agree.  The constructor part is really hurting users.  With inline
functions, the programmer knows "I have copies of the object code
for the function everywhere, I understand why gdb is not smart enough
to handle that yet."  With constructors, the programmer does not know
that they have multiple copies of the object code, so gdb's deficiency
shows up as a surprise.

Michael C

Re: [RFA/PATCH] breakpoint.c: fix until command

[Michael Elizabeth Chastain]

My proposal for the behavior matrix is:

until:
  continue until any source line > the current source line is reached,
  in the current stack frame, or the current stack frame pops,
  whichever comes first.

until LOCATION:
  a. LOCATION is in current function: continue until $PC == LINE
     in the current stack frame, or the current stack frame pops,
     whichever comes first.
  b. LOCATION not in current function: error

In the 'until LOCATION' case, I guess it's okay for the user to be on
line 70 and ask to continue 'until line 65'.  The user is expecting
the program to get to line 65 and they are probably right.

I don't want to say "for every command line, choose some behavior and
implement it".  That leads to a bunch of quirky non-orthogonal commands.
I want to say "for everything we can imagine the user doing,
provide one simple way to do it."  In Elena's matrix:

  until funcname:
    d. funcname called from current frame (2) --> continue until func is reached
    e. funcname not called from current frame --> cont until current frame pops.

There is already a way to do almost exactly this in gdb:

  tbreak funcname
  finish

If we had a user-accessible 'mbreak' command for momentary breakpoints,
then this would be identical:

  mbreak funcname
  finish

Judging by the November thread, most people really want to have
'until LOCATION' always do something, even when LOCATION is not in
the current frame.  I really think it should give an error
in that case.

Michael C

Re: [RFA/PATCH] breakpoint.c: fix until command

[Elena Zannoni]

Michael Elizabeth Chastain writes:
 > My proposal for the behavior matrix is:
 > 
 > until:
 >   continue until any source line > the current source line is reached,
 >   in the current stack frame, or the current stack frame pops,
 >   whichever comes first.
 > 
 > until LOCATION:
 >   a. LOCATION is in current function: continue until $PC == LINE
 >      in the current stack frame, or the current stack frame pops,
 >      whichever comes first.
 >   b. LOCATION not in current function: error
 > 

this is essentially what it does now.  But instead of erroring out it
stops at the exit from the current frame.  Because we cannot reliably
distinguish a. from b. Roughly, your error is equivalent to exiting
the frame.

 > In the 'until LOCATION' case, I guess it's okay for the user to be on
 > line 70 and ask to continue 'until line 65'.  The user is expecting
 > the program to get to line 65 and they are probably right.
 > 

there could be a loop, and they may want to go back to the top, so yes.

 > I don't want to say "for every command line, choose some behavior and
 > implement it".  That leads to a bunch of quirky non-orthogonal commands.
 > I want to say "for everything we can imagine the user doing,
 > provide one simple way to do it."  In Elena's matrix:
 > 
 >   until funcname:
 >     d. funcname called from current frame (2) --> continue until func is reached
 >     e. funcname not called from current frame --> cont until current frame pops.
 > 
 > There is already a way to do almost exactly this in gdb:
 > 
 >   tbreak funcname
 >   finish
 > 
 > If we had a user-accessible 'mbreak' command for momentary breakpoints,
 > then this would be identical:
 > 
 >   mbreak funcname
 >   finish
 > 
 > Judging by the November thread, most people really want to have
 > 'until LOCATION' always do something, even when LOCATION is not in

Yes, some people agreed it would be more convenient to have 'until' do
something different from what it does currently (back to what it did
in 4.18). 

Independently of that, we all agree now that the 2 behaviors are
incompatible. So either we define another command, or leave the world
as is (but fix the doco and the testsuite).


 > the current frame.  I really think it should give an error
 > in that case.
 > 
 > Michael C

Re: [RFA/PATCH] breakpoint.c: fix until command

[Michael Elizabeth Chastain]

Hi Elena,

> See the thread from November on gdb@sources.

Gotcha.  Thanks.

> I think that using decode_line_1 may be the real problem, because that
> allows all kind of arguments to be used, just like for a breakpoint.

I think the real problems are: (a) we haven't designed what should
actually happen in all cases, and then (b) Daniel J says that some
decision-making information is not reliable to get (when the user says
'until 70' gdb cannot reliably tell whether line 70 is in the current
function).

Michael C

Re: [RFA/PATCH] breakpoint.c: fix until command

[Michael Snyder]

Michael Elizabeth Chastain wrote:
> 
> Hi Elena,
> 
> > See the thread from November on gdb@sources.
> 
> Gotcha.  Thanks.
> 
> > I think that using decode_line_1 may be the real problem, because that
> > allows all kind of arguments to be used, just like for a breakpoint.
> 
> I think the real problems are: (a) we haven't designed what should
> actually happen in all cases, and then (b) Daniel J says that some
> decision-making information is not reliable to get (when the user says
> 'until 70' gdb cannot reliably tell whether line 70 is in the current
> function).

Yes it can, unles code motion actually breaks functions into multiple
chunks.  find_pc_partial_function will return the function's bounding
addresses.

Re: [RFA/PATCH] breakpoint.c: fix until command

[Michael Elizabeth Chastain]

Hi Daniel,

mec> So we might need additional promises.
mec> I think it would be reasonable for us to ask for them if we decide
mec> we need them.

drow> I don't.  Promises don't mean anything; we have existing code.

A promise in a manual is a contract.  If gcc violates its contract,
then gcc is at fault, and we can file bug reports against it.  That's
what I'm getting at.

mec> If we are in foo:67, and the user asks to 'until 70',
mec> then I bet we can figure out that '70' is in the current function no
mec> matter where its object code addresses are.

drow> No, we can't.  It's a pretty fundamental rule that we can never do
drow> anything except display source lines.  Consider code re-organization,
drow> templates, macros, #line directives...

Okay, I am naive here.  I see a DW_TAG_subprogram for each function
with a DW_AT_decl_line.  Can't we use that information to build a table
that maps source line #'s to function names?

But you know much more about this area then I do so if you are gloomy,
I have to be gloomy, too.

Michael C

Re: [RFA/PATCH] breakpoint.c: fix until command

[Daniel Jacobowitz]

On Fri, Jan 03, 2003 at 10:38:25AM -0600, Michael Elizabeth Chastain wrote:
> Hi Daniel,
> 
> mec> So we might need additional promises.
> mec> I think it would be reasonable for us to ask for them if we decide
> mec> we need them.
> 
> drow> I don't.  Promises don't mean anything; we have existing code.
> 
> A promise in a manual is a contract.  If gcc violates its contract,
> then gcc is at fault, and we can file bug reports against it.  That's
> what I'm getting at.

We support other compilers; we support other versions of GCC.  The life
of a debugger is that making people fix the compiler isn't going to
fly.

> mec> If we are in foo:67, and the user asks to 'until 70',
> mec> then I bet we can figure out that '70' is in the current function no
> mec> matter where its object code addresses are.
> 
> drow> No, we can't.  It's a pretty fundamental rule that we can never do
> drow> anything except display source lines.  Consider code re-organization,
> drow> templates, macros, #line directives...
> 
> Okay, I am naive here.  I see a DW_TAG_subprogram for each function
> with a DW_AT_decl_line.  Can't we use that information to build a table
> that maps source line #'s to function names?
> 
> But you know much more about this area then I do so if you are gloomy,
> I have to be gloomy, too.

No.  Here's the problem: generally, a code address maps to one
file:line pair.  Generally.  It's not always clear what file:line it
is, and sometimes it could reasonably map to multiple file:line's; for
instance, common subexpression hoisting.  But generally, we can go from
PC to file:line.

Right now we have code to go from file:line to PC.  However, assuming
that you can do that is wrong.  Consider:

inline int baz()
{
  return something
     -complicated;
}

int main()
{
  int a;
  a = baz();
  return a * baz();
}

We're on the "return something" line.  For the purposes of "until", if
someone said we could go to the "-complicated" line, it's obvious what
we mean; this inline instance.  In general, that's not true.  From the
linespec we have no way to figure out which inline instance is referred
to.  We lose.

[Similarly, we need to stop assuming a symbol name maps to one PC. 
This causes us to mess up constructor breakpoints right now.  GDB has
essentially no support for debugging inline functions, and it's a
problem there too.  DWARF-2 tells us where every single inlined copy
is, but what do we do with that information?  More, how do we present
it to the user?  Big interface problems here.]


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/PATCH] breakpoint.c: fix until command

[Michael Elizabeth Chastain]

Daniel J says:

> With a modern compiler, "after $PC" is pretty much meaningless.  Not
> going to fly.  It could be re-ordered; there can be out-of-line code in
> separate sections.

I'm thinking of a famous promise in the gcc manual:

  Without `-O', the compiler's goal is to reduce the cost of
  compilation and to make debugging produce the expected results.
  Statements are independent: if you stop the program with a
  breakpoint between statements, you can then assign a new value to
  any variable or change the program counter to any other statement
  in the function and get exactly the results you would expect from
  the source code.

Statements which are independent can could be re-ordered, like moving
error-handling blocks far away to a different section of the address
space to improve cache locality.  So we might need additional promises.
I think it would be reasonable for us to ask for them if we decide
we need them.

With optimized code, I agree, gdb is just going to degrade, the way
it does now with stepping through for loops.

Unfortunately for us, the no-argument form of 'until' pretty much depends
on the "after" property.  Perhaps we could re-implement 'until' to set
a breakpoint on *every* source line after the current source line and
then get rid of the object code address comparison and the steppy
implementation.  That would take some work and doubtless have its own
issues.

> I don't see any reason for that to go to a single-steppy behavior
> however.

My primitive impulse is to have 'until' and 'until LOCATION' use the same
mechanism so that they will behave the same way in all the hard cases.

I admit, this is not a compelling reason, it just feels right to me.

> And what it means when LOCATION is not in function is not clear.
> The problem is, do we know well enough when LOCATION is or is not in
> FUNCTION to make any statements?

If we can get more promises from gcc, then we can know this is true
in un-optimized code.

We can also know whether LOCATION is in the function if we operate
on LOCATION while it is in source form before we translate to object
code location.  If we are in foo:67, and the user asks to 'until 70',
then I bet we can figure out that '70' is in the current function no
matter where its object code addresses are.

> The implicit breakpoint at the return is still somewhat useful, IMHO. 
> It's not quite the same; when you hit one of the breakpoints (or stop
> for some other reason), both vanish.  I don't think that's what tbreaks
> do.

And lo ... 'finish'.

This command has a non-intuitive name.  It is actually the same as
'continue' plus a momentary breakpoint on the return.  The momentary
breakpoint vanishes as soon as proceed() returns.

It looks perfectly okay to use 'finish' almost all the time, even if you
expect the momentary breakpoint not to be hit.  In fact, I'm personally
going to try debugging this way, because I've had too many Ellen Feiss
moments where the debugger didn't hit the breakpoint I thought it would
hit and then it went beep beep beep beep and ate all my stack frames
and the inferior was back in something useless like main().

(Just "define cont \n finish \n end" and try debugging for a while,
it's kind of nice to lose only one stack frame at a time!)

The current implementation of 'until LOCATION' looks close to 'tbreak
LOCATION; finish".  'until LOCATION' uses a momentary breakpoint on
'LOCATION' and 'tbreak LOCATION' (obviously) uses a tbreak.  But they
both set momentary breakpoints on the return.

> I'm still undecided about what to do if LOCATION is not in the
> function.  Maybe you're right and we should make this an error.  What
> if LOCATION is in the frame that called this one?

I still say, make it an error.  I like the idea that 'until' is all
about the current frame.

And it seems weird.  The user should know it's not in the current
frame when they type in in LOCATION.  And they know that 'until' rolls
right over function calls.  So the user knows that LOCATION is in a
calling frame.  This collides head on with the idea that 'until' has
a momentary breakpoint on the return location in the caller.  Try it.
It will always take the return-breakpoint.  It will never reach LOCATION.

So 'until LOCATION' behaves very similar to 'finish' and the user knows
this, so they should just type 'finish'.  If the user wants to hit the
return-breakpoint, they want 'finish'.  If they do not want the
return-breakpoint, they want 'tbreak/continue' (almost).  Either way,
'until LOCATION' is redundant with something else.

Also try 'until LOCATION' where LOCATION gets hit in an inner frame.
Right now it also behaves like a 'finish' because of the next-y behavior
of function calls .

So 'until LOCATION' is already practically useless if LOCATION is not
in the current frame, either way.

Michael C

Re: [RFA/PATCH] breakpoint.c: fix until command

[Daniel Jacobowitz]

On Fri, Jan 03, 2003 at 12:49:28AM -0600, Michael Elizabeth Chastain wrote:
> Daniel J says:
> 
> > With a modern compiler, "after $PC" is pretty much meaningless.  Not
> > going to fly.  It could be re-ordered; there can be out-of-line code in
> > separate sections.
> 
> I'm thinking of a famous promise in the gcc manual:
> 
>   Without `-O', the compiler's goal is to reduce the cost of
>   compilation and to make debugging produce the expected results.
>   Statements are independent: if you stop the program with a
>   breakpoint between statements, you can then assign a new value to
>   any variable or change the program counter to any other statement
>   in the function and get exactly the results you would expect from
>   the source code.
> 
> Statements which are independent can could be re-ordered, like moving
> error-handling blocks far away to a different section of the address
> space to improve cache locality.  So we might need additional promises.
> I think it would be reasonable for us to ask for them if we decide
> we need them.

I don't.  Promises don't mean anything; we have existing code.

> With optimized code, I agree, gdb is just going to degrade, the way
> it does now with stepping through for loops.

Which isn't OK.  We need to do something about this; it requires some
substantial planning but with DWARF-2 we really should have all the
information we need to do better.

> > And what it means when LOCATION is not in function is not clear.
> > The problem is, do we know well enough when LOCATION is or is not in
> > FUNCTION to make any statements?
> 
> If we can get more promises from gcc, then we can know this is true
> in un-optimized code.
> 
> We can also know whether LOCATION is in the function if we operate
> on LOCATION while it is in source form before we translate to object
> code location.  If we are in foo:67, and the user asks to 'until 70',
> then I bet we can figure out that '70' is in the current function no
> matter where its object code addresses are.

No, we can't.  It's a pretty fundamental rule that we can never do
anything except display source lines.  Consider code re-organization,
templates, macros, #line directives...

> > I'm still undecided about what to do if LOCATION is not in the
> > function.  Maybe you're right and we should make this an error.  What
> > if LOCATION is in the frame that called this one?
> 
> I still say, make it an error.  I like the idea that 'until' is all
> about the current frame.
> 
> And it seems weird.  The user should know it's not in the current
> frame when they type in in LOCATION.  And they know that 'until' rolls
> right over function calls.  So the user knows that LOCATION is in a
> calling frame.  This collides head on with the idea that 'until' has
> a momentary breakpoint on the return location in the caller.  Try it.
> It will always take the return-breakpoint.  It will never reach LOCATION.

Oh, you're right of course.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

[RFA/PATCH] breakpoint.c: fix until command

[Elena Zannoni]

This fixes the problem reported in:
http://sources.redhat.com/ml/gdb/2002-11/msg00144.html

testsuite patch coming

Elena

2002-12-20  Elena Zannoni  <ezannoni@redhat.com>

	Fix PR breakpoints/898.
	* breakpoint.c (until_break_command): Don't use selected_frame,
	but the null frame.

Index: breakpoint.c
===================================================================
RCS file: /cvs/uberbaum/gdb/breakpoint.c,v
retrieving revision 1.104
diff -u -p -r1.104 breakpoint.c
--- breakpoint.c	17 Dec 2002 17:27:44 -0000	1.104
+++ breakpoint.c	20 Dec 2002 18:06:27 -0000
@@ -5615,9 +5615,7 @@ until_break_command (char *arg, int from
 
   resolve_sal_pc (&sal);
 
-  breakpoint = 
-    set_momentary_breakpoint (sal,get_frame_id (deprecated_selected_frame),
-			      bp_until);
+  breakpoint = set_momentary_breakpoint (sal, null_frame_id, bp_until);
 
   if (!event_loop_p || !target_can_async_p ())
     old_chain = make_cleanup_delete_breakpoint (breakpoint);

Re: [RFA/PATCH] breakpoint.c: fix until command

[Michael Snyder]

Elena Zannoni wrote:
> 
> This fixes the problem reported in:
> http://sources.redhat.com/ml/gdb/2002-11/msg00144.html
> 
> testsuite patch coming

Elena, can you sum up in a sentence or two, what this change
is intended to do?

Thanks,
Michael



> 2002-12-20  Elena Zannoni  <ezannoni@redhat.com>
> 
>         Fix PR breakpoints/898.
>         * breakpoint.c (until_break_command): Don't use selected_frame,
>         but the null frame.
> 
> Index: breakpoint.c
> ===================================================================
> RCS file: /cvs/uberbaum/gdb/breakpoint.c,v
> retrieving revision 1.104
> diff -u -p -r1.104 breakpoint.c
> --- breakpoint.c        17 Dec 2002 17:27:44 -0000      1.104
> +++ breakpoint.c        20 Dec 2002 18:06:27 -0000
> @@ -5615,9 +5615,7 @@ until_break_command (char *arg, int from
> 
>    resolve_sal_pc (&sal);
> 
> -  breakpoint =
> -    set_momentary_breakpoint (sal,get_frame_id (deprecated_selected_frame),
> -                             bp_until);
> +  breakpoint = set_momentary_breakpoint (sal, null_frame_id, bp_until);
> 
>    if (!event_loop_p || !target_can_async_p ())
>      old_chain = make_cleanup_delete_breakpoint (breakpoint);

Re: [RFA/PATCH] breakpoint.c: fix until command

[Daniel Jacobowitz]

On Mon, Dec 23, 2002 at 03:53:22PM -0800, Michael Snyder wrote:
> Elena Zannoni wrote:
> > 
> > This fixes the problem reported in:
> > http://sources.redhat.com/ml/gdb/2002-11/msg00144.html
> > 
> > testsuite patch coming
> 
> Elena, can you sum up in a sentence or two, what this change
> is intended to do?

[Since I happen to be reading email right now, I'll do a sketchy
imitation.]

The problem is that we were marking the breakpoint on the
user-specified line with the current frame.  But when we hit that
breakpoint, if it's in a different function, it will have a different
frame.  Right now we see that the frames don't match and resume
executing.

Oops.


> 
> Thanks,
> Michael
> 
> 
> 
> > 2002-12-20  Elena Zannoni  <ezannoni@redhat.com>
> > 
> >         Fix PR breakpoints/898.
> >         * breakpoint.c (until_break_command): Don't use selected_frame,
> >         but the null frame.
> > 
> > Index: breakpoint.c
> > ===================================================================
> > RCS file: /cvs/uberbaum/gdb/breakpoint.c,v
> > retrieving revision 1.104
> > diff -u -p -r1.104 breakpoint.c
> > --- breakpoint.c        17 Dec 2002 17:27:44 -0000      1.104
> > +++ breakpoint.c        20 Dec 2002 18:06:27 -0000
> > @@ -5615,9 +5615,7 @@ until_break_command (char *arg, int from
> > 
> >    resolve_sal_pc (&sal);
> > 
> > -  breakpoint =
> > -    set_momentary_breakpoint (sal,get_frame_id (deprecated_selected_frame),
> > -                             bp_until);
> > +  breakpoint = set_momentary_breakpoint (sal, null_frame_id, bp_until);
> > 
> >    if (!event_loop_p || !target_can_async_p ())
> >      old_chain = make_cleanup_delete_breakpoint (breakpoint);
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/PATCH] breakpoint.c: fix until command

[Michael Snyder]

Daniel Jacobowitz wrote:
> 
> On Mon, Dec 23, 2002 at 03:53:22PM -0800, Michael Snyder wrote:
> > Elena Zannoni wrote:
> > >
> > > This fixes the problem reported in:
> > > http://sources.redhat.com/ml/gdb/2002-11/msg00144.html
> > >
> > > testsuite patch coming
> >
> > Elena, can you sum up in a sentence or two, what this change
> > is intended to do?
> 
> [Since I happen to be reading email right now, I'll do a sketchy
> imitation.]
> 
> The problem is that we were marking the breakpoint on the
> user-specified line with the current frame.  But when we hit that
> breakpoint, if it's in a different function, it will have a different
> frame.  Right now we see that the frames don't match and resume
> executing.
> 
> Oops.

OK, thanks.  But we _need_ to mark the breakpoint with the current
frame, because if the breakpoint is in the current frame, we don't
want to stop in an inner recursive call, ie. not until the current
frame hits the breakpoint.  

So this needs further consideration, and I don't think it can
be approved as is.

Michael

> >
> > > 2002-12-20  Elena Zannoni  <ezannoni@redhat.com>
> > >
> > >         Fix PR breakpoints/898.
> > >         * breakpoint.c (until_break_command): Don't use selected_frame,
> > >         but the null frame.
> > >
> > > Index: breakpoint.c
> > > ===================================================================
> > > RCS file: /cvs/uberbaum/gdb/breakpoint.c,v
> > > retrieving revision 1.104
> > > diff -u -p -r1.104 breakpoint.c
> > > --- breakpoint.c        17 Dec 2002 17:27:44 -0000      1.104
> > > +++ breakpoint.c        20 Dec 2002 18:06:27 -0000
> > > @@ -5615,9 +5615,7 @@ until_break_command (char *arg, int from
> > >
> > >    resolve_sal_pc (&sal);
> > >
> > > -  breakpoint =
> > > -    set_momentary_breakpoint (sal,get_frame_id (deprecated_selected_frame),
> > > -                             bp_until);
> > > +  breakpoint = set_momentary_breakpoint (sal, null_frame_id, bp_until);
> > >
> > >    if (!event_loop_p || !target_can_async_p ())
> > >      old_chain = make_cleanup_delete_breakpoint (breakpoint);
> >
> 
> --
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/PATCH] breakpoint.c: fix until command

[Daniel Jacobowitz]

On Mon, Dec 23, 2002 at 04:57:00PM -0800, Michael Snyder wrote:
> Daniel Jacobowitz wrote:
> > 
> > On Mon, Dec 23, 2002 at 03:53:22PM -0800, Michael Snyder wrote:
> > > Elena Zannoni wrote:
> > > >
> > > > This fixes the problem reported in:
> > > > http://sources.redhat.com/ml/gdb/2002-11/msg00144.html
> > > >
> > > > testsuite patch coming
> > >
> > > Elena, can you sum up in a sentence or two, what this change
> > > is intended to do?
> > 
> > [Since I happen to be reading email right now, I'll do a sketchy
> > imitation.]
> > 
> > The problem is that we were marking the breakpoint on the
> > user-specified line with the current frame.  But when we hit that
> > breakpoint, if it's in a different function, it will have a different
> > frame.  Right now we see that the frames don't match and resume
> > executing.
> > 
> > Oops.
> 
> OK, thanks.  But we _need_ to mark the breakpoint with the current
> frame, because if the breakpoint is in the current frame, we don't
> want to stop in an inner recursive call, ie. not until the current
> frame hits the breakpoint.  
> 
> So this needs further consideration, and I don't think it can
> be approved as is.

OK.  Is that really what you expect "until" to do, though?  I'd be
pretty surprised if an inner function call executed that line without
stopping.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/PATCH] breakpoint.c: fix until command

[Michael Snyder]

Daniel Jacobowitz wrote:
> 
> On Mon, Dec 23, 2002 at 04:57:00PM -0800, Michael Snyder wrote:
> > Daniel Jacobowitz wrote:
> > >
> > > On Mon, Dec 23, 2002 at 03:53:22PM -0800, Michael Snyder wrote:
> > > > Elena Zannoni wrote:
> > > > >
> > > > > This fixes the problem reported in:
> > > > > http://sources.redhat.com/ml/gdb/2002-11/msg00144.html
> > > > >
> > > > > testsuite patch coming
> > > >
> > > > Elena, can you sum up in a sentence or two, what this change
> > > > is intended to do?
> > >
> > > [Since I happen to be reading email right now, I'll do a sketchy
> > > imitation.]
> > >
> > > The problem is that we were marking the breakpoint on the
> > > user-specified line with the current frame.  But when we hit that
> > > breakpoint, if it's in a different function, it will have a different
> > > frame.  Right now we see that the frames don't match and resume
> > > executing.
> > >
> > > Oops.
> >
> > OK, thanks.  But we _need_ to mark the breakpoint with the current
> > frame, because if the breakpoint is in the current frame, we don't
> > want to stop in an inner recursive call, ie. not until the current
> > frame hits the breakpoint.
> >
> > So this needs further consideration, and I don't think it can
> > be approved as is.
> 
> OK.  Is that really what you expect "until" to do, though?  I'd be
> pretty surprised if an inner function call executed that line without
> stopping.

Nevertheless, that is and has always been the intent.
If you're in factorial(5), and you say "until 100", 
you don't stop until line 100 is hit by factorial(5).

Re: [RFA/PATCH] breakpoint.c: fix until command

[Elena Zannoni]

Michael Snyder writes:
 > Daniel Jacobowitz wrote:
 > > 
 > > On Mon, Dec 23, 2002 at 04:57:00PM -0800, Michael Snyder wrote:
 > > > Daniel Jacobowitz wrote:
 > > > >
 > > > > On Mon, Dec 23, 2002 at 03:53:22PM -0800, Michael Snyder wrote:
 > > > > > Elena Zannoni wrote:
 > > > > > >
 > > > > > > This fixes the problem reported in:
 > > > > > > http://sources.redhat.com/ml/gdb/2002-11/msg00144.html
 > > > > > >
 > > > > > > testsuite patch coming
 > > > > >
 > > > > > Elena, can you sum up in a sentence or two, what this change
 > > > > > is intended to do?
 > > > >
 > > > > [Since I happen to be reading email right now, I'll do a sketchy
 > > > > imitation.]
 > > > >
 > > > > The problem is that we were marking the breakpoint on the
 > > > > user-specified line with the current frame.  But when we hit that
 > > > > breakpoint, if it's in a different function, it will have a different
 > > > > frame.  Right now we see that the frames don't match and resume
 > > > > executing.
 > > > >
 > > > > Oops.
 > > >
 > > > OK, thanks.  But we _need_ to mark the breakpoint with the current
 > > > frame, because if the breakpoint is in the current frame, we don't
 > > > want to stop in an inner recursive call, ie. not until the current
 > > > frame hits the breakpoint.
 > > >
 > > > So this needs further consideration, and I don't think it can
 > > > be approved as is.
 > > 
 > > OK.  Is that really what you expect "until" to do, though?  I'd be
 > > pretty surprised if an inner function call executed that line without
 > > stopping.
 > 
 > Nevertheless, that is and has always been the intent.
 > If you're in factorial(5), and you say "until 100", 
 > you don't stop until line 100 is hit by factorial(5).


I am tracking down this to something that changed between (ahem...)
4.18 and 5.0. The code in breakpoint.c didn't change. Right now,
stepping the two gdb's side to side, I can see a difference in
get_prev_frame, because of a different value returned by
FRAME_CHAIN_VALID. :-( (i have not still stepped past that to see how
that could influence the until foo behavior, maybe it doesn't).

The behavior you specify above is in 5.0 and not in 4.18, while the
'until foo' works in 4.18 and is broken in 5.0.

More digging.

Elena

Re: [RFA/PATCH] breakpoint.c: fix until command

[Michael Snyder]

Elena Zannoni wrote:
> 
> Michael Snyder writes:
>  > Daniel Jacobowitz wrote:
>  > >
>  > > On Mon, Dec 23, 2002 at 04:57:00PM -0800, Michael Snyder wrote:
>  > > > Daniel Jacobowitz wrote:
>  > > > >
>  > > > > On Mon, Dec 23, 2002 at 03:53:22PM -0800, Michael Snyder wrote:
>  > > > > > Elena Zannoni wrote:
>  > > > > > >
>  > > > > > > This fixes the problem reported in:
>  > > > > > > http://sources.redhat.com/ml/gdb/2002-11/msg00144.html
>  > > > > > >
>  > > > > > > testsuite patch coming
>  > > > > >
>  > > > > > Elena, can you sum up in a sentence or two, what this change
>  > > > > > is intended to do?
>  > > > >
>  > > > > [Since I happen to be reading email right now, I'll do a sketchy
>  > > > > imitation.]
>  > > > >
>  > > > > The problem is that we were marking the breakpoint on the
>  > > > > user-specified line with the current frame.  But when we hit that
>  > > > > breakpoint, if it's in a different function, it will have a different
>  > > > > frame.  Right now we see that the frames don't match and resume
>  > > > > executing.
>  > > > >
>  > > > > Oops.
>  > > >
>  > > > OK, thanks.  But we _need_ to mark the breakpoint with the current
>  > > > frame, because if the breakpoint is in the current frame, we don't
>  > > > want to stop in an inner recursive call, ie. not until the current
>  > > > frame hits the breakpoint.
>  > > >
>  > > > So this needs further consideration, and I don't think it can
>  > > > be approved as is.
>  > >
>  > > OK.  Is that really what you expect "until" to do, though?  I'd be
>  > > pretty surprised if an inner function call executed that line without
>  > > stopping.
>  >
>  > Nevertheless, that is and has always been the intent.
>  > If you're in factorial(5), and you say "until 100",
>  > you don't stop until line 100 is hit by factorial(5).
> 
> I am tracking down this to something that changed between (ahem...)
> 4.18 and 5.0. The code in breakpoint.c didn't change. Right now,
> stepping the two gdb's side to side, I can see a difference in
> get_prev_frame, because of a different value returned by
> FRAME_CHAIN_VALID. :-( (i have not still stepped past that to see how
> that could influence the until foo behavior, maybe it doesn't).
> 
> The behavior you specify above is in 5.0 and not in 4.18, while the
> 'until foo' works in 4.18 and is broken in 5.0.
> 
> More digging.

Heh.  Clearly we need more "until" tests.   ;-/

Re: [RFA/PATCH] breakpoint.c: fix until command

[Elena Zannoni]

Elena Zannoni writes:
>  > Nevertheless, that is and has always been the intent.
 >  > If you're in factorial(5), and you say "until 100", 
 >  > you don't stop until line 100 is hit by factorial(5).
 > 
 > 
 > I am tracking down this to something that changed between (ahem...)
 > 4.18 and 5.0. The code in breakpoint.c didn't change. Right now,
 > stepping the two gdb's side to side, I can see a difference in
 > get_prev_frame, because of a different value returned by
 > FRAME_CHAIN_VALID. :-( (i have not still stepped past that to see how
 > that could influence the until foo behavior, maybe it doesn't).
 > 
 > The behavior you specify above is in 5.0 and not in 4.18, while the
 > 'until foo' works in 4.18 and is broken in 5.0.
 > 
 > More digging.
 > 
 > Elena


OK. The reason for which 'until foo' worked at all in 4.18 is totally
fortuitous.  It is because of this patch in breakpoint.c:

1998-09-08  Jason Molenda  (jsm@bugshack.cygnus.com)

	* breakpoint.c (bpstat_stop_status):  Declare a bp match if the
	current fp matches the bp->fp OR if the current fp is less than
	the bp->fp if we're looking at a bp_step_resume breakpoint.

Index: breakpoint.c
===================================================================
RCS file: /cvs/cvsfiles/src/gdb/breakpoint.c,v
retrieving revision 1.190
retrieving revision 1.191
diff -u -p -p -r1.190 -r1.191
--- breakpoint.c	1998/07/17 15:29:10	1.190
+++ breakpoint.c	1998/09/09 04:16:57	1.191
@@ -1506,7 +1506,9 @@ bpstat_stop_status (pc, not_a_breakpoint
       else if (DECR_PC_AFTER_BREAK != 0 || must_shift_inst_regs)
 	real_breakpoint = 1;
 
-      if (b->frame && b->frame != (get_current_frame ())->frame)
+      if (b->frame && b->frame != (get_current_frame ())->frame &&
+          (b->type == bp_step_resume && 
+           (get_current_frame ())->frame INNER_THAN b->frame))
 	bs->stop = 0;
       else
 	{



Note that this added condition is always false for a bp_until type
breakpoint.  So, effectively we were invalidating the check of the
current frame vs. bp->frame. And we always stopped.

However, since we were not checking the frames, the case Michael wants
didn't work.

The patch above was reverted in 1999:

1999-08-13  Jim Kingdon  <http://developer.redhat.com/>

        * breakpoint.c (bpstat_stop_status): Revert 1998-09-08 change
        to ->frame matching.  The change did not match the ChangeLog
        entry, looked fishy, and caused infinite stepping when running
        "next" from main on sparc w/ RH Linux.  Thanks to Jakub for the
	report.

the effect was that the frame matching check was re-enabled, and so
'until foo' stopped working.

I don't think there is a way to have both behaviors work correctly.  I
thought of checking that the pc which you want to run until is in
the same function as the one of the selected frame, and in that case
enforce the check (by using a non-null frame for the bp_until),
otherwise use the null frame (which disables the check). But what would
be the correct behavior if you say:

"until bar" where bar is recursive, and you are in "bar" at the
moment?  This doesn't work currently. It seems intuitive that you
would stop the next time you enter "bar". Right now you end up at the
caller of "bar". 

I think it is a matter of deciding which behavior is more useful.

(note that I tried to revert Jason's patch in stock 4.18 and 'until
foo' stopped working, i.e. it wasn't something else that broke between
4.18 and 5.0)


Elena

Re: [RFA/PATCH] breakpoint.c: fix until command

[Michael Snyder]

Elena Zannoni wrote:
> 
> Elena Zannoni writes:
> >  > Nevertheless, that is and has always been the intent.
>  >  > If you're in factorial(5), and you say "until 100",
>  >  > you don't stop until line 100 is hit by factorial(5).
>  >
>  >
>  > I am tracking down this to something that changed between (ahem...)
>  > 4.18 and 5.0. The code in breakpoint.c didn't change. Right now,
>  > stepping the two gdb's side to side, I can see a difference in
>  > get_prev_frame, because of a different value returned by
>  > FRAME_CHAIN_VALID. :-( (i have not still stepped past that to see how
>  > that could influence the until foo behavior, maybe it doesn't).
>  >
>  > The behavior you specify above is in 5.0 and not in 4.18, while the
>  > 'until foo' works in 4.18 and is broken in 5.0.
>  >
>  > More digging.
>  >
>  > Elena
> 
> OK. The reason for which 'until foo' worked at all in 4.18 is totally
> fortuitous.  It is because of this patch in breakpoint.c:
> 
> 1998-09-08  Jason Molenda  (jsm@bugshack.cygnus.com)
> 
>         * breakpoint.c (bpstat_stop_status):  Declare a bp match if the
>         current fp matches the bp->fp OR if the current fp is less than
>         the bp->fp if we're looking at a bp_step_resume breakpoint.
> 
> Index: breakpoint.c
> ===================================================================
> RCS file: /cvs/cvsfiles/src/gdb/breakpoint.c,v
> retrieving revision 1.190
> retrieving revision 1.191
> diff -u -p -p -r1.190 -r1.191
> --- breakpoint.c        1998/07/17 15:29:10     1.190
> +++ breakpoint.c        1998/09/09 04:16:57     1.191
> @@ -1506,7 +1506,9 @@ bpstat_stop_status (pc, not_a_breakpoint
>        else if (DECR_PC_AFTER_BREAK != 0 || must_shift_inst_regs)
>         real_breakpoint = 1;
> 
> -      if (b->frame && b->frame != (get_current_frame ())->frame)
> +      if (b->frame && b->frame != (get_current_frame ())->frame &&
> +          (b->type == bp_step_resume &&
> +           (get_current_frame ())->frame INNER_THAN b->frame))
>         bs->stop = 0;
>        else
>         {
> 
> Note that this added condition is always false for a bp_until type
> breakpoint.  So, effectively we were invalidating the check of the
> current frame vs. bp->frame. And we always stopped.
> 
> However, since we were not checking the frames, the case Michael wants
> didn't work.
> 
> The patch above was reverted in 1999:
> 
> 1999-08-13  Jim Kingdon  <http://developer.redhat.com/>
> 
>         * breakpoint.c (bpstat_stop_status): Revert 1998-09-08 change
>         to ->frame matching.  The change did not match the ChangeLog
>         entry, looked fishy, and caused infinite stepping when running
>         "next" from main on sparc w/ RH Linux.  Thanks to Jakub for the
>         report.
> 
> the effect was that the frame matching check was re-enabled, and so
> 'until foo' stopped working.
> 
> I don't think there is a way to have both behaviors work correctly.  I
> thought of checking that the pc which you want to run until is in
> the same function as the one of the selected frame, and in that case
> enforce the check (by using a non-null frame for the bp_until),
> otherwise use the null frame (which disables the check). But what would
> be the correct behavior if you say:
> 
> "until bar" where bar is recursive, and you are in "bar" at the
> moment?  This doesn't work currently. It seems intuitive that you
> would stop the next time you enter "bar". Right now you end up at the
> caller of "bar".
> 
> I think it is a matter of deciding which behavior is more useful.
> 
> (note that I tried to revert Jason's patch in stock 4.18 and 'until
> foo' stopped working, i.e. it wasn't something else that broke between
> 4.18 and 5.0)

You raise a good point.  The commands "until <line>" and "until <func>"
are inconsistant.  Moreover the docs do not seem to describe this
recursion behavior.  Maybe a conversation with a wider audience is
in order (the gdb list)?  I'm sure I can't be the only one who 
remembers that "until" behaved this way, and we shouldn't change
the behavior precipitously.

Re: [RFA/PATCH] breakpoint.c: fix until command

[Daniel Jacobowitz]

On Thu, Jan 02, 2003 at 05:44:42PM -0800, Michael Snyder wrote:
> Elena Zannoni wrote:
> > 
> > Elena Zannoni writes:
> > >  > Nevertheless, that is and has always been the intent.
> >  >  > If you're in factorial(5), and you say "until 100",
> >  >  > you don't stop until line 100 is hit by factorial(5).
> >  >
> >  >
> >  > I am tracking down this to something that changed between (ahem...)
> >  > 4.18 and 5.0. The code in breakpoint.c didn't change. Right now,
> >  > stepping the two gdb's side to side, I can see a difference in
> >  > get_prev_frame, because of a different value returned by
> >  > FRAME_CHAIN_VALID. :-( (i have not still stepped past that to see how
> >  > that could influence the until foo behavior, maybe it doesn't).
> >  >
> >  > The behavior you specify above is in 5.0 and not in 4.18, while the
> >  > 'until foo' works in 4.18 and is broken in 5.0.
> >  >
> >  > More digging.
> >  >
> >  > Elena
> > 
> > OK. The reason for which 'until foo' worked at all in 4.18 is totally
> > fortuitous.  It is because of this patch in breakpoint.c:
> > 
> > 1998-09-08  Jason Molenda  (jsm@bugshack.cygnus.com)
> > 
> >         * breakpoint.c (bpstat_stop_status):  Declare a bp match if the
> >         current fp matches the bp->fp OR if the current fp is less than
> >         the bp->fp if we're looking at a bp_step_resume breakpoint.
> > 
> > Index: breakpoint.c
> > ===================================================================
> > RCS file: /cvs/cvsfiles/src/gdb/breakpoint.c,v
> > retrieving revision 1.190
> > retrieving revision 1.191
> > diff -u -p -p -r1.190 -r1.191
> > --- breakpoint.c        1998/07/17 15:29:10     1.190
> > +++ breakpoint.c        1998/09/09 04:16:57     1.191
> > @@ -1506,7 +1506,9 @@ bpstat_stop_status (pc, not_a_breakpoint
> >        else if (DECR_PC_AFTER_BREAK != 0 || must_shift_inst_regs)
> >         real_breakpoint = 1;
> > 
> > -      if (b->frame && b->frame != (get_current_frame ())->frame)
> > +      if (b->frame && b->frame != (get_current_frame ())->frame &&
> > +          (b->type == bp_step_resume &&
> > +           (get_current_frame ())->frame INNER_THAN b->frame))
> >         bs->stop = 0;
> >        else
> >         {
> > 
> > Note that this added condition is always false for a bp_until type
> > breakpoint.  So, effectively we were invalidating the check of the
> > current frame vs. bp->frame. And we always stopped.
> > 
> > However, since we were not checking the frames, the case Michael wants
> > didn't work.
> > 
> > The patch above was reverted in 1999:
> > 
> > 1999-08-13  Jim Kingdon  <http://developer.redhat.com/>
> > 
> >         * breakpoint.c (bpstat_stop_status): Revert 1998-09-08 change
> >         to ->frame matching.  The change did not match the ChangeLog
> >         entry, looked fishy, and caused infinite stepping when running
> >         "next" from main on sparc w/ RH Linux.  Thanks to Jakub for the
> >         report.
> > 
> > the effect was that the frame matching check was re-enabled, and so
> > 'until foo' stopped working.
> > 
> > I don't think there is a way to have both behaviors work correctly.  I
> > thought of checking that the pc which you want to run until is in
> > the same function as the one of the selected frame, and in that case
> > enforce the check (by using a non-null frame for the bp_until),
> > otherwise use the null frame (which disables the check). But what would
> > be the correct behavior if you say:
> > 
> > "until bar" where bar is recursive, and you are in "bar" at the
> > moment?  This doesn't work currently. It seems intuitive that you
> > would stop the next time you enter "bar". Right now you end up at the
> > caller of "bar".
> > 
> > I think it is a matter of deciding which behavior is more useful.
> > 
> > (note that I tried to revert Jason's patch in stock 4.18 and 'until
> > foo' stopped working, i.e. it wasn't something else that broke between
> > 4.18 and 5.0)
> 
> You raise a good point.  The commands "until <line>" and "until <func>"
> are inconsistant.  Moreover the docs do not seem to describe this
> recursion behavior.  Maybe a conversation with a wider audience is
> in order (the gdb list)?  I'm sure I can't be the only one who 
> remembers that "until" behaved this way, and we shouldn't change
> the behavior precipitously.

Am I the only one getting the feeling that we have two useful behaviors
here; and that we should pick one for "until" but expose the other
under some other name or with some option?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/PATCH] breakpoint.c: fix until command

[Michael Snyder]

Daniel Jacobowitz wrote:
> 
> On Thu, Jan 02, 2003 at 05:44:42PM -0800, Michael Snyder wrote:
> > Elena Zannoni wrote:
> > >
> > > Elena Zannoni writes:
> > > >  > Nevertheless, that is and has always been the intent.
> > >  >  > If you're in factorial(5), and you say "until 100",
> > >  >  > you don't stop until line 100 is hit by factorial(5).
> > >  >
> > >  >
> > >  > I am tracking down this to something that changed between (ahem...)
> > >  > 4.18 and 5.0. The code in breakpoint.c didn't change. Right now,
> > >  > stepping the two gdb's side to side, I can see a difference in
> > >  > get_prev_frame, because of a different value returned by
> > >  > FRAME_CHAIN_VALID. :-( (i have not still stepped past that to see how
> > >  > that could influence the until foo behavior, maybe it doesn't).
> > >  >
> > >  > The behavior you specify above is in 5.0 and not in 4.18, while the
> > >  > 'until foo' works in 4.18 and is broken in 5.0.
> > >  >
> > >  > More digging.
> > >  >
> > >  > Elena
> > >
> > > OK. The reason for which 'until foo' worked at all in 4.18 is totally
> > > fortuitous.  It is because of this patch in breakpoint.c:
> > >
> > > 1998-09-08  Jason Molenda  (jsm@bugshack.cygnus.com)
> > >
> > >         * breakpoint.c (bpstat_stop_status):  Declare a bp match if the
> > >         current fp matches the bp->fp OR if the current fp is less than
> > >         the bp->fp if we're looking at a bp_step_resume breakpoint.
> > >
> > > Index: breakpoint.c
> > > ===================================================================
> > > RCS file: /cvs/cvsfiles/src/gdb/breakpoint.c,v
> > > retrieving revision 1.190
> > > retrieving revision 1.191
> > > diff -u -p -p -r1.190 -r1.191
> > > --- breakpoint.c        1998/07/17 15:29:10     1.190
> > > +++ breakpoint.c        1998/09/09 04:16:57     1.191
> > > @@ -1506,7 +1506,9 @@ bpstat_stop_status (pc, not_a_breakpoint
> > >        else if (DECR_PC_AFTER_BREAK != 0 || must_shift_inst_regs)
> > >         real_breakpoint = 1;
> > >
> > > -      if (b->frame && b->frame != (get_current_frame ())->frame)
> > > +      if (b->frame && b->frame != (get_current_frame ())->frame &&
> > > +          (b->type == bp_step_resume &&
> > > +           (get_current_frame ())->frame INNER_THAN b->frame))
> > >         bs->stop = 0;
> > >        else
> > >         {
> > >
> > > Note that this added condition is always false for a bp_until type
> > > breakpoint.  So, effectively we were invalidating the check of the
> > > current frame vs. bp->frame. And we always stopped.
> > >
> > > However, since we were not checking the frames, the case Michael wants
> > > didn't work.
> > >
> > > The patch above was reverted in 1999:
> > >
> > > 1999-08-13  Jim Kingdon  <http://developer.redhat.com/>
> > >
> > >         * breakpoint.c (bpstat_stop_status): Revert 1998-09-08 change
> > >         to ->frame matching.  The change did not match the ChangeLog
> > >         entry, looked fishy, and caused infinite stepping when running
> > >         "next" from main on sparc w/ RH Linux.  Thanks to Jakub for the
> > >         report.
> > >
> > > the effect was that the frame matching check was re-enabled, and so
> > > 'until foo' stopped working.
> > >
> > > I don't think there is a way to have both behaviors work correctly.  I
> > > thought of checking that the pc which you want to run until is in
> > > the same function as the one of the selected frame, and in that case
> > > enforce the check (by using a non-null frame for the bp_until),
> > > otherwise use the null frame (which disables the check). But what would
> > > be the correct behavior if you say:
> > >
> > > "until bar" where bar is recursive, and you are in "bar" at the
> > > moment?  This doesn't work currently. It seems intuitive that you
> > > would stop the next time you enter "bar". Right now you end up at the
> > > caller of "bar".
> > >
> > > I think it is a matter of deciding which behavior is more useful.
> > >
> > > (note that I tried to revert Jason's patch in stock 4.18 and 'until
> > > foo' stopped working, i.e. it wasn't something else that broke between
> > > 4.18 and 5.0)
> >
> > You raise a good point.  The commands "until <line>" and "until <func>"
> > are inconsistant.  Moreover the docs do not seem to describe this
> > recursion behavior.  Maybe a conversation with a wider audience is
> > in order (the gdb list)?  I'm sure I can't be the only one who
> > remembers that "until" behaved this way, and we shouldn't change
> > the behavior precipitously.
> 
> Am I the only one getting the feeling that we have two useful behaviors
> here; and that we should pick one for "until" but expose the other
> under some other name or with some option?

;-)  That's often the case when someone feels 'intuitively' that 
gdb should behave differently.  We have to look out for feeping
creaturitis, but in this case I'm getting the impression that the
two behaviors are mutually incompatible, and may need to be separated
somehow.

If you say "until <line>", and the line is inside the current function,
you can impose the frame restriction.  If the line (or address) is outside 
the current function, or if you give a function name or something else, 
you can't.  And I don't think we can code that distinction at runtime.

Re: [RFA/PATCH] breakpoint.c: fix until command

[Elena Zannoni]

Michael Snyder writes:
 > > > You raise a good point.  The commands "until <line>" and "until <func>"
 > > > are inconsistant.  Moreover the docs do not seem to describe this
 > > > recursion behavior.  Maybe a conversation with a wider audience is
 > > > in order (the gdb list)?  I'm sure I can't be the only one who
 > > > remembers that "until" behaved this way, and we shouldn't change
 > > > the behavior precipitously.
 > > 
 > > Am I the only one getting the feeling that we have two useful behaviors
 > > here; and that we should pick one for "until" but expose the other
 > > under some other name or with some option?
 > 
 > ;-)  That's often the case when someone feels 'intuitively' that 
 > gdb should behave differently.  We have to look out for feeping
 > creaturitis, but in this case I'm getting the impression that the
 > two behaviors are mutually incompatible, and may need to be separated
 > somehow.
 > 
 > If you say "until <line>", and the line is inside the current function,
 > you can impose the frame restriction.  If the line (or address) is outside 
 > the current function, or if you give a function name or something else, 
 > you can't.  And I don't think we can code that distinction at runtime.

I think we should come up with a behavior matrix, something like:

until: 
 continue until next source line is reached. If already at the last line
 of current function, continue until current frame pops.

until line:
 a. line in current function (1) --> continue until the line is reached.
 b. line in function in inner frame --> continue until the line is reached.
 c. line in function not in inner frame --> continue until current frame pops.

(1) However if current function is recursive, a. should become like
    b. But we want to enforce a different behavior, because we don't
    want to stop in the inner frame. --> this is the main problem,
    because the condition is basically impossible to figure out at run
    time.

until funcname:
 d. funcname called from current frame (2) --> continue until func is reached
 e. funcname not called from current frame --> cont until current frame pops.

(2) if current function is recursive and funcame == current function
    we want to stop at the next inner invocation of funcname


The 'continue until current frame pops' behavior is already there. It
always puts another bp_until at the caller.

Re: [RFA/PATCH] breakpoint.c: fix until command

[Michael Snyder]

Elena Zannoni wrote:
> 
> Michael Snyder writes:

>  > If you say "until <line>", and the line is inside the current function,
>  > you can impose the frame restriction.  If the line (or address) is outside
>  > the current function, or if you give a function name or something else,
>  > you can't.  And I don't think we can code that distinction at runtime.
> 
> I think we should come up with a behavior matrix, something like:
> 
> until:
>  continue until next source line is reached. If already at the last line
>  of current function, continue until current frame pops.
> 
> until line:
>  a. line in current function (1) --> continue until the line is reached.

Agreed, with the qualification given.

>  b. line in function in inner frame --> continue until the line is reached.

Agreed.

>  c. line in function not in inner frame --> continue until current frame pops.

Agreed.

> (1) However if current function is recursive, a. should become like
>     b. But we want to enforce a different behavior, because we don't
>     want to stop in the inner frame. 

I think this could be stated simply as "continue until the line 
is reached by the current execution frame".

> --> this is the main problem,
>     because the condition is basically impossible to figure out at run
>     time.

If we can figure it out at runtime, you would agree to it?

> until funcname:
>  d. funcname called from current frame (2) --> continue until func is reached

Agreed.

>  e. funcname not called from current frame --> cont until current frame pops.

Agreed.

> (2) if current function is recursive and funcame == current function
>     we want to stop at the next inner invocation of funcname

Ow, not obvious.  But since it clearly isn't specified now, 
I suppose we could make up such a stipulation if we choose to.
I don't even know what the traditional behavior would be in
this case.


> The 'continue until current frame pops' behavior is already there. It
> always puts another bp_until at the caller.

Yep.

So AFAICT, we have only one corner case to agree upon.
"until factorial".

Re: [RFA/PATCH] breakpoint.c: fix until command

[Elena Zannoni]

Michael Snyder writes:
 > Elena Zannoni wrote:
 > > 
 > > Michael Snyder writes:
 > 
 > >  > If you say "until <line>", and the line is inside the current function,
 > >  > you can impose the frame restriction.  If the line (or address) is outside
 > >  > the current function, or if you give a function name or something else,
 > >  > you can't.  And I don't think we can code that distinction at runtime.
 > > 
 > > I think we should come up with a behavior matrix, something like:
 > > 
 > > until:
 > >  continue until next source line is reached. If already at the last line
 > >  of current function, continue until current frame pops.
 > > 
 > > until line:
 > >  a. line in current function (1) --> continue until the line is reached.
 > 
 > Agreed, with the qualification given.
 > 
 > >  b. line in function in inner frame --> continue until the line is reached.
 > 
 > Agreed.
 > 
 > >  c. line in function not in inner frame --> continue until current frame pops.
 > 
 > Agreed.
 > 
 > > (1) However if current function is recursive, a. should become like
 > >     b. But we want to enforce a different behavior, because we don't
 > >     want to stop in the inner frame. 
 > 
 > I think this could be stated simply as "continue until the line 
 > is reached by the current execution frame".
 > 
 > > --> this is the main problem,
 > >     because the condition is basically impossible to figure out at run
 > >     time.
 > 
 > If we can figure it out at runtime, you would agree to it?
 > 
 > > until funcname:
 > >  d. funcname called from current frame (2) --> continue until func is reached
 > 
 > Agreed.
 > 
 > >  e. funcname not called from current frame --> cont until current frame pops.
 > 
 > Agreed.
 > 
 > > (2) if current function is recursive and funcame == current function
 > >     we want to stop at the next inner invocation of funcname
 > 
 > Ow, not obvious.  But since it clearly isn't specified now, 
 > I suppose we could make up such a stipulation if we choose to.
 > I don't even know what the traditional behavior would be in
 > this case.
 > 
 > 
 > > The 'continue until current frame pops' behavior is already there. It
 > > always puts another bp_until at the caller.
 > 
 > Yep.
 > 
 > So AFAICT, we have only one corner case to agree upon.
 > "until factorial".


yes yes yes!

(see my previous message).

Re: [RFA/PATCH] breakpoint.c: fix until command

[Michael Snyder]

Elena Zannoni wrote:
> 
> Michael Snyder writes:
>  > Elena Zannoni wrote:
>  > >
>  > > Michael Snyder writes:
>  >
>  > >  > If you say "until <line>", and the line is inside the current function,
>  > >  > you can impose the frame restriction.  If the line (or address) is outside
>  > >  > the current function, or if you give a function name or something else,
>  > >  > you can't.  And I don't think we can code that distinction at runtime.
>  > >
>  > > I think we should come up with a behavior matrix, something like:
>  > >
>  > > until:
>  > >  continue until next source line is reached. If already at the last line
>  > >  of current function, continue until current frame pops.
>  > >
>  > > until line:
>  > >  a. line in current function (1) --> continue until the line is reached.
>  >
>  > Agreed, with the qualification given.
>  >
>  > >  b. line in function in inner frame --> continue until the line is reached.
>  >
>  > Agreed.
>  >
>  > >  c. line in function not in inner frame --> continue until current frame pops.
>  >
>  > Agreed.
>  >
>  > > (1) However if current function is recursive, a. should become like
>  > >     b. But we want to enforce a different behavior, because we don't
>  > >     want to stop in the inner frame.
>  >
>  > I think this could be stated simply as "continue until the line
>  > is reached by the current execution frame".
>  >
>  > > --> this is the main problem,
>  > >     because the condition is basically impossible to figure out at run
>  > >     time.
>  >
>  > If we can figure it out at runtime, you would agree to it?
>  >
>  > > until funcname:
>  > >  d. funcname called from current frame (2) --> continue until func is reached
>  >
>  > Agreed.
>  >
>  > >  e. funcname not called from current frame --> cont until current frame pops.
>  >
>  > Agreed.
>  >
>  > > (2) if current function is recursive and funcame == current function
>  > >     we want to stop at the next inner invocation of funcname
>  >
>  > Ow, not obvious.  But since it clearly isn't specified now,
>  > I suppose we could make up such a stipulation if we choose to.
>  > I don't even know what the traditional behavior would be in
>  > this case.
>  >
>  >
>  > > The 'continue until current frame pops' behavior is already there. It
>  > > always puts another bp_until at the caller.
>  >
>  > Yep.
>  >
>  > So AFAICT, we have only one corner case to agree upon.
>  > "until factorial".
> 
> yes yes yes!

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?

Daniel?  Michael?

Anyone else?

Re: [RFA/PATCH] breakpoint.c: fix until command

[Daniel Jacobowitz]

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

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

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/PATCH] breakpoint.c: fix until command

[Elena Zannoni]

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.

 > 
 > > 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'? 
 

 > -- 
 > Daniel Jacobowitz
 > MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/PATCH] breakpoint.c: fix until command

[Michael Snyder]

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.

Re: [RFA/PATCH] breakpoint.c: fix until command

[Elena Zannoni]

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

Elena

Re: [RFA/PATCH] breakpoint.c: fix until command

[Michael Snyder]

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"?

Re: [RFA/PATCH] breakpoint.c: fix until command

[Daniel Jacobowitz]

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 <line>"
  "until-first <line>"
  "until -first <line>"
?

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

Re: [RFA/PATCH] breakpoint.c: fix until command

[Elena Zannoni]

Daniel Jacobowitz writes:
 > > >  > >  > 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 <line>"
 >   "until-first <line>"
 >   "until -first <line>"
 > ?
 > 
 > Me, I'm partial to the third form; then you can have:
 >   until -first func
 >   until -current func
 > 

I am not clear what first vs. current means. You mean first as 'first
time you cross' that given location? So you would drop the "called
from the current frame" restriction.

 > 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?  
 > 

I don't much like having options, it's too much to type. :-) I think
we should leave the until as it is, name and all. Or it will confuse
people even more.  I like 'to' as a possible simple name for the other
form.  Or 'through'.

Elena




 > Just a thought.
 > 
 > -- 
 > Daniel Jacobowitz
 > MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/PATCH] breakpoint.c: fix until command

[Daniel Jacobowitz]

On Wed, Jan 08, 2003 at 05:12:50PM -0500, Elena Zannoni wrote:
> Daniel Jacobowitz writes:
>  > > >  > >  > 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 <line>"
>  >   "until-first <line>"
>  >   "until -first <line>"
>  > ?
>  > 
>  > Me, I'm partial to the third form; then you can have:
>  >   until -first func
>  >   until -current func
>  > 
> 
> I am not clear what first vs. current means. You mean first as 'first
> time you cross' that given location? So you would drop the "called
> from the current frame" restriction.

Yeah, that was my basic idea.

>  > 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?  
>  > 
> 
> I don't much like having options, it's too much to type. :-) I think
> we should leave the until as it is, name and all. Or it will confuse
> people even more.  I like 'to' as a possible simple name for the other
> form.  Or 'through'.

The problem is, neither to or through makes sense to me as an option; I
can't figure out what it will do.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/PATCH] breakpoint.c: fix until command

[Elena Zannoni]

Daniel Jacobowitz writes:
 > On Wed, Jan 08, 2003 at 05:12:50PM -0500, Elena Zannoni wrote:
 > > Daniel Jacobowitz writes:
 > >  > > >  > >  > 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 <line>"
 > >  >   "until-first <line>"
 > >  >   "until -first <line>"
 > >  > ?
 > >  > 
 > >  > Me, I'm partial to the third form; then you can have:
 > >  >   until -first func
 > >  >   until -current func
 > >  > 
 > > 
 > > I am not clear what first vs. current means. You mean first as 'first
 > > time you cross' that given location? So you would drop the "called
 > > from the current frame" restriction.
 > 
 > Yeah, that was my basic idea.
 > 
 > >  > 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?  
 > >  > 
 > > 
 > > I don't much like having options, it's too much to type. :-) I think
 > > we should leave the until as it is, name and all. Or it will confuse
 > > people even more.  I like 'to' as a possible simple name for the other
 > > form.  Or 'through'.
 > 
 > The problem is, neither to or through makes sense to me as an option; I
 > can't figure out what it will do.
 > 

Not as an option, I was thinking as a separate command.
(to tell you the through, it should just be an argument to 'continue').

Elena

 > -- 
 > Daniel Jacobowitz
 > MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/PATCH] breakpoint.c: fix until command

[Daniel Jacobowitz]

On Fri, Jan 10, 2003 at 05:29:33PM -0500, Elena Zannoni wrote:
> Daniel Jacobowitz writes:
>  > On Wed, Jan 08, 2003 at 05:12:50PM -0500, Elena Zannoni wrote:
>  > > I don't much like having options, it's too much to type. :-) I think
>  > > we should leave the until as it is, name and all. Or it will confuse
>  > > people even more.  I like 'to' as a possible simple name for the other
>  > > form.  Or 'through'.
>  > 
>  > The problem is, neither to or through makes sense to me as an option; I
>  > can't figure out what it will do.
>  > 
> 
> Not as an option, I was thinking as a separate command.

Sorry, so was I.  I can't see what "to" would do, really.

> (to tell you the through, it should just be an argument to 'continue').

I suppose, but then we're back where we started.

continue
continue until foo
continue to 34

[still not clear what the difference there is.]

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/PATCH] breakpoint.c: fix until command

[Elena Zannoni]

Daniel Jacobowitz writes:
 > On Fri, Jan 10, 2003 at 05:29:33PM -0500, Elena Zannoni wrote:
 > > Daniel Jacobowitz writes:
 > >  > On Wed, Jan 08, 2003 at 05:12:50PM -0500, Elena Zannoni wrote:
 > >  > > I don't much like having options, it's too much to type. :-) I think
 > >  > > we should leave the until as it is, name and all. Or it will confuse
 > >  > > people even more.  I like 'to' as a possible simple name for the other
 > >  > > form.  Or 'through'.
 > >  > 
 > >  > The problem is, neither to or through makes sense to me as an option; I
 > >  > can't figure out what it will do.
 > >  > 
 > > 
 > > Not as an option, I was thinking as a separate command.
 > 
 > Sorry, so was I.  I can't see what "to" would do, really.
 > 
 > > (to tell you the through, it should just be an argument to 'continue').
 > 
 > I suppose, but then we're back where we started.
 > 
 > continue
 > continue until foo
 > continue to 34

No no, I meant 2 different commands, not options.
until <location> (with the current behavior)
to <location> (with the 'new' behavior)

or until <location>
   continue <location> (but unfortunately continue has already an argument)

Elena

 > 
 > [still not clear what the difference there is.]
 > 
 > -- 
 > Daniel Jacobowitz
 > MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/PATCH] breakpoint.c: fix until command

[Elena Zannoni]

Daniel Jacobowitz writes:
 > On Thu, Jan 02, 2003 at 05:44:42PM -0800, Michael Snyder wrote:
 > > Elena Zannoni wrote:
 > > > 
 > > > Elena Zannoni writes:
 > > > >  > Nevertheless, that is and has always been the intent.
 > > >  >  > If you're in factorial(5), and you say "until 100",
 > > >  >  > you don't stop until line 100 is hit by factorial(5).
 > > >  >
 > > >  >
 > > >  > I am tracking down this to something that changed between (ahem...)
 > > >  > 4.18 and 5.0. The code in breakpoint.c didn't change. Right now,
 > > >  > stepping the two gdb's side to side, I can see a difference in
 > > >  > get_prev_frame, because of a different value returned by
 > > >  > FRAME_CHAIN_VALID. :-( (i have not still stepped past that to see how
 > > >  > that could influence the until foo behavior, maybe it doesn't).
 > > >  >
 > > >  > The behavior you specify above is in 5.0 and not in 4.18, while the
 > > >  > 'until foo' works in 4.18 and is broken in 5.0.
 > > >  >
 > > >  > More digging.
 > > >  >
 > > >  > Elena
 > > > 
 > > > OK. The reason for which 'until foo' worked at all in 4.18 is totally
 > > > fortuitous.  It is because of this patch in breakpoint.c:
 > > > 
 > > > 1998-09-08  Jason Molenda  (jsm@bugshack.cygnus.com)
 > > > 
 > > >         * breakpoint.c (bpstat_stop_status):  Declare a bp match if the
 > > >         current fp matches the bp->fp OR if the current fp is less than
 > > >         the bp->fp if we're looking at a bp_step_resume breakpoint.
 > > > 
 > > > Index: breakpoint.c
 > > > ===================================================================
 > > > RCS file: /cvs/cvsfiles/src/gdb/breakpoint.c,v
 > > > retrieving revision 1.190
 > > > retrieving revision 1.191
 > > > diff -u -p -p -r1.190 -r1.191
 > > > --- breakpoint.c        1998/07/17 15:29:10     1.190
 > > > +++ breakpoint.c        1998/09/09 04:16:57     1.191
 > > > @@ -1506,7 +1506,9 @@ bpstat_stop_status (pc, not_a_breakpoint
 > > >        else if (DECR_PC_AFTER_BREAK != 0 || must_shift_inst_regs)
 > > >         real_breakpoint = 1;
 > > > 
 > > > -      if (b->frame && b->frame != (get_current_frame ())->frame)
 > > > +      if (b->frame && b->frame != (get_current_frame ())->frame &&
 > > > +          (b->type == bp_step_resume &&
 > > > +           (get_current_frame ())->frame INNER_THAN b->frame))
 > > >         bs->stop = 0;
 > > >        else
 > > >         {
 > > > 
 > > > Note that this added condition is always false for a bp_until type
 > > > breakpoint.  So, effectively we were invalidating the check of the
 > > > current frame vs. bp->frame. And we always stopped.
 > > > 
 > > > However, since we were not checking the frames, the case Michael wants
 > > > didn't work.
 > > > 
 > > > The patch above was reverted in 1999:
 > > > 
 > > > 1999-08-13  Jim Kingdon  <http://developer.redhat.com/>
 > > > 
 > > >         * breakpoint.c (bpstat_stop_status): Revert 1998-09-08 change
 > > >         to ->frame matching.  The change did not match the ChangeLog
 > > >         entry, looked fishy, and caused infinite stepping when running
 > > >         "next" from main on sparc w/ RH Linux.  Thanks to Jakub for the
 > > >         report.
 > > > 
 > > > the effect was that the frame matching check was re-enabled, and so
 > > > 'until foo' stopped working.
 > > > 
 > > > I don't think there is a way to have both behaviors work correctly.  I
 > > > thought of checking that the pc which you want to run until is in
 > > > the same function as the one of the selected frame, and in that case
 > > > enforce the check (by using a non-null frame for the bp_until),
 > > > otherwise use the null frame (which disables the check). But what would
 > > > be the correct behavior if you say:
 > > > 
 > > > "until bar" where bar is recursive, and you are in "bar" at the
 > > > moment?  This doesn't work currently. It seems intuitive that you
 > > > would stop the next time you enter "bar". Right now you end up at the
 > > > caller of "bar".
 > > > 
 > > > I think it is a matter of deciding which behavior is more useful.
 > > > 
 > > > (note that I tried to revert Jason's patch in stock 4.18 and 'until
 > > > foo' stopped working, i.e. it wasn't something else that broke between
 > > > 4.18 and 5.0)
 > > 
 > > You raise a good point.  The commands "until <line>" and "until <func>"
 > > are inconsistant.  Moreover the docs do not seem to describe this
 > > recursion behavior.  Maybe a conversation with a wider audience is
 > > in order (the gdb list)?  I'm sure I can't be the only one who 
 > > remembers that "until" behaved this way, and we shouldn't change
 > > the behavior precipitously.
 > 
 > Am I the only one getting the feeling that we have two useful behaviors
 > here; and that we should pick one for "until" but expose the other
 > under some other name or with some option?
 > 

yes, I don't think there is any way we can distinguish the recursive
function cases from the non recursive ones, and the 'line'
vs. 'funcname' argument.

Elena


 > -- 
 > Daniel Jacobowitz
 > MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/PATCH] breakpoint.c: fix until command

[Michael Snyder]

Elena Zannoni wrote:
> 
> Daniel Jacobowitz writes:
>  > On Thu, Jan 02, 2003 at 05:44:42PM -0800, Michael Snyder wrote:
>  > > Elena Zannoni wrote:
>  > > >
>  > > > Elena Zannoni writes:
>  > > > >  > Nevertheless, that is and has always been the intent.
>  > > >  >  > If you're in factorial(5), and you say "until 100",
>  > > >  >  > you don't stop until line 100 is hit by factorial(5).
>  > > >  >
>  > > >  >
>  > > >  > I am tracking down this to something that changed between (ahem...)
>  > > >  > 4.18 and 5.0. The code in breakpoint.c didn't change. Right now,
>  > > >  > stepping the two gdb's side to side, I can see a difference in
>  > > >  > get_prev_frame, because of a different value returned by
>  > > >  > FRAME_CHAIN_VALID. :-( (i have not still stepped past that to see how
>  > > >  > that could influence the until foo behavior, maybe it doesn't).
>  > > >  >
>  > > >  > The behavior you specify above is in 5.0 and not in 4.18, while the
>  > > >  > 'until foo' works in 4.18 and is broken in 5.0.
>  > > >  >
>  > > >  > More digging.
>  > > >  >
>  > > >  > Elena
>  > > >
>  > > > OK. The reason for which 'until foo' worked at all in 4.18 is totally
>  > > > fortuitous.  It is because of this patch in breakpoint.c:
>  > > >
>  > > > 1998-09-08  Jason Molenda  (jsm@bugshack.cygnus.com)
>  > > >
>  > > >         * breakpoint.c (bpstat_stop_status):  Declare a bp match if the
>  > > >         current fp matches the bp->fp OR if the current fp is less than
>  > > >         the bp->fp if we're looking at a bp_step_resume breakpoint.
>  > > >
>  > > > Index: breakpoint.c
>  > > > ===================================================================
>  > > > RCS file: /cvs/cvsfiles/src/gdb/breakpoint.c,v
>  > > > retrieving revision 1.190
>  > > > retrieving revision 1.191
>  > > > diff -u -p -p -r1.190 -r1.191
>  > > > --- breakpoint.c        1998/07/17 15:29:10     1.190
>  > > > +++ breakpoint.c        1998/09/09 04:16:57     1.191
>  > > > @@ -1506,7 +1506,9 @@ bpstat_stop_status (pc, not_a_breakpoint
>  > > >        else if (DECR_PC_AFTER_BREAK != 0 || must_shift_inst_regs)
>  > > >         real_breakpoint = 1;
>  > > >
>  > > > -      if (b->frame && b->frame != (get_current_frame ())->frame)
>  > > > +      if (b->frame && b->frame != (get_current_frame ())->frame &&
>  > > > +          (b->type == bp_step_resume &&
>  > > > +           (get_current_frame ())->frame INNER_THAN b->frame))
>  > > >         bs->stop = 0;
>  > > >        else
>  > > >         {
>  > > >
>  > > > Note that this added condition is always false for a bp_until type
>  > > > breakpoint.  So, effectively we were invalidating the check of the
>  > > > current frame vs. bp->frame. And we always stopped.
>  > > >
>  > > > However, since we were not checking the frames, the case Michael wants
>  > > > didn't work.
>  > > >
>  > > > The patch above was reverted in 1999:
>  > > >
>  > > > 1999-08-13  Jim Kingdon  <http://developer.redhat.com/>
>  > > >
>  > > >         * breakpoint.c (bpstat_stop_status): Revert 1998-09-08 change
>  > > >         to ->frame matching.  The change did not match the ChangeLog
>  > > >         entry, looked fishy, and caused infinite stepping when running
>  > > >         "next" from main on sparc w/ RH Linux.  Thanks to Jakub for the
>  > > >         report.
>  > > >
>  > > > the effect was that the frame matching check was re-enabled, and so
>  > > > 'until foo' stopped working.
>  > > >
>  > > > I don't think there is a way to have both behaviors work correctly.  I
>  > > > thought of checking that the pc which you want to run until is in
>  > > > the same function as the one of the selected frame, and in that case
>  > > > enforce the check (by using a non-null frame for the bp_until),
>  > > > otherwise use the null frame (which disables the check). But what would
>  > > > be the correct behavior if you say:
>  > > >
>  > > > "until bar" where bar is recursive, and you are in "bar" at the
>  > > > moment?  This doesn't work currently. It seems intuitive that you
>  > > > would stop the next time you enter "bar". Right now you end up at the
>  > > > caller of "bar".
>  > > >
>  > > > I think it is a matter of deciding which behavior is more useful.
>  > > >
>  > > > (note that I tried to revert Jason's patch in stock 4.18 and 'until
>  > > > foo' stopped working, i.e. it wasn't something else that broke between
>  > > > 4.18 and 5.0)
>  > >
>  > > You raise a good point.  The commands "until <line>" and "until <func>"
>  > > are inconsistant.  Moreover the docs do not seem to describe this
>  > > recursion behavior.  Maybe a conversation with a wider audience is
>  > > in order (the gdb list)?  I'm sure I can't be the only one who
>  > > remembers that "until" behaved this way, and we shouldn't change
>  > > the behavior precipitously.
>  >
>  > Am I the only one getting the feeling that we have two useful behaviors
>  > here; and that we should pick one for "until" but expose the other
>  > under some other name or with some option?
>  >
> 
> yes, I don't think there is any way we can distinguish the recursive
> function cases from the non recursive ones, and the 'line'
> vs. 'funcname' argument.

I agree, but maybe we can distinguish between "a location inside the
current function" and "a location outside the current function".
After all, a line is not a meaningful distinction -- it could be a
line inside another function.

So I suggest using find_pc_partial_function to find the bounds
of the current function.  If <location> is inside, we use a 
frame-relative breakpoint.  If it's outside, we don't.

Wouldn't that satisfy the issue that you're working on?

Michael

Re: [RFA/PATCH] breakpoint.c: fix until command

[Elena Zannoni]

Michael Snyder writes:

 > >  > > > I don't think there is a way to have both behaviors work correctly.  I
 > >  > > > thought of checking that the pc which you want to run until is in
 > >  > > > the same function as the one of the selected frame, and in that case
 > >  > > > enforce the check (by using a non-null frame for the bp_until),
 > >  > > > otherwise use the null frame (which disables the check). But what would
 > >  > > > be the correct behavior if you say:
 > >  > > >
 > >  > > > "until bar" where bar is recursive, and you are in "bar" at the
 > >  > > > moment?  This doesn't work currently. It seems intuitive that you
 > >  > > > would stop the next time you enter "bar". Right now you end up at the
 > >  > > > caller of "bar".
 > >  > > >
 > 

 > I agree, but maybe we can distinguish between "a location inside the
 > current function" and "a location outside the current function".
 > After all, a line is not a meaningful distinction -- it could be a
 > line inside another function.
 > 
 > So I suggest using find_pc_partial_function to find the bounds
 > of the current function.  If <location> is inside, we use a 
 > frame-relative breakpoint.  If it's outside, we don't.
 > 
 > Wouldn't that satisfy the issue that you're working on?

See the above, in this very same thread. :-) I tried this yesterday,
but I ran into a corner case. If we decide what to do in this corner
case, we should be ok.

Elena

 > 
 > Michael

Re: [RFA/PATCH] breakpoint.c: fix until command

[Michael Snyder]

Elena Zannoni wrote:
> 
> Michael Snyder writes:
> 
>  > >  > > > I don't think there is a way to have both behaviors work correctly.  I
>  > >  > > > thought of checking that the pc which you want to run until is in
>  > >  > > > the same function as the one of the selected frame, and in that case
>  > >  > > > enforce the check (by using a non-null frame for the bp_until),
>  > >  > > > otherwise use the null frame (which disables the check). But what would
>  > >  > > > be the correct behavior if you say:
>  > >  > > >
>  > >  > > > "until bar" where bar is recursive, and you are in "bar" at the
>  > >  > > > moment?  This doesn't work currently. It seems intuitive that you
>  > >  > > > would stop the next time you enter "bar". Right now you end up at the
>  > >  > > > caller of "bar".
>  > >  > > >
>  >
> 
>  > I agree, but maybe we can distinguish between "a location inside the
>  > current function" and "a location outside the current function".
>  > After all, a line is not a meaningful distinction -- it could be a
>  > line inside another function.
>  >
>  > So I suggest using find_pc_partial_function to find the bounds
>  > of the current function.  If <location> is inside, we use a
>  > frame-relative breakpoint.  If it's outside, we don't.
>  >
>  > Wouldn't that satisfy the issue that you're working on?
> 
> See the above, in this very same thread. :-) I tried this yesterday,
> but I ran into a corner case. If we decide what to do in this corner
> case, we should be ok.

What if we can come to a consensus regarding "until bar"?

Re: [RFA/PATCH] breakpoint.c: fix until command

[Elena Zannoni]

Michael Snyder writes:
 > Elena Zannoni wrote:
 > > 
 > > Elena Zannoni writes:
 > > >  > Nevertheless, that is and has always been the intent.
 > >  >  > If you're in factorial(5), and you say "until 100",
 > >  >  > you don't stop until line 100 is hit by factorial(5).
 > >  >
 > >  >
 > >  > I am tracking down this to something that changed between (ahem...)
 > >  > 4.18 and 5.0. The code in breakpoint.c didn't change. Right now,
 > >  > stepping the two gdb's side to side, I can see a difference in
 > >  > get_prev_frame, because of a different value returned by
 > >  > FRAME_CHAIN_VALID. :-( (i have not still stepped past that to see how
 > >  > that could influence the until foo behavior, maybe it doesn't).
 > >  >
 > >  > The behavior you specify above is in 5.0 and not in 4.18, while the
 > >  > 'until foo' works in 4.18 and is broken in 5.0.
 > >  >
 > >  > More digging.
 > >  >
 > >  > Elena
 > > 
 > > OK. The reason for which 'until foo' worked at all in 4.18 is totally
 > > fortuitous.  It is because of this patch in breakpoint.c:
 > > 
 > > 1998-09-08  Jason Molenda  (jsm@bugshack.cygnus.com)
 > > 
 > >         * breakpoint.c (bpstat_stop_status):  Declare a bp match if the
 > >         current fp matches the bp->fp OR if the current fp is less than
 > >         the bp->fp if we're looking at a bp_step_resume breakpoint.
 > > 
 > > Index: breakpoint.c
 > > ===================================================================
 > > RCS file: /cvs/cvsfiles/src/gdb/breakpoint.c,v
 > > retrieving revision 1.190
 > > retrieving revision 1.191
 > > diff -u -p -p -r1.190 -r1.191
 > > --- breakpoint.c        1998/07/17 15:29:10     1.190
 > > +++ breakpoint.c        1998/09/09 04:16:57     1.191
 > > @@ -1506,7 +1506,9 @@ bpstat_stop_status (pc, not_a_breakpoint
 > >        else if (DECR_PC_AFTER_BREAK != 0 || must_shift_inst_regs)
 > >         real_breakpoint = 1;
 > > 
 > > -      if (b->frame && b->frame != (get_current_frame ())->frame)
 > > +      if (b->frame && b->frame != (get_current_frame ())->frame &&
 > > +          (b->type == bp_step_resume &&
 > > +           (get_current_frame ())->frame INNER_THAN b->frame))
 > >         bs->stop = 0;
 > >        else
 > >         {
 > > 
 > > Note that this added condition is always false for a bp_until type
 > > breakpoint.  So, effectively we were invalidating the check of the
 > > current frame vs. bp->frame. And we always stopped.
 > > 
 > > However, since we were not checking the frames, the case Michael wants
 > > didn't work.
 > > 
 > > The patch above was reverted in 1999:
 > > 
 > > 1999-08-13  Jim Kingdon  <http://developer.redhat.com/>
 > > 
 > >         * breakpoint.c (bpstat_stop_status): Revert 1998-09-08 change
 > >         to ->frame matching.  The change did not match the ChangeLog
 > >         entry, looked fishy, and caused infinite stepping when running
 > >         "next" from main on sparc w/ RH Linux.  Thanks to Jakub for the
 > >         report.
 > > 
 > > the effect was that the frame matching check was re-enabled, and so
 > > 'until foo' stopped working.
 > > 
 > > I don't think there is a way to have both behaviors work correctly.  I
 > > thought of checking that the pc which you want to run until is in
 > > the same function as the one of the selected frame, and in that case
 > > enforce the check (by using a non-null frame for the bp_until),
 > > otherwise use the null frame (which disables the check). But what would
 > > be the correct behavior if you say:
 > > 
 > > "until bar" where bar is recursive, and you are in "bar" at the
 > > moment?  This doesn't work currently. It seems intuitive that you
 > > would stop the next time you enter "bar". Right now you end up at the
 > > caller of "bar".
 > > 
 > > I think it is a matter of deciding which behavior is more useful.
 > > 
 > > (note that I tried to revert Jason's patch in stock 4.18 and 'until
 > > foo' stopped working, i.e. it wasn't something else that broke between
 > > 4.18 and 5.0)
 > 
 > You raise a good point.  The commands "until <line>" and "until <func>"
 > are inconsistant.  Moreover the docs do not seem to describe this
 > recursion behavior.  Maybe a conversation with a wider audience is
 > in order (the gdb list)?  I'm sure I can't be the only one who 
 > remembers that "until" behaved this way, and we shouldn't change
 > the behavior precipitously.

We already did that:
http://sources.redhat.com/ml/gdb/2002-11/msg00144.html

Re: [RFA/PATCH] breakpoint.c: fix until command

[Michael Snyder]

Elena Zannoni wrote:
> 
> Michael Snyder writes:
>  > Elena Zannoni wrote:
>  > >
>  > > Elena Zannoni writes:
>  > > >  > Nevertheless, that is and has always been the intent.
>  > >  >  > If you're in factorial(5), and you say "until 100",
>  > >  >  > you don't stop until line 100 is hit by factorial(5).
>  > >  >
>  > >  >
>  > >  > I am tracking down this to something that changed between (ahem...)
>  > >  > 4.18 and 5.0. The code in breakpoint.c didn't change. Right now,
>  > >  > stepping the two gdb's side to side, I can see a difference in
>  > >  > get_prev_frame, because of a different value returned by
>  > >  > FRAME_CHAIN_VALID. :-( (i have not still stepped past that to see how
>  > >  > that could influence the until foo behavior, maybe it doesn't).
>  > >  >
>  > >  > The behavior you specify above is in 5.0 and not in 4.18, while the
>  > >  > 'until foo' works in 4.18 and is broken in 5.0.
>  > >  >
>  > >  > More digging.
>  > >  >
>  > >  > Elena
>  > >
>  > > OK. The reason for which 'until foo' worked at all in 4.18 is totally
>  > > fortuitous.  It is because of this patch in breakpoint.c:
>  > >
>  > > 1998-09-08  Jason Molenda  (jsm@bugshack.cygnus.com)
>  > >
>  > >         * breakpoint.c (bpstat_stop_status):  Declare a bp match if the
>  > >         current fp matches the bp->fp OR if the current fp is less than
>  > >         the bp->fp if we're looking at a bp_step_resume breakpoint.
>  > >
>  > > Index: breakpoint.c
>  > > ===================================================================
>  > > RCS file: /cvs/cvsfiles/src/gdb/breakpoint.c,v
>  > > retrieving revision 1.190
>  > > retrieving revision 1.191
>  > > diff -u -p -p -r1.190 -r1.191
>  > > --- breakpoint.c        1998/07/17 15:29:10     1.190
>  > > +++ breakpoint.c        1998/09/09 04:16:57     1.191
>  > > @@ -1506,7 +1506,9 @@ bpstat_stop_status (pc, not_a_breakpoint
>  > >        else if (DECR_PC_AFTER_BREAK != 0 || must_shift_inst_regs)
>  > >         real_breakpoint = 1;
>  > >
>  > > -      if (b->frame && b->frame != (get_current_frame ())->frame)
>  > > +      if (b->frame && b->frame != (get_current_frame ())->frame &&
>  > > +          (b->type == bp_step_resume &&
>  > > +           (get_current_frame ())->frame INNER_THAN b->frame))
>  > >         bs->stop = 0;
>  > >        else
>  > >         {
>  > >
>  > > Note that this added condition is always false for a bp_until type
>  > > breakpoint.  So, effectively we were invalidating the check of the
>  > > current frame vs. bp->frame. And we always stopped.
>  > >
>  > > However, since we were not checking the frames, the case Michael wants
>  > > didn't work.
>  > >
>  > > The patch above was reverted in 1999:
>  > >
>  > > 1999-08-13  Jim Kingdon  <http://developer.redhat.com/>
>  > >
>  > >         * breakpoint.c (bpstat_stop_status): Revert 1998-09-08 change
>  > >         to ->frame matching.  The change did not match the ChangeLog
>  > >         entry, looked fishy, and caused infinite stepping when running
>  > >         "next" from main on sparc w/ RH Linux.  Thanks to Jakub for the
>  > >         report.
>  > >
>  > > the effect was that the frame matching check was re-enabled, and so
>  > > 'until foo' stopped working.
>  > >
>  > > I don't think there is a way to have both behaviors work correctly.  I
>  > > thought of checking that the pc which you want to run until is in
>  > > the same function as the one of the selected frame, and in that case
>  > > enforce the check (by using a non-null frame for the bp_until),
>  > > otherwise use the null frame (which disables the check). But what would
>  > > be the correct behavior if you say:
>  > >
>  > > "until bar" where bar is recursive, and you are in "bar" at the
>  > > moment?  This doesn't work currently. It seems intuitive that you
>  > > would stop the next time you enter "bar". Right now you end up at the
>  > > caller of "bar".
>  > >
>  > > I think it is a matter of deciding which behavior is more useful.
>  > >
>  > > (note that I tried to revert Jason's patch in stock 4.18 and 'until
>  > > foo' stopped working, i.e. it wasn't something else that broke between
>  > > 4.18 and 5.0)
>  >
>  > You raise a good point.  The commands "until <line>" and "until <func>"
>  > are inconsistant.  Moreover the docs do not seem to describe this
>  > recursion behavior.  Maybe a conversation with a wider audience is
>  > in order (the gdb list)?  I'm sure I can't be the only one who
>  > remembers that "until" behaved this way, and we shouldn't change
>  > the behavior precipitously.
> 
> We already did that:
> http://sources.redhat.com/ml/gdb/2002-11/msg00144.html

I could swear I remember replying to your first msg, but
I don't see my reply...

    If I am in 'foo' at line 15,and enter the command 'until fun', 
    I would expect to end up ... where? At line 22?  Or should I 
    end up at line 5? Right now gdb ends up at 22, i.e. doesn't 
    enter 'fun'. I think it is consistent with the doco.

I think stopping at line 22 is entirely consistent with the doco, 
since foo does not call fun: "Continue running your program until
either the specified location is reached, _or_the_current_stack_
frame_returns_.  That would be line 22.

    Similarly from foo line 15 where should 'until fun2' take me? 
    Inside fun2, at line 10? Or at line 16? Currently I end up at 
    line 22 which is in main. This seems clearly wrong either way.

This is where we have a problem.  We're working on deciding the
answer to this question.  I think we're converging on "inside
fun2, at line 10", which unles I'm mistaken, is the answer
you want?

I believe the current behavior would be to stop at line 22, 
but I agree that that behavior makes no sense.

Michael

Re: [RFA/PATCH] breakpoint.c: fix until command

[Elena Zannoni]

Michael Snyder writes:
 > Daniel Jacobowitz wrote:
 > > 
 > > On Mon, Dec 23, 2002 at 03:53:22PM -0800, Michael Snyder wrote:
 > > > Elena Zannoni wrote:
 > > > >
 > > > > This fixes the problem reported in:
 > > > > http://sources.redhat.com/ml/gdb/2002-11/msg00144.html
 > > > >
 > > > > testsuite patch coming
 > > >
 > > > Elena, can you sum up in a sentence or two, what this change
 > > > is intended to do?
 > > 
 > > [Since I happen to be reading email right now, I'll do a sketchy
 > > imitation.]
 > > 
 > > The problem is that we were marking the breakpoint on the
 > > user-specified line with the current frame.  But when we hit that
 > > breakpoint, if it's in a different function, it will have a different
 > > frame.  Right now we see that the frames don't match and resume
 > > executing.
 > > 
 > > Oops.
 > 
 > OK, thanks.  But we _need_ to mark the breakpoint with the current
 > frame, because if the breakpoint is in the current frame, we don't
 > want to stop in an inner recursive call, ie. not until the current
 > frame hits the breakpoint.  
 > 

You mean this:

(gdb) l
91	#else
92	int factorial (value)
93	int value;
94	#endif
95	{
96	    if (value > 1) {
97		value *= factorial (value - 1);
98	    }
99	    return (value);
100	}
(gdb) until 99

where should we stop? At the same invocation of factorial from which
we issued the until, or the next time line 99 is executed, i.e. the
next inner invocation of factorial? I would find the latter more
intuitive.  To do what you want one could use 'break 99' and 'ignore n'.

(gdb) b factorial
Breakpoint 2 at 0x80485d7: file /home/ezannoni/sources/src/gdb/testsuite/gdb.base/break.c, line 96.
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /home/ezannoni/sources/native/gdb/testsuite/gdb.base/break 

Breakpoint 2, factorial (value=6)
    at /home/ezannoni/sources/src/gdb/testsuite/gdb.base/break.c:96
96	    if (value > 1) {
(gdb) delete
Delete all breakpoints? (y or n) y
(gdb) b 99

Breakpoint 3 at 0x80485f8: file /home/ezannoni/sources/src/gdb/testsuite/gdb.base/break.c, line 99.
(gdb) ignore 3 5
Will ignore next 5 crossings of breakpoint 3.
(gdb) c
Continuing.

Breakpoint 3, factorial (value=720)
    at /home/ezannoni/sources/src/gdb/testsuite/gdb.base/break.c:99
99	    return (value);

And here you are at the outermost invocation of factorial:

(gdb) n
100	}
(gdb) 
720
main (argc=1, argv=0xbffff374, envp=0xbffff37c)
    at /home/ezannoni/sources/src/gdb/testsuite/gdb.base/break.c:81
81	    marker1 ();



Elena


 > So this needs further consideration, and I don't think it can
 > be approved as is.
 > 
 > Michael
 > 
 > > >
 > > > > 2002-12-20  Elena Zannoni  <ezannoni@redhat.com>
 > > > >
 > > > >         Fix PR breakpoints/898.
 > > > >         * breakpoint.c (until_break_command): Don't use selected_frame,
 > > > >         but the null frame.
 > > > >
 > > > > Index: breakpoint.c
 > > > > ===================================================================
 > > > > RCS file: /cvs/uberbaum/gdb/breakpoint.c,v
 > > > > retrieving revision 1.104
 > > > > diff -u -p -r1.104 breakpoint.c
 > > > > --- breakpoint.c        17 Dec 2002 17:27:44 -0000      1.104
 > > > > +++ breakpoint.c        20 Dec 2002 18:06:27 -0000
 > > > > @@ -5615,9 +5615,7 @@ until_break_command (char *arg, int from
 > > > >
 > > > >    resolve_sal_pc (&sal);
 > > > >
 > > > > -  breakpoint =
 > > > > -    set_momentary_breakpoint (sal,get_frame_id (deprecated_selected_frame),
 > > > > -                             bp_until);
 > > > > +  breakpoint = set_momentary_breakpoint (sal, null_frame_id, bp_until);
 > > > >
 > > > >    if (!event_loop_p || !target_can_async_p ())
 > > > >      old_chain = make_cleanup_delete_breakpoint (breakpoint);
 > > >
 > > 
 > > --
 > > Daniel Jacobowitz
 > > MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/PATCH] breakpoint.c: fix until command

[Michael Snyder]

Elena Zannoni wrote:
> 
> Michael Snyder writes:
>  > Daniel Jacobowitz wrote:
>  > >
>  > > On Mon, Dec 23, 2002 at 03:53:22PM -0800, Michael Snyder wrote:
>  > > > Elena Zannoni wrote:
>  > > > >
>  > > > > This fixes the problem reported in:
>  > > > > http://sources.redhat.com/ml/gdb/2002-11/msg00144.html
>  > > > >
>  > > > > testsuite patch coming
>  > > >
>  > > > Elena, can you sum up in a sentence or two, what this change
>  > > > is intended to do?
>  > >
>  > > [Since I happen to be reading email right now, I'll do a sketchy
>  > > imitation.]
>  > >
>  > > The problem is that we were marking the breakpoint on the
>  > > user-specified line with the current frame.  But when we hit that
>  > > breakpoint, if it's in a different function, it will have a different
>  > > frame.  Right now we see that the frames don't match and resume
>  > > executing.
>  > >
>  > > Oops.
>  >
>  > OK, thanks.  But we _need_ to mark the breakpoint with the current
>  > frame, because if the breakpoint is in the current frame, we don't
>  > want to stop in an inner recursive call, ie. not until the current
>  > frame hits the breakpoint.
>  >
> 
> You mean this:
> 
> (gdb) l
> 91      #else
> 92      int factorial (value)
> 93      int value;
> 94      #endif
> 95      {
> 96          if (value > 1) {
> 97              value *= factorial (value - 1);
> 98          }
> 99          return (value);
> 100     }
> (gdb) until 99
> 
> where should we stop? At the same invocation of factorial from which
> we issued the until, or the next time line 99 is executed, i.e. the
> next inner invocation of factorial?

The former.  That's how it's always been intended to behave.
Otherwise we wouldn't be saving the frame.

> I would find the latter more intuitive. 
> To do what you want one could use 'break 99' and 'ignore n'.

Only if you were confident that you knew the value of 'n'.

Anyway, I'm not advocating which way is more intuitive, 
I'm just reporting how it is currently meant to behave.
Always been that way, AFAIK.

 
> (gdb) b factorial
> Breakpoint 2 at 0x80485d7: file /home/ezannoni/sources/src/gdb/testsuite/gdb.base/break.c, line 96.
> (gdb) r
> The program being debugged has been started already.
> Start it from the beginning? (y or n) y
> 
> Starting program: /home/ezannoni/sources/native/gdb/testsuite/gdb.base/break
> 
> Breakpoint 2, factorial (value=6)
>     at /home/ezannoni/sources/src/gdb/testsuite/gdb.base/break.c:96
> 96          if (value > 1) {
> (gdb) delete
> Delete all breakpoints? (y or n) y
> (gdb) b 99
> 
> Breakpoint 3 at 0x80485f8: file /home/ezannoni/sources/src/gdb/testsuite/gdb.base/break.c, line 99.
> (gdb) ignore 3 5
> Will ignore next 5 crossings of breakpoint 3.
> (gdb) c
> Continuing.
> 
> Breakpoint 3, factorial (value=720)
>     at /home/ezannoni/sources/src/gdb/testsuite/gdb.base/break.c:99
> 99          return (value);
> 
> And here you are at the outermost invocation of factorial:
> 
> (gdb) n
> 100     }
> (gdb)
> 720
> main (argc=1, argv=0xbffff374, envp=0xbffff37c)
>     at /home/ezannoni/sources/src/gdb/testsuite/gdb.base/break.c:81
> 81          marker1 ();
> 
> Elena
> 
>  > So this needs further consideration, and I don't think it can
>  > be approved as is.
>  >
>  > Michael
>  >
>  > > >
>  > > > > 2002-12-20  Elena Zannoni  <ezannoni@redhat.com>
>  > > > >
>  > > > >         Fix PR breakpoints/898.
>  > > > >         * breakpoint.c (until_break_command): Don't use selected_frame,
>  > > > >         but the null frame.
>  > > > >
>  > > > > Index: breakpoint.c
>  > > > > ===================================================================
>  > > > > RCS file: /cvs/uberbaum/gdb/breakpoint.c,v
>  > > > > retrieving revision 1.104
>  > > > > diff -u -p -r1.104 breakpoint.c
>  > > > > --- breakpoint.c        17 Dec 2002 17:27:44 -0000      1.104
>  > > > > +++ breakpoint.c        20 Dec 2002 18:06:27 -0000
>  > > > > @@ -5615,9 +5615,7 @@ until_break_command (char *arg, int from
>  > > > >
>  > > > >    resolve_sal_pc (&sal);
>  > > > >
>  > > > > -  breakpoint =
>  > > > > -    set_momentary_breakpoint (sal,get_frame_id (deprecated_selected_frame),
>  > > > > -                             bp_until);
>  > > > > +  breakpoint = set_momentary_breakpoint (sal, null_frame_id, bp_until);
>  > > > >
>  > > > >    if (!event_loop_p || !target_can_async_p ())
>  > > > >      old_chain = make_cleanup_delete_breakpoint (breakpoint);
>  > > >
>  > >
>  > > --
>  > > Daniel Jacobowitz
>  > > MontaVista Software                         Debian GNU/Linux Developer