From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id iNw4DQ+822PjFSgAWB0awg (envelope-from ) for ; Thu, 02 Feb 2023 08:35:11 -0500 Received: by simark.ca (Postfix, from userid 112) id 2A8F41E128; Thu, 2 Feb 2023 08:35:11 -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=MyirNqcA; 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 BEEB31E110 for ; Thu, 2 Feb 2023 08:35:10 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id DB23E3858288 for ; Thu, 2 Feb 2023 13:35:09 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DB23E3858288 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1675344909; bh=4XuxbqKgvuHPR8VtXaLH7Px+kEozBXOczXRjrvgoHo8=; 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=MyirNqcAgTQ1UD5dQoTnOERYfF9rNwB9NB6J+hu5CHkmlcmnDT4CuoMPjQw3vb9yR C/wsCBhh/bc6Kffoh7Qh4ANXGOcbA8XGLvjuEZStTSSYuzcyp4CGd9E1UeEuHpYtCJ P2US4ilbj8qiJSgi7cz9Olc/JMwOoYWz362xGVZg= 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 5E44B3858C60 for ; Thu, 2 Feb 2023 13:34:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5E44B3858C60 Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-502-mohc3HjoM7OvduQ660CtgA-1; Thu, 02 Feb 2023 08:34:47 -0500 X-MC-Unique: mohc3HjoM7OvduQ660CtgA-1 Received: by mail-qt1-f197.google.com with SMTP id x16-20020ac87ed0000000b003b82d873b38so945592qtj.13 for ; Thu, 02 Feb 2023 05:34:47 -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=4XuxbqKgvuHPR8VtXaLH7Px+kEozBXOczXRjrvgoHo8=; b=TXLIcQ5vEZbXcKK0mUr6VbDSmuGaBFcxrdOFN8JZ+BoPw5M6auDPNhffpvKHRkL6tI WpQ6w2xR1cGT46s3RipDBe5f9He4iffuxwhjQvAYv+12W/gEU+T0A6FYK/5x0CPJ+gbW w3ei3s0CbGZ3HFpKF6yyJDJoWxWiL7q64ZT/YQDoFrSviduNtfNKyitmZGritnnuK5TO XjxzIWuPGOKb7uOg+asCKCUtClMIMuHm8gzGrSSpN/5ZfKS6e2l9PyfL1Atq0iiOx59T ZicYP68zuJUY4oCKCfV5QdL8UOlL5MVXuuEoVdPj8BY/afwkiYYSOjIPYvgBknTdBkhO d/+A== X-Gm-Message-State: AO0yUKWs095zecmzhwWUckIMqKHBX/NIbZZVDK6ErwpKySsJQoAyoFg0 WE9ZK4nc3UqstlUhVLEpOkiIh+D7E3cbH0fRnOvDLAsDT4KVCcR5B+ZkQu7yBp3GNazWVHUKW8u AzWxbYD6pYFVDNbRc3cBJLA== X-Received: by 2002:ac8:5a86:0:b0:3b9:da90:ebee with SMTP id c6-20020ac85a86000000b003b9da90ebeemr2041145qtc.30.1675344886969; Thu, 02 Feb 2023 05:34:46 -0800 (PST) X-Google-Smtp-Source: AK7set+0uVoruTCT4PKzJeMIfktEA55cVie7RvwffQ7HEGHC5Fkaxo9eqSssFMD8IAs1Dq+G/Bz55w== X-Received: by 2002:ac8:5a86:0:b0:3b9:da90:ebee with SMTP id c6-20020ac85a86000000b003b9da90ebeemr2041115qtc.30.1675344886715; Thu, 02 Feb 2023 05:34:46 -0800 (PST) Received: from localhost (95.72.115.87.dyn.plus.net. [87.115.72.95]) by smtp.gmail.com with ESMTPSA id k14-20020ac8604e000000b003ab7aee56a0sm13575662qtm.39.2023.02.02.05.34.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Feb 2023 05:34:46 -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: <83ilglz1ih.fsf@gnu.org> References: <78764570698177ecf049fdab759908ca88fd7bd3.1675185990.git.aburgess@redhat.com> <83tu061stt.fsf@gnu.org> <87v8kls2ev.fsf@redhat.com> <83ilglz1ih.fsf@gnu.org> Date: Thu, 02 Feb 2023 13:34:44 +0000 Message-ID: <87pmasry17.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: >> From: Andrew Burgess >> 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