From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id i6ltB+Ol2mNRXycAWB0awg (envelope-from ) for ; Wed, 01 Feb 2023 12:48:19 -0500 Received: by simark.ca (Postfix, from userid 112) id 0C9B51E128; Wed, 1 Feb 2023 12:48:19 -0500 (EST) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=GZAL1TI/; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id A7B131E0D3 for ; Wed, 1 Feb 2023 12:48:18 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 69C963858412 for ; Wed, 1 Feb 2023 17:48:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 69C963858412 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1675273697; bh=VuPFQqUn9DqVcv1PPHH+AzfkntEKcXq0mEGhqfRxXgI=; h=To:Cc:Subject:In-Reply-To:References:Date:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=GZAL1TI/loj9Bo2vx5kqy1Xjz6h6rxV8rAP4wyQLWLczrFeh9RSoV9ojFhQtWPsew YbkqzPha7Buj2AsaDHRcjo32OGC59PUfT77VbTT3TATKmJ2fSGc4kPuc9lt2+X9IBD c0psTrz8srwpTV/RI3P/7v0Hf19XdPFENc238aBA= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id F1E2A3858D33 for ; Wed, 1 Feb 2023 17:47:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F1E2A3858D33 Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-474-EYgs51IhOc2jfJGu_6G18w-1; Wed, 01 Feb 2023 12:47:55 -0500 X-MC-Unique: EYgs51IhOc2jfJGu_6G18w-1 Received: by mail-qt1-f199.google.com with SMTP id cd3-20020a05622a418300b003b9bd2a2284so827172qtb.4 for ; Wed, 01 Feb 2023 09:47:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=VuPFQqUn9DqVcv1PPHH+AzfkntEKcXq0mEGhqfRxXgI=; b=CljxNhbqw7YlsXGM4nxuaZ6lZE02KXFymfrTpBMd/MYXbRreejxqNYFIQhgmYNKlvl GatOzj8g2v/Dm80kfaZmE1abf40+fvrgYCDIl105MtoCeT0wBU2bXUIZjCR2btzk/7be HlGPI82wzlb6JQaR93xC2NHwRl48M53A4M0eeV10/d1TMUvaBa/jOKKen+UafVGwcewU RJOHUfEyNSKrpYmkh40VSvzm/kWnLgUicvV8ZwL9xED0REM4xFrcuf1VTqqpASo1O4bt IciC4mYwacJM98xCSB9cGsyYS0eNWdRf+cvRRXqOIPAvhgQ+qFY+psIaHrzwyqbubE7/ gxpQ== X-Gm-Message-State: AO0yUKUE2PD+P83uPmBMuyDu1dekTeAPH/uIYxUYDyXup77xPm3KdyKB FjVRpdJ32VGS7ze49KIae1p50D2YF4MDwiprPmR/zcLtqyjrOLfZ/5CQpnmautFLxaLsfp816Ba WkuGXpyvBg+H6SsBGuSFlcg== X-Received: by 2002:ac8:5850:0:b0:3b8:4144:fe72 with SMTP id h16-20020ac85850000000b003b84144fe72mr6148581qth.9.1675273675068; Wed, 01 Feb 2023 09:47:55 -0800 (PST) X-Google-Smtp-Source: AK7set+dzrSsX7gd+3brSdcjVI0rV5QJudYecjFNw4cYuPZ7cGFYXEFuREilBuFBh62XDtMeaiuS4w== X-Received: by 2002:ac8:5850:0:b0:3b8:4144:fe72 with SMTP id h16-20020ac85850000000b003b84144fe72mr6148562qth.9.1675273674844; Wed, 01 Feb 2023 09:47:54 -0800 (PST) Received: from localhost (95.72.115.87.dyn.plus.net. [87.115.72.95]) by smtp.gmail.com with ESMTPSA id x21-20020ac87a95000000b003a530a32f67sm10233311qtr.65.2023.02.01.09.47.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Feb 2023 09:47:54 -0800 (PST) To: Eli Zaretskii Cc: gdb-patches@sourceware.org Subject: Re: [PATCHv3 02/13] gdb/doc: extend the documentation for conditional breakpoints In-Reply-To: <83tu061stt.fsf@gnu.org> References: <78764570698177ecf049fdab759908ca88fd7bd3.1675185990.git.aburgess@redhat.com> <83tu061stt.fsf@gnu.org> Date: Wed, 01 Feb 2023 17:47:52 +0000 Message-ID: <87v8kls2ev.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Andrew Burgess via Gdb-patches Reply-To: Andrew Burgess Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" Eli Zaretskii writes: >> Cc: Andrew Burgess >> Date: Tue, 31 Jan 2023 17:27:07 +0000 >> From: Andrew Burgess via Gdb-patches >> >> +If a breakpoint condition calls a function in your program, then it is >> +possible that your program could stop for some reason while in the >> +called function. For example, @value{GDBN} might hit a breakpoint in >> +the called function, or the called function may receive a signal >> +(e.g.@ a @code{SIGSEGV}) as a result of some undefined behavior. If >> +this happens then @value{GDBN} will stop. Depending on the settings >> +@code{unwindonsignal} and @code{unwind-on-terminating-exception} >> +(@pxref{Calling,,Calling Program Functions}) @value{GDBN} may unwind >> +the stack back to the breakpoint location, or may leave the program at >> +the frame where the stop occurred. > > This is okay, but should we perhaps tell the reader how to deal with > these calamities? I presume there's something to say, otherwise why > do we describe these situations? How about if I add an extra sentence at the end of the paragraph to say that it is possible to continue debugging from the point where GDB stops, like this (new text starts "If @value{GDBN} remains in the..."): If a breakpoint condition calls a function in your program, then it is possible that your program could stop for some reason while in the called function. For example, @value{GDBN} might hit a breakpoint in the called function, or the called function may receive a signal (e.g.@ a @code{SIGSEGV}) as a result of some undefined behavior. If this happens then @value{GDBN} will stop. Depending on the settings @code{unwindonsignal} and @code{unwind-on-terminating-exception} (@pxref{Calling,,Calling Program Functions}) @value{GDBN} may unwind the stack back to the breakpoint location, or may leave the program at the frame where the stop occurred. If @value{GDBN} remains in the frame where the stop occurred then you can debug the inferior from this point to understand why the called function failed. Does this address your concerns? Thanks, Andrew