public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Andrew Burgess <aburgess@redhat.com>
To: gdb-patches@sourceware.org
Cc: Andrew Burgess <aburgess@redhat.com>
Subject: [PUSHED] gdb: fix some #ifdef logic in bt-utils.h
Date: Wed,  4 Jan 2023 11:50:52 +0000	[thread overview]
Message-ID: <b77a357567b8640003a7301b1bd50bd81fd7a26a.1672833040.git.aburgess@redhat.com> (raw)

In passing I spotted some incorrect #ifdef logic in bt-utils.h.  The
logic in question has existed since the file was originally added in
commit:

  commit abbbd4a3e0ca51132e7fb31a43f896d29894dae0
  Date:   Wed Aug 11 13:24:33 2021 +0100

      gdb: use libbacktrace to create a better backtrace for fatal signals

The code is trying to select between using libbacktrace or using the
execinfo supplied backtrace API.

First we check to see if we can use libbacktrace.  If we can then we
include some header files, and then set some defines to indicate that
libbacktrace is being used.

Then we check if execinfo is available, if it is then we include
<execinfo.h> and set some alternative defines.

In theory the second block of logic should not trigger if the first
block (that uses libbacktrace) has also triggered, but we incorrectly
check the define 'PRINT_BACKTRACE_ON_FATAL_SIGNAL' instead of checking
for 'GDB_PRINT_INTERNAL_BACKTRACE_USING_LIBBACKTRACE', so the second
block triggers more than it should.  The
'PRINT_BACKTRACE_ON_FATAL_SIGNAL' define is not defined anywhere, this
was a mistake in the original commit.

In reality this is harmless, we include <execinfo.h> when we don't
need too, but in by-utils.c the libbacktrace define is always checked
for before the execinfo define, so we never actually end up using the
execinfo path (when libbacktrace is available).  But I figure its
still worth cleaning this up.

I've tested GDB in a "default" build where libbacktrace is used, and
when configuring with --disable-libbacktrace which causes the execinfo
backtrace API to be used instead, both still appear to work fine.

There should be no user visible changes after this commit.
---
 gdb/bt-utils.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gdb/bt-utils.h b/gdb/bt-utils.h
index 079410dc8a9..ba887927979 100644
--- a/gdb/bt-utils.h
+++ b/gdb/bt-utils.h
@@ -32,7 +32,7 @@
 
 #if defined HAVE_EXECINFO_H			\
   && defined HAVE_EXECINFO_BACKTRACE		\
-  && !defined PRINT_BACKTRACE_ON_FATAL_SIGNAL
+  && !defined GDB_PRINT_INTERNAL_BACKTRACE_USING_LIBBACKTRACE
 # include <execinfo.h>
 # define GDB_PRINT_INTERNAL_BACKTRACE
 # define GDB_PRINT_INTERNAL_BACKTRACE_USING_EXECINFO

base-commit: e24d337e219da287535eddc5c9918ac410d124be
-- 
2.25.4


                 reply	other threads:[~2023-01-04 11:51 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b77a357567b8640003a7301b1bd50bd81fd7a26a.1672833040.git.aburgess@redhat.com \
    --to=aburgess@redhat.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).