Message ID | 78764570698177ecf049fdab759908ca88fd7bd3.1675185990.git.aburgess@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <gdb-patches-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4A1463858000 for <patchwork@sourceware.org>; Tue, 31 Jan 2023 17:50:19 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4A1463858000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1675187419; bh=YOqM371fnJuseZPG+vfR9ai3DSPN1m3S3lmdKNcrEsQ=; h=To:Cc:Subject:Date:In-Reply-To:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=CMarh6WD1Xpfe2mJcK7V/SUjZgVo0uNEtSwPQs/NboWuHhDCeGaGtyyrSucmScAKo UL5btFmjSjUCdeBP+ScSh3cOtdFtvGIBQjaLgpydg/mDU+L1FmTN/nyso0b144Jicn u7/f6F+Q9PH3IkPUZyA3zDx2+yvTSLD5vGt52c4M= X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org 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 4008F3858404 for <gdb-patches@sourceware.org>; Tue, 31 Jan 2023 17:49:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4008F3858404 Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-625-fgV4AsLUNd6mum8WZqZBSQ-1; Tue, 31 Jan 2023 12:27:25 -0500 X-MC-Unique: fgV4AsLUNd6mum8WZqZBSQ-1 Received: by mail-qk1-f197.google.com with SMTP id a3-20020a05620a438300b007069b068069so9460213qkp.2 for <gdb-patches@sourceware.org>; Tue, 31 Jan 2023 09:27:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=YOqM371fnJuseZPG+vfR9ai3DSPN1m3S3lmdKNcrEsQ=; b=08jbd09CfU6YLqdsbXqxytJAbqf/xlgX5jole9U6Yhenby+sLi/6RvIdTPMckeOJEI Q2UCjYPhoS7btePd7kOjOL9pJfokdsEmICM+tTK+ZwikvLH+l8Ec53otWa1diyZ/G7SE ROkT0PvFSIpABwdsyTSI23tC2ZZ5nzlYXBgBRi+6FZMgbVrcsjYN/goEU0c/9ioirPmy ZS0EbUm0kJiZOERyzm9VF/N2HYrV6p3uj3CIIkt5K0NjSinO1TKBit74UWOqzqLvvkK9 0kBck5/UVA4uZr4rG27AI0YgkQ8NMymNOVIJxkj5Z3X2gWjNXtEPmP8uuZyEs3281k3C corg== X-Gm-Message-State: AO0yUKV6VyWifNpS86ilXIhDEuL+/Hr80XOYr/g8fZVJ2Hq5wu/T5t5T m5PVl1RtqS9UDwF5e2J0Kxvyv+1RXEv+lWbenSuld69Au88veOetIa/Bv2JzzO5sPerKWvo5+Uo tCXnfomGaFeK1KE7OMN7qTr0pTRulnHY+XjYgZsLe3Cyo16aWr3VdaYx56VllJJff1e8dGhdJWw == X-Received: by 2002:ac8:5956:0:b0:3b8:4144:fe72 with SMTP id 22-20020ac85956000000b003b84144fe72mr20946648qtz.9.1675186045306; Tue, 31 Jan 2023 09:27:25 -0800 (PST) X-Google-Smtp-Source: AK7set+YjOHcJ10eFWepkVTn3L1Mx9pP5+xUFq/9hytq7jzeMfa3fKehAf3JcKs0OOUxjm4Va7wlDg== X-Received: by 2002:ac8:5956:0:b0:3b8:4144:fe72 with SMTP id 22-20020ac85956000000b003b84144fe72mr20946618qtz.9.1675186045042; Tue, 31 Jan 2023 09:27:25 -0800 (PST) Received: from localhost (95.72.115.87.dyn.plus.net. [87.115.72.95]) by smtp.gmail.com with ESMTPSA id f10-20020ac8134a000000b003b9b4028d63sm921868qtj.80.2023.01.31.09.27.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 31 Jan 2023 09:27:24 -0800 (PST) To: gdb-patches@sourceware.org Cc: Andrew Burgess <aburgess@redhat.com> Subject: [PATCHv3 02/13] gdb/doc: extend the documentation for conditional breakpoints Date: Tue, 31 Jan 2023 17:27:07 +0000 Message-Id: <78764570698177ecf049fdab759908ca88fd7bd3.1675185990.git.aburgess@redhat.com> X-Mailer: git-send-email 2.25.4 In-Reply-To: <cover.1675185990.git.aburgess@redhat.com> References: <cover.1674058359.git.aburgess@redhat.com> <cover.1675185990.git.aburgess@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII"; x-default=true X-Spam-Status: No, score=-11.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list <gdb-patches.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/gdb-patches>, <mailto:gdb-patches-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/gdb-patches>, <mailto:gdb-patches-request@sourceware.org?subject=subscribe> From: Andrew Burgess via Gdb-patches <gdb-patches@sourceware.org> Reply-To: Andrew Burgess <aburgess@redhat.com> Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org Sender: "Gdb-patches" <gdb-patches-bounces+patchwork=sourceware.org@sourceware.org> |
Series |
Infcalls from B/P conditions in multi-threaded inferiors
|
|
Commit Message
Andrew Burgess
Jan. 31, 2023, 5:27 p.m. UTC
This documentation update adds more text to describe what happens if a conditional breakpoint calls an inferior function, and the inferior function is interrupted for some reason. --- gdb/doc/gdb.texinfo | 11 +++++++++++ 1 file changed, 11 insertions(+)
Comments
> Cc: Andrew Burgess <aburgess@redhat.com> > Date: Tue, 31 Jan 2023 17:27:07 +0000 > From: Andrew Burgess via Gdb-patches <gdb-patches@sourceware.org> > > +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? Thanks.
Eli Zaretskii <eliz@gnu.org> writes: >> Cc: Andrew Burgess <aburgess@redhat.com> >> Date: Tue, 31 Jan 2023 17:27:07 +0000 >> From: Andrew Burgess via Gdb-patches <gdb-patches@sourceware.org> >> >> +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
> From: Andrew Burgess <aburgess@redhat.com> > Cc: gdb-patches@sourceware.org > Date: Wed, 01 Feb 2023 17:47:52 +0000 > > 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? Some. But I also think that the text should more explicitly explain that the various values of the unwind-* options are there precisely to tailor what happens to the needs of the debugging session. The text is now written as purely descriptional: if you set the option this way, what will happen is so-and-so. It would be better, I think, to turn the table and say: if you want to debug the called function when this happen, set the option to this value; OTOH if you want ignore that and continue debugging the inferior, set the option to that other value. Does this make sense?
Eli Zaretskii <eliz@gnu.org> writes: >> From: Andrew Burgess <aburgess@redhat.com> >> Cc: gdb-patches@sourceware.org >> Date: Wed, 01 Feb 2023 17:47:52 +0000 >> >> 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? > > Some. But I also think that the text should more explicitly explain > that the various values of the unwind-* options are there precisely to > tailor what happens to the needs of the debugging session. The text > is now written as purely descriptional: if you set the option this > way, what will happen is so-and-so. It would be better, I think, to > turn the table and say: if you want to debug the called function when > this happen, set the option to this value; OTOH if you want ignore > that and continue debugging the inferior, set the option to that other > value. Does this make sense? OK thanks. I spent some time thinking about what I was trying to say here, and in the end I'm not convinced I'm actually adding much value with this change. I think the previous patch, and the doc changes in later commits probably contains enough information. So, for now at least, I'm going to propose dropping just hist patch from the series. Thanks, Andrew
diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo index 682f85387e5..dd8267f448f 100644 --- a/gdb/doc/gdb.texinfo +++ b/gdb/doc/gdb.texinfo @@ -5713,6 +5713,17 @@ purpose of performing side effects when a breakpoint is reached (@pxref{Break Commands, ,Breakpoint Command Lists}). +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. + Breakpoint conditions can also be evaluated on the target's side if the target supports it. Instead of evaluating the conditions locally, @value{GDBN} encodes the expression into an agent expression