From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105240 invoked by alias); 16 Mar 2017 12:21:13 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 105223 invoked by uid 89); 16 Mar 2017 12:21:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=1.5 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=ros, HTo:U*tom, publishing, or=c5=a1uli=c4?= X-HELO: mail.fer.hr Received: from mail5.fer.hr (HELO mail.fer.hr) (161.53.72.235) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 16 Mar 2017 12:21:09 +0000 Received: from POSTAR.fer.hr (2001:b68:16:250::72:237) by MAIL5.fer.hr (2001:b68:16:250::72:235) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 16 Mar 2017 13:21:06 +0100 Received: from mail-wm0-f46.google.com (74.125.82.46) by POSTAR.fer.hr (161.53.72.237) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 16 Mar 2017 13:21:06 +0100 Received: by mail-wm0-f46.google.com with SMTP id t189so46241378wmt.1 for ; Thu, 16 Mar 2017 05:21:06 -0700 (PDT) X-Gm-Message-State: AFeK/H3xtkjuyy90veOa2UVy9K8b+VdRCho3FbPpDjHEd8LCorCjc5YUN7dVTKaYJdQ/KIa9U/+XORk0peagwA== X-Received: by 10.28.147.147 with SMTP id v141mr26455694wmd.110.1489666866073; Thu, 16 Mar 2017 05:21:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.224.139 with HTTP; Thu, 16 Mar 2017 05:20:25 -0700 (PDT) In-Reply-To: <51b1626e27124e7f9b43603f0bb2a4dc@MAIL.fer.hr> References: <51b1626e27124e7f9b43603f0bb2a4dc@MAIL.fer.hr> From: =?UTF-8?B?SnVyYWogT3LFoXVsacSH?= Date: Thu, 16 Mar 2017 12:21:00 -0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: "continue" in breakpoint commands breaks line-by-line stepping To: Tom Tromey CC: "gdb@sourceware.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-SW-Source: 2017-03/txt/msg00022.txt.bz2 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 wrote: >>>>>> "Juraj" =3D=3D Juraj Or=C5=A1uli=C4=87 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 w= ant > Juraj> to stop the execution in these points, I added a "continue", as > Juraj> mentioned in https://sourceware.org/gdb/onlinedocs/gdb/Break-Comma= nds.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 "contin= ue", > Juraj> and I lose control if I call "next" when I am in an outer frame. H= ow > Juraj> could I mitigate this? Perhaps by redefining "next" to set a tempo= rary > Juraj> breakpoint on the next line to ensure that I stop there? Should th= is > 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 =3D 73 > cont > end > > but instead: > > b x if y =3D 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