mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-06-27 06:17:47 +08:00
b77a357567
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.
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.