From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) by sourceware.org (Postfix) with ESMTPS id 259ED3858D35 for ; Wed, 29 Sep 2021 08:34:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 259ED3858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=embecosm.com Received: by mail-wm1-x32b.google.com with SMTP id 205-20020a1c01d6000000b0030cd17ffcf8so4532511wmb.3 for ; Wed, 29 Sep 2021 01:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=RYWgiGlqbTLNqmZ21MGuUg71Wl3wQqATkqFGcR7VEgM=; b=LTN+l57tcT8qd0VLgKbnkEVc+OLTv9OFbX5KJdMhe0TduC/+ezvIM+CUrtQlmIbVbL 2/7w4Y2s/NH5WzUNOGhF/b8GnFnAWB0EntM45wBGST6SPHT25cSGa7InsPZV1zrb/Rkg 2bvPbP3RUyUGkpLEB9gSXMYqDbnsKS4dW9qlcR6EqRmOWEYSmFsftIpFrxH80WzxzCn/ 7k34l5s++3RLYrhmigBquS2yFjqlOBRHmNPBOyxHYXY1mcAL6QumRyFEwLNZuCQmWl4j ksjP6GmRDvsDr3qJCb03oGs9BiGoKC4j2tRu/1Jjyz6vjt5CAuz2pj5e9HZQsgpQIrWU MIzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=RYWgiGlqbTLNqmZ21MGuUg71Wl3wQqATkqFGcR7VEgM=; b=wlO3ikxMk2PZtr+RxstjxxQIcIZHI1WDKa92AqGuwv3CHNmaBroxg6YCJgoSANgq0e CxyuqduV4r9zJn8HEoy+k9u/fpFfbmY3BGljsPXW4Lyd7g8iUFgXBzFQxffwAuGWHa3x IjPUTH9VBHh9AZig3O8OJv5T5fNqWD6oVD6QnuejRZQDDfy8FYg2c46HSfMFhJXWkTPf gqjv0ZcdtJccoAu7ZVveN6OlZPh7cACiGxHBfAh2aRht1tBVGuNmv4voJccFjYIQ/9YO xXO1khyaZViSF5uDShAgFBwKAzohevLxGkt7YYDG+98JBL3bbPnW9qgPlw2iSV61zz8r b0zQ== X-Gm-Message-State: AOAM532H/+jRsSNEG+O5k4pl7uBryb8GxqPF7wWW1Bg4CGfd3weTmZqs EPQ9eHVtZ5pb+eJuSyHYMo0ndBXuDJ02Pg== X-Google-Smtp-Source: ABdhPJzn0qEKb/6janQtILu8i69eb584aleovNaJzNUMVg9O2V2Z3qYZF+bCsoCxv8A2w4EsKPROgw== X-Received: by 2002:a1c:192:: with SMTP id 140mr9010437wmb.186.1632904486095; Wed, 29 Sep 2021 01:34:46 -0700 (PDT) Received: from localhost (host86-169-137-11.range86-169.btcentralplus.com. [86.169.137.11]) by smtp.gmail.com with ESMTPSA id h1sm870632wmb.7.2021.09.29.01.34.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Sep 2021 01:34:45 -0700 (PDT) Date: Wed, 29 Sep 2021 09:34:44 +0100 From: Andrew Burgess To: Eli Zaretskii Cc: gdb-patches@sourceware.org Subject: Re: [PUSHED 6/6] gdb: print backtrace for internal error/warning Message-ID: <20210929083444.GL1900093@embecosm.com> References: <91f2597bd24d171c1337a4629f8237aa47c59082.1632828191.git.andrew.burgess@embecosm.com> <83ee98khrs.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83ee98khrs.fsf@gnu.org> X-Operating-System: Linux/5.8.18-100.fc31.x86_64 (x86_64) X-Uptime: 09:28:45 up 9 days, 23:37, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-Spam-Status: No, score=-10.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: , X-List-Received-Date: Wed, 29 Sep 2021 08:34:49 -0000 * Eli Zaretskii [2021-09-28 15:26:47 +0300]: > > From: Andrew Burgess > > Date: Tue, 28 Sep 2021 12:26:24 +0100 > > > > ../../src.dev-3/gdb/maint.c:82: internal-error: blah > > A problem internal to GDB has been detected, > > further debugging may prove unreliable. > > Create a core file of GDB? (y or n) n > > > > My hope is that this backtrace might make it slightly easier to > > diagnose GDB issues if all that is provided is the console output, I > > find that we frequently get reports of an assert being hit that is > > located in pretty generic code (frame.c, value.c, etc) and it is not > > always obvious how we might have arrived at the assert. > > > > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26377 > > --- > > gdb/NEWS | 8 ++ > > gdb/doc/gdb.texinfo | 13 ++ > > .../gdb.base/bt-on-error-and-warning.exp | 118 ++++++++++++++++++ > > gdb/testsuite/gdb.base/bt-on-fatal-signal.exp | 36 ------ > > gdb/utils.c | 36 +++++- > > 5 files changed, 174 insertions(+), 37 deletions(-) > > create mode 100644 gdb/testsuite/gdb.base/bt-on-error-and-warning.exp > > > > diff --git a/gdb/NEWS b/gdb/NEWS > > index d7c29c82edb..1e25cb8cc36 100644 > > --- a/gdb/NEWS > > +++ b/gdb/NEWS > > @@ -19,6 +19,14 @@ show source open > > to open and read source code files, which can be useful if the files > > are located over a slow network connection. > > > > +maint set internal-error backtrace on|off > > +maint show internal-error backtrace > > +maint set internal-warning backtrace on|off > > +maint show internal-warning backtrace > > + GDB can now print a backtrace of itself when it encounters either an > > + internal-error, or an internal-warning. This is on by default for > > + internal-error and off by default for internal-warning. > > Does this depend on libbacktrace? If so, should that be mentioned in > the documentation? I'm not sure. libbacktrace is now included within the binutils-gdb repository, so it's not like this is a dependency that users will need to hunt down and install on their own. It is true that libbacktrace could potentially not be supported/built on a particular target, but then GDB falls back to the libc backtrace() API, so libbacktrace isn't a hard requirement for getting such a backtrace, it's just one possible requirement. Would you suggest that this dependency situation be described in the actual .texinfo docs? Or just mentioned in the NEWS file? If you can give some more guidance, I'll try to draft some suitable words. > > > +When @value{GDBN} reports an internal problem (error or warning) it is > > +possible to have a backtrace of @value{GDBN} printed to stderr. This > > I suggest "standard error stream" instead of "stderr". Thanks, I fixed the two places I said 'stderr' with the patch below which I pushed. Thanks, Andrew --- commit 4180173142185f0967dfefb131e4843a17779c86 Author: Andrew Burgess Date: Wed Sep 29 09:25:03 2021 +0100 gdb/doc: use 'standard error stream' instead of 'stderr' in some places With this commit: commit 91f2597bd24d171c1337a4629f8237aa47c59082 Date: Thu Aug 12 18:24:59 2021 +0100 gdb: print backtrace for internal error/warning I included some references to 'stderr', which, it was pointed out, would be better written as 'standard error stream'. See: https://sourceware.org/pipermail/gdb-patches/2021-September/182225.html This commit replaces the two instances of 'stderr' that I introduced. diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo index d4e4174be5d..c156a1d6739 100644 --- a/gdb/doc/gdb.texinfo +++ b/gdb/doc/gdb.texinfo @@ -39266,9 +39266,9 @@ @itemx maint set internal-warning backtrace @r{[}on|off@r{]} @itemx maint show internal-warning backtrace When @value{GDBN} reports an internal problem (error or warning) it is -possible to have a backtrace of @value{GDBN} printed to stderr. This -is @samp{on} by default for @code{internal-error} and @samp{off} by -default for @code{internal-warning}. +possible to have a backtrace of @value{GDBN} printed to the standard +error stream. This is @samp{on} by default for @code{internal-error} +and @samp{off} by default for @code{internal-warning}. @kindex maint packet @item maint packet @var{text} @@ -39768,9 +39768,9 @@ @itemx maint show backtrace-on-fatal-signal When this setting is @code{on}, if @value{GDBN} itself terminates with a fatal signal (e.g.@: SIGSEGV), then a limited backtrace will be -printed to stderr. This backtrace can be used to help diagnose -crashes within @value{GDBN} in situations where a user is unable to -share a corefile with the @value{GDBN} developers. +printed to the standard error stream. This backtrace can be used to +help diagnose crashes within @value{GDBN} in situations where a user +is unable to share a corefile with the @value{GDBN} developers. If the functionality to provide this backtrace is not available for the platform on which GDB is running then this feature will be