| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
I'd like to move some things so they become methods on struct ui. But
first, I think that struct ui and the related things are big enough to
deserve their own file, instead of being scattered through top.{c,h} and
event-top.c.
Change-Id: I15594269ace61fd76ef80a7b58f51ff3ab6979bc
|
|
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.
|
|
cmd_list_element can contain a pointer to data that can be set and / or
shown. This is achieved with the void* VAR member which points to the
data that can be accessed, while the VAR_TYPE member (of type enum
var_types) indicates how to interpret the data pointed to.
With this pattern, the user of the cmd_list_element needs to know what
is the storage type associated with a given VAR_TYPES in order to do
the proper casting. No automatic safeguard is available to prevent
miss-use of the pointer. Client code typically looks something like:
switch (c->var_type)
{
case var_zuinteger:
unsigned int v = *(unsigned int*) c->var;
...
break;
case var_boolean:
bool v = *(bool *) c->var;
...
break;
...
}
This patch proposes to add an abstraction around the var_types and void*
pointer pair. The abstraction is meant to prevent the user from having
to handle the cast and verify that the data is read or written as a type
that is coherent with the setting's var_type. This is achieved by
introducing the struct setting which exposes a set of templated get /
set member functions. The template parameter is the type of the
variable that holds the referred variable.
Using those accessors allows runtime checks to be inserted in order to
ensure that the data pointed to has the expected type. For example,
instantiating the member functions with bool will yield something
similar to:
const bool &get<bool> () const
{
gdb_assert (m_var_type == var_boolean);
gdb_assert (m_var != nullptr);
return *static_cast<bool *> (m_var);
}
void set<bool> (const bool &var)
{
gdb_assert (m_var_type == var_boolean);
gdb_assert (m_var != nullptr);
*static_cast<bool *> (m_var) = var;
}
Using the new abstraction, our initial example becomes:
switch (c->var_type)
{
case var_zuinteger:
unsigned int v = c->var->get<unsigned int> ();
...
break;
case var_boolean:
bool v = c->var->get<bool> ();
...
break;
...
}
While the call site is still similar, the introduction of runtime checks
help ensure correct usage of the data.
In order to avoid turning the bulk of add_setshow_cmd_full into a
templated function, and following a suggestion from Pedro Alves, a
setting can be constructed from a pre validated type erased reference to
a variable. This is what setting::erased_args is used for.
Introducing an opaque abstraction to describe a setting will also make
it possible to use callbacks to retrieve or set the value of the setting
on the fly instead of pointing to a static chunk of memory. This will
be done added in a later commit.
Given that a cmd_list_element may or may not reference a setting, the
VAR and VAR_TYPES members of the struct are replaced with a
gdb::optional<setting> named VAR.
Few internal function signatures have been modified to take into account
this new abstraction:
-The functions value_from_setting, str_value_from_setting and
get_setshow_command_value_string used to have a 'cmd_list_element *'
parameter but only used it for the VAR and VAR_TYPE member. They now
take a 'const setting &' parameter instead.
- Similarly, the 'void *' and a 'enum var_types' parameters of
pascm_param_value and gdbpy_parameter_value have been replaced with a
'const setting &' parameter.
No user visible change is expected after this patch.
Tested on GNU/Linux x86_64, with no regression noticed.
Co-authored-by: Simon Marchi <simon.marchi@polymtl.ca>
Change-Id: Ie1d08c3ceb8b30b3d7bf1efe036eb8acffcd2f34
|
|
When building master GDB, I ran into the following:
binutils-gdb/gdb/bt-utils.c: In function 'int libbacktrace_print(void*, uintptr_t, const char*, int, const char*)':
binutils-gdb/gdb/bt-utils.c:93:44: error: format '%lx' expects argument of type 'long unsigned int', but argument 4 has type 'uintptr_t {aka unsigned int}' [-Werror=format=]
snprintf (buf, sizeof (buf), "0x%lx ", pc);
Fix this by using %PRIxPTR as opposed to %lx.
|
|
In this commit:
commit abbbd4a3e0ca51132e7fb31a43f896d29894dae0
Date: Wed Aug 11 13:24:33 2021 +0100
gdb: use libbacktrace to create a better backtrace for fatal signals
The build of GDB was broken iff, the execinfo backtrace API is not
available, and, libbacktrace is either disabled, or not usable. In
this case you'll see build errors like this:
CXX bt-utils.o
/home/username/src/binutils-gdb/gdb/bt-utils.c: In function 'void gdb_internal_backtrace()':
/home/username/src/binutils-gdb/gdb/bt-utils.c:165:5: error: 'gdb_internal_backtrace_1' was not declared in this scope
gdb_internal_backtrace_1 ();
^~~~~~~~~~~~~~~~~~~~~~~~
This commit fixes the issue by guarding the call to
gdb_internal_backtrace_1 with '#ifdef GDB_PRINT_INTERNAL_BACKTRACE',
which is only defined when one of the backtrace libraries are
available.
|
|
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}.
|
