"continue" in breakpoint commands breaks line-by-line stepping

"continue" in breakpoint commands breaks line-by-line stepping

[Juraj Oršulić]

Hi everyone, I have a quick question. I have added some breakpoint
commands for logging using the "commands" command. Since I don't want
to stop the execution in these points, I added a "continue", as
mentioned in https://sourceware.org/gdb/onlinedocs/gdb/Break-Commands.html.
However, this breaks stepping line-by-line in outer frames - if I
stumple upon one of these logging breakpoints, it issues a "continue",
and I lose control if I call "next" when I am in an outer frame. How
could I mitigate this? Perhaps by redefining "next" to set a temporary
breakpoint on the next line to ensure that I stop there? Should this
be the default behavior?

Thanks,
Juraj

Re: "continue" in breakpoint commands breaks line-by-line stepping

[Tom Tromey]

>>>>> "Juraj" == Juraj Oršulić <juraj.orsulic@fer.hr> writes:

Juraj> Hi everyone, I have a quick question. I have added some breakpoint
Juraj> commands for logging using the "commands" command. Since I don't want
Juraj> to stop the execution in these points, I added a "continue", as
Juraj> mentioned in https://sourceware.org/gdb/onlinedocs/gdb/Break-Commands.html.
Juraj> However, this breaks stepping line-by-line in outer frames - if I
Juraj> stumple upon one of these logging breakpoints, it issues a "continue",
Juraj> and I lose control if I call "next" when I am in an outer frame. How
Juraj> could I mitigate this? Perhaps by redefining "next" to set a temporary
Juraj> breakpoint on the next line to ensure that I stop there? Should this
Juraj> be the default behavior?

There are a few reasonably good ways to deal with the
"next-over-continue" issue.

One way, specifically for logging, is to use the dprintf command instead
of a breakpoint+commands.  dprintf doesn't have this problem.

Another way, if you need something more generic, is to use Python to
create your breakpoints and do your actions in the |stop| method.  This
was introduced specifically to deal with this problem.

A third way, specific to modifying a variable, is not to do this:

    b x
    commands
      silent
      set y = 73
      cont
    end

but instead:

    b x if y = 73, 1

Breakpoint conditions are evaluated at a different time and don't affect
"next"ing.

I think it would be good if the "Break Commands" documentation was
updated to mention dprintf and the variable setting scenario, and to
point out the next-over-continue problem.

Maybe gdb could introduce some kind of flag to "continue" to breakpoints
to solve this problem more generally.

Tom

Re: "continue" in breakpoint commands breaks line-by-line stepping

[Tom Tromey]

>>>>> "Tom" == Tom Tromey <tom@tromey.com> writes:

Tom> but instead:
Tom>     b x if y = 73, 1

Actually I meant ",0" here and didn't realize that it was backward
before sending.

Tom

Re: "continue" in breakpoint commands breaks line-by-line stepping

[Juraj Oršulić]

Thanks on the tips! In the end I went with a Python breakpoint,
because my logging was not a simple print, it was actually publishing
messages using ROS so I can visualize what's going on. I think a
simple note on that page, like "use the Python API for more complex
breakpoints without stopping and without breaking next", would have
pointed me in the right direction right away.

Greetings,
Juraj


On Thu, Mar 16, 2017 at 9:57 AM, Tom Tromey <tom@tromey.com> wrote:
>>>>>> "Juraj" == Juraj Oršulić <juraj.orsulic@fer.hr> writes:
>
> Juraj> Hi everyone, I have a quick question. I have added some breakpoint
> Juraj> commands for logging using the "commands" command. Since I don't want
> Juraj> to stop the execution in these points, I added a "continue", as
> Juraj> mentioned in https://sourceware.org/gdb/onlinedocs/gdb/Break-Commands.html.
> Juraj> However, this breaks stepping line-by-line in outer frames - if I
> Juraj> stumple upon one of these logging breakpoints, it issues a "continue",
> Juraj> and I lose control if I call "next" when I am in an outer frame. How
> Juraj> could I mitigate this? Perhaps by redefining "next" to set a temporary
> Juraj> breakpoint on the next line to ensure that I stop there? Should this
> Juraj> be the default behavior?
>
> There are a few reasonably good ways to deal with the
> "next-over-continue" issue.
>
> One way, specifically for logging, is to use the dprintf command instead
> of a breakpoint+commands.  dprintf doesn't have this problem.
>
> Another way, if you need something more generic, is to use Python to
> create your breakpoints and do your actions in the |stop| method.  This
> was introduced specifically to deal with this problem.
>
> A third way, specific to modifying a variable, is not to do this:
>
>     b x
>     commands
>       silent
>       set y = 73
>       cont
>     end
>
> but instead:
>
>     b x if y = 73, 1
>
> Breakpoint conditions are evaluated at a different time and don't affect
> "next"ing.
>
> I think it would be good if the "Break Commands" documentation was
> updated to mention dprintf and the variable setting scenario, and to
> point out the next-over-continue problem.
>
> Maybe gdb could introduce some kind of flag to "continue" to breakpoints
> to solve this problem more generally.
>
> Tom