It can easily happen that the signal handler function
`handle_fatal_signal` uses various signal unsafe functions.
The problematic functions are `_` and `strsignal` which
can be pre-computed after the `setlocale` call is done.
Unfortunately when compiled with --disable-libbacktrace a
different code path is used, that calls the glibc function
`backtrace` which calls `malloc` and `free` and is therefore
also signal unsafe, that is probably unfixable, so there
is no attempt to fix anything in this code path.
Approved-By: Andrew Burgess <aburgess@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31713#c9
This commit is the result of the following actions:
- Running gdb/copyright.py to update all of the copyright headers to
include 2024,
- Manually updating a few files the copyright.py script told me to
update, these files had copyright headers embedded within the
file,
- Regenerating gdbsupport/Makefile.in to refresh it's copyright
date,
- Using grep to find other files that still mentioned 2023. If
these files were updated last year from 2022 to 2023 then I've
updated them this year to 2024.
I'm sure I've probably missed some dates. Feel free to fix them up as
you spot them.
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 abbbd4a3e0
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.
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
Right now, gdb's self-backtrace feature will still print something
when a backtrace is unavailable:
sig_write (_("----- Backtrace -----\n"));
[...]
sig_write (_("Backtrace unavailable\n"));
sig_write ("---------------------\n");
However, if GDB_PRINT_INTERNAL_BACKTRACE is undefined, it seems better
to me to print nothing at all.
This patch implements this change. It also makes a couple of other
small changes in this same module: it adds a header guard to
bt-utils.h, and it protects the definitions of
gdb_internal_backtrace_1 with a check of GDB_PRINT_INTERNAL_BACKTRACE.
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.
For the avoidance of doubt, all changes in this commits were
performed by the script.
In a recent commit I used 'manor' in some comments rather than
'manner'. This commit fixes those two mistakes.
I also looked through the gdb/ tree and found one additional instance
of this mistake that this commit also fixes.
GDB recently gained the ability to print a backtrace when a fatal
signal is encountered. This backtrace is produced using the backtrace
and backtrace_symbols_fd API available in glibc.
However, in order for this API to actually map addresses to symbol
names it is required that the application (GDB) be compiled with
-rdynamic, which GDB is not by default.
As a result, the backtrace produced often looks like this:
Fatal signal: Bus error
----- Backtrace -----
./gdb/gdb[0x80ec00]
./gdb/gdb[0x80ed56]
/lib64/libc.so.6(+0x3c6b0)[0x7fc2ce1936b0]
/lib64/libc.so.6(__poll+0x4f)[0x7fc2ce24da5f]
./gdb/gdb[0x15495ba]
./gdb/gdb[0x15489b8]
./gdb/gdb[0x9b794d]
./gdb/gdb[0x9b7a6d]
./gdb/gdb[0x9b943b]
./gdb/gdb[0x9b94a1]
./gdb/gdb[0x4175dd]
/lib64/libc.so.6(__libc_start_main+0xf3)[0x7fc2ce17e1a3]
./gdb/gdb[0x4174de]
---------------------
This is OK if you have access to the exact same build of GDB, you can
manually map the addresses back to symbols, however, it is next to
useless if all you have is a backtrace copied into a bug report.
GCC uses libbacktrace for printing a backtrace when it encounters an
error. In recent commits I added this library into the binutils-gdb
repository, and in this commit I allow this library to be used by
GDB. Now (when GDB is compiled with debug information) the backtrace
looks like this:
----- Backtrace -----
0x80ee08 gdb_internal_backtrace
../../src/gdb/event-top.c:989
0x80ef0b handle_fatal_signal
../../src/gdb/event-top.c:1036
0x7f24539dd6af ???
0x7f2453a97a5f ???
0x154976f gdb_wait_for_event
../../src/gdbsupport/event-loop.cc:613
0x1548b6d _Z16gdb_do_one_eventv
../../src/gdbsupport/event-loop.cc:237
0x9b7b02 start_event_loop
../../src/gdb/main.c:421
0x9b7c22 captured_command_loop
../../src/gdb/main.c:481
0x9b95f0 captured_main
../../src/gdb/main.c:1353
0x9b9656 _Z8gdb_mainP18captured_main_args
../../src/gdb/main.c:1368
0x4175ec main
../../src/gdb/gdb.c:32
---------------------
Which seems much more useful.
Use of libbacktrace is optional. If GDB is configured with
--disable-libbacktrace then the libbacktrace directory will not be
built, and GDB will not try to use this library. In this case GDB
would try to use the old backtrace and backtrace_symbols_fd API.
All of the functions related to writing the backtrace of GDB itself
have been moved into the new files gdb/by-utils.{c,h}.
