I noticed my IDE (VSCode) starting to automatically trim trailing
whitespaces on save, despite the setting for it being disabled. I
realized that this is because the .editorconfig file now has
trim_trailing_whitespace = true
for many file types. If we have this EditorConfig setting forcing
editors to trim trailing whitespaces, I think it would make sense to
clean up trailing whitespaces from our files. Otherwise, people will
always get spurious whitespace changes when editing these files.
I did a mass cleanup using this command:
$ find gdb gdbserver gdbsupport -type f \( \
-name "*.c" -o \
-name "*.h" -o \
-name "*.cc" -o \
-name "*.texi" -o \
-name "*.exp" -o \
-name "*.tcl" -o \
-name "*.py" -o \
-name "*.s" -o \
-name "*.S" -o \
-name "*.asm" -o \
-name "*.awk" -o \
-name "*.ac" -o \
-name "Makefile*" -o \
-name "*.sh" -o \
-name "*.adb" -o \
-name "*.ads" -o \
-name "*.d" -o \
-name "*.go" -o \
-name "*.F90" -o \
-name "*.f90" \
\) -exec sed -ri 's/[ \t]+$//' {} +
I then did an autotools regen, because we don't actually want to change
the Makefile and Makefile.in files that are generated.
Change-Id: I6f91b83e3b8c4dc7d5d51a2ebf60706120efe691
This patch introduces a new macro, INIT_GDB_FILE. This is used to
replace the current "_initialize_" idiom when introducing a per-file
initialization function. That is, rather than write:
void _initialize_something ();
void
_initialize_something ()
{
...
}
... now you would write:
INIT_GDB_FILE (something)
{
...
}
The macro handles both the declaration and definition of the function.
The point of this approach is that it makes it harder to accidentally
cause an initializer to be omitted; see commit 2711e475 ("Ensure
cooked_index_entry self-tests are run"). Specifically, the regexp now
used by make-init-c seems harder to trick.
New in v2: un-did some erroneous changes made by the script.
The bulk of this patch was written by script.
Regression tested on x86-64 Fedora 41.
This updates the copyright headers to include 2025. I did this by
running gdb/copyright.py and then manually modifying a few files as
noted by the script.
Approved-By: Eli Zaretskii <eliz@gnu.org>
Frame unwinders have historically been a structure populated with
callback pointers, so that architectures (or other specific unwinders)
could install their own way to handle the inferior. However, since
moving to C++, we could use polymorphism to get the same functionality
in a more readable way. Polymorphism also makes it simpler to add new
functionality to all frame unwinders, since all that's required is
adding it to the base class.
As part of the changes to add support to disabling frame unwinders,
this commit makes the first baby step in using polymorphism for the
frame unwinders, by making frame_unwind a virtual class, and adds a
couple of new classes. The main class added is frame_unwind_legacy,
which works the same as the previous structs, using function pointers
as callbacks. This class was added to allow the transition to happen
piecemeal. New unwinders should instead follow the lead of the other
classes implemented.
2 of the others, frame_unwind_python and frame_unwind_trampoline, were added
because it seemed simpler at the moment to do that instead of reworking
the dynamic allocation to work with the legacy class, and can be used as
an example to future implementations.
Finally, the cygwin unwinder was converted to a class since it was most
of the way there already.
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
A future patch will add a way to disable certain unwinders based on
different characteristics. This patch aims to make it more convenient
to disable related unwinders in bulk, such as architecture specific
ones, by identifying all unwinders by which part of the code adds it.
The classes, and explanations, are as follows:
* GDB: An internal unwinder, added by GDB core, such as the unwinder
for dummy frames;
* EXTENSION: Unwinders added by extension languages;
* DEBUGINFO: Unwinders installed by the debug info reader;
* ARCH: Unwinders installed by the architecture specific code.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
>From what I can see, lookup_minimal_symbol doesn't have any dependencies
on the global current state other than the single reference to
current_program_space. Add a program_space parameter and make that
current_program_space reference bubble up one level.
Change-Id: I759415e2f9c74c9627a2fe05bd44eb4147eee6fe
Reviewed-by: Keith Seitz <keiths@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
Most calls to lookup_minimal_symbol don't pass a value for sfile and
objf. Make these parameters optional (have a default value of
nullptr). And since passing a value to `objf` is much more common than
passing a value to `sfile`, swap the order so `objf` comes first, to
avoid having to pass a nullptr value to `sfile` when wanting to pass a
value to `objf`.
Change-Id: I8e9cc6b942e593bec640f9dfd30f62786b0f5a27
Reviewed-by: Keith Seitz <keiths@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
This is a simple find / replace from "struct bound_minimal_symbol" to
"bound_minimal_symbol", to make things shorter and more consisten
througout. In some cases, move variable declarations where first used.
Change-Id: Ica4af11c4ac528aa842bfa49a7afe8fe77a66849
Reviewed-by: Keith Seitz <keiths@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
Most files including gdbcmd.h currently rely on it to access things
actually declared in cli/cli-cmds.h (setlist, showlist, etc). To make
things easy, replace all includes of gdbcmd.h with includes of
cli/cli-cmds.h. This might lead to some unused includes of
cli/cli-cmds.h, but it's harmless, and much faster than going through
the 170 or so files by hand.
Change-Id: I11f884d4d616c12c05f395c98bbc2892950fb00f
Approved-By: Tom Tromey <tom@tromey.com>
Move the declarations out of defs.h, and the implementations out of
findvar.c.
I opted for a new file, because this functionality of converting
integers to bytes and vice-versa seems a bit to generic to live in
findvar.c.
Change-Id: I524858fca33901ee2150c582bac16042148d2251
Approved-By: John Baldwin <jhb@FreeBSD.org>
Now that defs.h, server.h and common-defs.h are included via the
`-include` option, it is no longer necessary for source files to include
them. Remove all the inclusions of these files I could find. Update
the generation scripts where relevant.
Change-Id: Ia026cff269c1b7ae7386dd3619bc9bb6a5332837
Approved-By: Pedro Alves <pedro@palves.net>
We currently pass frames to function by value, as `frame_info_ptr`.
This is somewhat expensive:
- the size of `frame_info_ptr` is 64 bytes, which is a bit big to pass
by value
- the constructors and destructor link/unlink the object in the global
`frame_info_ptr::frame_list` list. This is an `intrusive_list`, so
it's not so bad: it's just assigning a few points, there's no memory
allocation as if it was `std::list`, but still it's useless to do
that over and over.
As suggested by Tom Tromey, change many function signatures to accept
`const frame_info_ptr &` instead of `frame_info_ptr`.
Some functions reassign their `frame_info_ptr` parameter, like:
void
the_func (frame_info_ptr frame)
{
for (; frame != nullptr; frame = get_prev_frame (frame))
{
...
}
}
I wondered what to do about them, do I leave them as-is or change them
(and need to introduce a separate local variable that can be
re-assigned). I opted for the later for consistency. It might not be
clear why some functions take `const frame_info_ptr &` while others take
`frame_info_ptr`. Also, if a function took a `frame_info_ptr` because
it did re-assign its parameter, I doubt that we would think to change it
to `const frame_info_ptr &` should the implementation change such that
it doesn't need to take `frame_info_ptr` anymore. It seems better to
have a simple rule and apply it everywhere.
Change-Id: I59d10addef687d157f82ccf4d54f5dde9a963fd0
Approved-By: Andrew Burgess <aburgess@redhat.com>
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.
The next patch introduces a new variant of gdbarch_pseudo_register_write
that takes a frame instead of a regcache for implementations to write
raw registers. Rename to old one to make it clear it's deprecated.
Change-Id: If8872c89c6f8a1edfcab983eb064248fd5ff3115
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Since GDB now requires C++17, we don't need the internally maintained
gdb::optional implementation. This patch does the following replacing:
- gdb::optional -> std::optional
- gdb::in_place -> std::in_place
- #include "gdbsupport/gdb_optional.h" -> #include <optional>
This change has mostly been done automatically. One exception is
gdbsupport/thread-pool.* which did not use the gdb:: prefix as it
already lives in the gdb namespace.
Change-Id: I19a92fa03e89637bab136c72e34fd351524f65e9
Approved-By: Tom Tromey <tom@tromey.com>
Approved-By: Pedro Alves <pedro@palves.net>
This turns the remaining value_contents functions -- value_contents,
value_contents_all, value_contents_for_printing, and
value_contents_for_printing_const -- into methods of value. It also
converts the static functions require_not_optimized_out and
require_available to be private methods.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
It's currently not clear how the ownership of gdbarch_tdep objects
works. In fact, nothing ever takes ownership of it. This is mostly
fine because we never free gdbarch objects, and thus we never free
gdbarch_tdep objects. There is an exception to that however: when
initialization fails, we do free the gdbarch object that is not going to
be used, and we free the tdep too. Currently, i386 and s390 do it.
To make things clearer, change gdbarch_alloc so that it takes ownership
of the tdep. The tdep is thus automatically freed if the gdbarch is
freed.
Change all gdbarch initialization functions to pass a new gdbarch_tdep
object to gdbarch_alloc and then retrieve a non-owning reference from
the gdbarch object.
Before this patch, the xtensa architecture had a single global instance
of xtensa_gdbarch_tdep. Since we need to pass a dynamically allocated
gdbarch_tdep_base instance to gdbarch_alloc, remove this global
instance, and dynamically allocate one as needed, like we do for all
other architectures. Make the `rmap` array externally visible and
rename it to the less collision-prone `xtensa_rmap` name.
Change-Id: Id3d70493ef80ce4bdff701c57636f4c79ed8aea2
Approved-By: Andrew Burgess <aburgess@redhat.com>
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.
Currently, every internal_error call must be passed __FILE__/__LINE__
explicitly, like:
internal_error (__FILE__, __LINE__, "foo %d", var);
The need to pass in explicit __FILE__/__LINE__ is there probably
because the function predates widespread and portable variadic macros
availability. We can use variadic macros nowadays, and in fact, we
already use them in several places, including the related
gdb_assert_not_reached.
So this patch renames the internal_error function to something else,
and then reimplements internal_error as a variadic macro that expands
__FILE__/__LINE__ itself.
The result is that we now should call internal_error like so:
internal_error ("foo %d", var);
Likewise for internal_warning.
The patch adjusts all calls sites. 99% of the adjustments were done
with a perl/sed script.
The non-mechanical changes are in gdbsupport/errors.h,
gdbsupport/gdb_assert.h, and gdb/gdbarch.py.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: Ia6f372c11550ca876829e8fd85048f4502bdcf06
This changes GDB to use frame_info_ptr instead of frame_info *
The substitution was done with multiple sequential `sed` commands:
sed 's/^struct frame_info;/class frame_info_ptr;/'
sed 's/struct frame_info \*/frame_info_ptr /g' - which left some
issues in a few files, that were manually fixed.
sed 's/\<frame_info \*/frame_info_ptr /g'
sed 's/frame_info_ptr $/frame_info_ptr/g' - used to remove whitespace
problems.
The changed files were then manually checked and some 'sed' changes
undone, some constructors and some gets were added, according to what
made sense, and what Tromey originally did
Co-Authored-By: Bruno Larsen <blarsen@redhat.com>
Approved-by: Tom Tomey <tom@tromey.com>
Building on the previous commits, this commit goes through the various
gdbarch_register_name methods and removes all the remaining 'return
NULL' cases, I claim that these either couldn't be hit, or should be
returning the empty string.
In all cases the return of NULL was used if the register number being
passed to gdbarch_register_name was "invalid", i.e. negative, or
greater than the total number of declared registers. I don't believe
either of these cases can occur, and the previous commit asserts that
this is the case. As a result we can simplify the code by removing
these checks. In many cases, where the register names are held in an
array, I was able to add a static assert that the array contains the
correct number of strings, after that, a direct access into the array
is fine.
I don't have any means of testing these changes.
After the commit:
commit 08106042d9
Date: Thu May 19 13:20:17 2022 +0100
gdb: move the type cast into gdbarch_tdep
GDB would no longer build using g++ 4.8. The issue appears to be some
confusion caused by GDB having 'struct gdbarch_tdep', but also a
templated function called 'gdbarch_tdep'. Prior to the above commit
the gdbarch_tdep function was not templated, and this compiled just
fine. Note that the above commit compiles just fine with later
versions of g++, so this issue was clearly fixed at some point, though
I've not tried to track down exactly when.
In this commit I propose to fix the g++ 4.8 build problem by renaming
'struct gdbarch_tdep' to 'struct gdbarch_tdep_base'. This rename
better represents that the struct is only ever used as a base class,
and removes the overloading of the name, which allows GDB to build
with g++ 4.8.
I've also updated the comment on 'struct gdbarch_tdep_base' to fix a
typo, and the comment on the 'gdbarch_tdep' function, to mention that
in maintainer mode a run-time type check is performed.
I built GDB for all targets on a x86-64/GNU-Linux system, and
then (accidentally) passed GDB a RISC-V binary, and asked GDB to "run"
the binary on the native target. I got this error:
(gdb) show architecture
The target architecture is set to "auto" (currently "i386").
(gdb) file /tmp/hello.rv32.exe
Reading symbols from /tmp/hello.rv32.exe...
(gdb) show architecture
The target architecture is set to "auto" (currently "riscv:rv32").
(gdb) run
Starting program: /tmp/hello.rv32.exe
../../src/gdb/i387-tdep.c:596: internal-error: i387_supply_fxsave: Assertion `tdep->st0_regnum >= I386_ST0_REGNUM' failed.
What's going on here is this; initially the architecture is i386, this
is based on the default architecture, which is set based on the native
target. After loading the RISC-V executable the architecture of the
current inferior is updated based on the architecture of the
executable.
When we "run", GDB does a fork & exec, with the inferior being
controlled through ptrace. GDB sees an initial stop from the inferior
as soon as the inferior comes to life. In response to this stop GDB
ends up calling save_stop_reason (linux-nat.c), which ends up trying
to read register from the inferior, to do this we end up calling
target_ops::fetch_registers, which, for the x86-64 native target,
calls amd64_linux_nat_target::fetch_registers.
After this I eventually end up in i387_supply_fxsave, different x86
based targets will end in different functions to fetch registers, but
it doesn't really matter which function we end up in, the problem is
this line, which is repeated in many places:
i386_gdbarch_tdep *tdep = (i386_gdbarch_tdep *) gdbarch_tdep (arch);
The problem here is that the ARCH in this line comes from the current
inferior, which, as we discussed above, will be a RISC-V gdbarch, the
tdep field will actually be of type riscv_gdbarch_tdep, not
i386_gdbarch_tdep. After this cast we are relying on undefined
behaviour, in my case I happen to trigger an assert, but this might
not always be the case.
The thing I tried that exposed this problem was of course, trying to
start an executable of the wrong architecture on a native target. I
don't think that the correct solution for this problem is to detect,
at the point of cast, that the gdbarch_tdep object is of the wrong
type, but, I did wonder, is there a way that we could protect
ourselves from incorrectly casting the gdbarch_tdep object?
I think that there is something we can do here, and this commit is the
first step in that direction, though no actual check is added by this
commit.
This commit can be split into two parts:
(1) In gdbarch.h and arch-utils.c. In these files I have modified
gdbarch_tdep (the function) so that it now takes a template argument,
like this:
template<typename TDepType>
static inline TDepType *
gdbarch_tdep (struct gdbarch *gdbarch)
{
struct gdbarch_tdep *tdep = gdbarch_tdep_1 (gdbarch);
return static_cast<TDepType *> (tdep);
}
After this change we are no better protected, but the cast is now
done within the gdbarch_tdep function rather than at the call sites,
this leads to the second, much larger change in this commit,
(2) Everywhere gdbarch_tdep is called, we make changes like this:
- i386_gdbarch_tdep *tdep = (i386_gdbarch_tdep *) gdbarch_tdep (arch);
+ i386_gdbarch_tdep *tdep = gdbarch_tdep<i386_gdbarch_tdep> (arch);
There should be no functional change after this commit.
In the next commit I will build on this change to add an assertion in
gdbarch_tdep that checks we are casting to the correct type.
Now that filtered and unfiltered output can be treated identically, we
can unify the printf family of functions. This is done under the name
"gdb_printf". Most of this patch was written by script.
Various targets introduce their own commands, which then use
unfiltered output. It's better to use filtered output by default, so
this patch fixes the instances I found.
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.
avr_io_reg_read_command is an ordinary gdb command, and so should not
be calling reinitialize_more_filter. This patch removes it. I'm
checking this in as obvious. Tested by rebuilding.
Commit 345bd07cce ("gdb: fix gdbarch_tdep ODR violation") made a bunch
of files define a *_gdbarch_tdep class that inherits from a gdbarch_tdep
base. But some of these files don't include gdbarch.h, where
gdbarch_tdep is defined. This may cause build errors if gdbarch.h isn't
already included by chance by some other header file. Avoid this by
making them include gdbarch.h.
Change-Id: If433d302007e274daa4f656cfc94f769cf1aa68a
I would like to be able to use non-trivial types in gdbarch_tdep types.
This is not possible at the moment (in theory), because of the one
definition rule.
To allow it, rename all gdbarch_tdep types to <arch>_gdbarch_tdep, and
make them inherit from a gdbarch_tdep base class. The inheritance is
necessary to be able to pass pointers to all these <arch>_gdbarch_tdep
objects to gdbarch_alloc, which takes a pointer to gdbarch_tdep.
These objects are never deleted through a base class pointer, so I
didn't include a virtual destructor. In the future, if gdbarch objects
deletable, I could imagine that the gdbarch_tdep objects could become
owned by the gdbarch objects, and then it would become useful to have a
virtual destructor (so that the gdbarch object can delete the owned
gdbarch_tdep object). But that's not necessary right now.
It turns out that RISC-V already has a gdbarch_tdep that is
non-default-constructible, so that provides a good motivation for this
change.
Most changes are fairly straightforward, mostly needing to add some
casts all over the place. There is however the xtensa architecture,
doing its own little weird thing to define its gdbarch_tdep. I did my
best to adapt it, but I can't test those changes.
Change-Id: Ic001903f91ddd106bd6ca09a79dabe8df2d69f3b
The bug fixed by this [1] patch was caused by an out-of-bounds access to
a value's content. The code gets the value's content (just a pointer)
and then indexes it with a non-sensical index.
This made me think of changing functions that return value contents to
return array_views instead of a plain pointer. This has the advantage
that when GDB is built with _GLIBCXX_DEBUG, accesses to the array_view
are checked, making bugs more apparent / easier to find.
This patch changes the return types of these functions, and updates
callers to call .data() on the result, meaning it's not changing
anything in practice. Additional work will be needed (which can be done
little by little) to make callers propagate the use of array_view and
reap the benefits.
[1] https://sourceware.org/pipermail/gdb-patches/2021-September/182306.html
Change-Id: I5151f888f169e1c36abe2cbc57620110673816f3
I wrote this while debugging a problem where the expected unwinder for a
frame wasn't used. It adds messages to show which unwinders are
considered for a frame, why they are not selected (if an exception is
thrown), and finally which unwinder is selected in the end.
To be able to show a meaningful, human-readable name for the unwinders,
add a "name" field to struct frame_unwind, and update all instances to
include a name.
Here's an example of the output:
[frame] frame_unwind_find_by_frame: this_frame=0
[frame] frame_unwind_try_unwinder: trying unwinder "dummy"
[frame] frame_unwind_try_unwinder: no
[frame] frame_unwind_try_unwinder: trying unwinder "dwarf2 tailcall"
[frame] frame_unwind_try_unwinder: no
[frame] frame_unwind_try_unwinder: trying unwinder "inline"
[frame] frame_unwind_try_unwinder: no
[frame] frame_unwind_try_unwinder: trying unwinder "jit"
[frame] frame_unwind_try_unwinder: no
[frame] frame_unwind_try_unwinder: trying unwinder "python"
[frame] frame_unwind_try_unwinder: no
[frame] frame_unwind_try_unwinder: trying unwinder "amd64 epilogue"
[frame] frame_unwind_try_unwinder: no
[frame] frame_unwind_try_unwinder: trying unwinder "i386 epilogue"
[frame] frame_unwind_try_unwinder: no
[frame] frame_unwind_try_unwinder: trying unwinder "dwarf2"
[frame] frame_unwind_try_unwinder: yes
gdb/ChangeLog:
* frame-unwind.h (struct frame_unwind) <name>: New. Update
instances everywhere to include this field.
* frame-unwind.c (frame_unwind_try_unwinder,
frame_unwind_find_by_frame): Add debug messages.
Change-Id: I813f17777422425f0d08b22499817b23922e8ddb
When trying to do pretty much anything that requires unwinding a frame
on AVR, we get
/home/simark/src/wt/avr/gdb/trad-frame.h:143: internal-error: LONGEST trad_frame_saved_reg::addr() const: Assertion `m_kind == trad_frame_saved_reg_kind::ADDR' failed.
This is likely coming from the trad-frame refactor in 098caef485
("Refactor struct trad_frame_saved_regs"). Here's an example of how to
reproduce it:
In one terminal:
$ cat test.c
int foo(int x)
{
return x * 7;
}
int main() {
return foo(2);
}
$ avr-gcc -gdwarf-4 -mmcu=atmega2560 test.c
$ /tmp/simavr/bin/simavr --mcu atmega2560 -g a.out
Loaded 330 .text at address 0x0
Loaded 0 .data
And in another one:
$ ./gdb -q -nx --data-directory=data-directory a.out -ex "tar rem :1234" -ex "b foo" -ex c -ex bt
Reading symbols from a.out...
Remote debugging using :1234
0x00000000 in __vectors ()
Breakpoint 1 at 0x110: file test.c, line 3.
Note: automatically using hardware breakpoints for read-only addresses.
Continuing.
Breakpoint 1, foo (x=2) at test.c:3
3 return x * 7;
#0 foo (x=2) at test.c:3
/home/simark/src/wt/avr/gdb/trad-frame.h:143: internal-error: LONGEST trad_frame_saved_reg::addr() const: Assertion `m_kind == trad_frame_saved_reg_kind::ADDR' failed.
What the AVR code does is:
1. In avr_scan_prologue, in the block that says "First stage of the
prologue scanning.", look for "push rX" instructions and note that rX
is saved on the stack. But instead of putting the actual stack
address directly, it puts an offset (from the previous frame's sp).
2. Back in avr_frame_unwind_cache, in the block that says "Adjust all
the saved registers", adjust all these values to be real stack
addresses.
To check whether a register was assigned an address (and therefore if it
needs adjustment), the code does:
if (info->saved_regs[i].addr () > 0)
Since commit 098caef485, it's invalid to call the `addr` getter of
trad_frame_saved_reg if the register hasn't been assigned an address.
Instead, the code could use the `is_addr` getter to verify if the
register has been assigned an address. This is what this patch does.
gdb/ChangeLog:
* avr-tdep.c (avr_frame_unwind_cache): Use
trad_frame_saved_reg::is_addr.
Change-Id: I5803089160b829400178746c5e3bca0c1cd11c00
The current_top_target function is a hidden dependency on the current
inferior. Since I'd like to slowly move towards reducing our dependency
on the global current state, remove this function and make callers use
current_inferior ()->top_target ()
There is no expected change in behavior, but this one step towards
making those callers use the inferior from their context, rather than
refer to the global current inferior.
gdb/ChangeLog:
* target.h (current_top_target): Remove, make callers use the
current inferior instead.
* target.c (current_top_target): Remove.
Change-Id: Iccd457036f84466cdaa3865aa3f9339a24ea001d
With the new member functions for struct trad_frame_saved_reg, there is no
need to invoke some of the set/get functions anymore. This patch removes
those and adjusts all callers.
Even though the most natural initial state of a saved register value is
UNKNOWN, there are target backends relying on the previous initial state
of REALREG set to a register's own number. I noticed this in at least a
couple targets: aarch64 and riscv.
Because of that, I decided to keep the reset function that sets the set of
register values to REALREG. I can't exercise all the targets to make sure
the initial state change won't break things, hence why it is risky to change
the default.
Validated with --enable-targets=all on aarch64-linux Ubuntu 18.04/20.04.
gdb/ChangeLog
2021-01-19 Luis Machado <luis.machado@linaro.org>
* trad-frame.h (trad_frame_saved_reg) <set_value_bytes>: Allocate
memory and save data.
(trad_frame_set_value, trad_frame_set_realreg, trad_frame_set_addr)
(trad_frame_set_unknown, trad_frame_set_value_bytes)
(trad_frame_value_p, trad_frame_addr_p, trad_frame_realreg_p)
(trad_frame_value_bytes_p): Remove.
(trad_frame_reset_saved_regs): Adjust documentation.
* trad-frame.c (trad_frame_alloc_saved_regs): Initialize via a
constructor and reset the state of the registers.
(trad_frame_value_p, trad_frame_addr_p, trad_frame_realreg_p)
(trad_frame_value_bytes_p, trad_frame_set_value)
(trad_frame_set_realreg, trad_frame_set_addr)
(trad_frame_set_unknown, trad_frame_set_value_bytes): Remove.
(trad_frame_set_reg_realreg): Update to call member function.
(trad_frame_set_reg_addr, trad_frame_set_reg_value_bytes): Likewise.
(trad_frame_get_prev_register): Likewise.
* aarch64-tdep.c (aarch64_analyze_prologue)
(aarch64_analyze_prologue_test, aarch64_make_prologue_cache_1)
(aarch64_prologue_prev_register): Update to use member functions.
* alpha-mdebug-tdep.c (alpha_mdebug_frame_unwind_cache): Likewise.
* alpha-tdep.c (alpha_heuristic_frame_unwind_cache): Likewise.
* arc-tdep.c (arc_print_frame_cache, arc_make_frame_cache): Likewise.
* arm-tdep.c (arm_make_prologue_cache, arm_exidx_fill_cache)
(arm_make_epilogue_frame_cache): Likewise.
* avr-tdep.c (avr_frame_unwind_cache)
(avr_frame_prev_register): Likewise.
* cris-tdep.c (cris_scan_prologue): Likewise.
* csky-tdep.c (csky_frame_unwind_cache): Likewise.
* frv-tdep.c (frv_analyze_prologue): Likewise.
* hppa-tdep.c (hppa_frame_cache, hppa_fallback_frame_cache): Likewise.
* lm32-tdep.c (lm32_frame_cache): Likewise.
* m32r-tdep.c (m32r_frame_unwind_cache): Likewise.
* m68hc11-tdep.c (m68hc11_frame_unwind_cache): Likewise.
* mips-tdep.c (set_reg_offset, mips_insn16_frame_cache)
(mips_micro_frame_cache, mips_insn32_frame_cache): Likewise.
(reset_saved_regs): Adjust to set realreg.
* riscv-tdep.c (riscv_scan_prologue, riscv_frame_cache): Adjust to
call member functions.
* rs6000-tdep.c (rs6000_frame_cache, rs6000_epilogue_frame_cache)
* s390-tdep.c (s390_prologue_frame_unwind_cache)
(s390_backchain_frame_unwind_cache): Likewise.
* score-tdep.c (score7_analyze_prologue)
(score3_analyze_prologue, score_make_prologue_cache): Likewise.
* sparc-netbsd-tdep.c (sparc32nbsd_sigcontext_saved_regs): Likewise.
* sparc-sol2-tdep.c (sparc32_sol2_sigtramp_frame_cache): Likewise.
* sparc64-netbsd-tdep.c (sparc64nbsd_sigcontext_saved_regs): Likewise.
* sparc64-sol2-tdep.c (sparc64_sol2_sigtramp_frame_cache): Likewise.
* tilegx-tdep.c (tilegx_analyze_prologue)
(tilegx_frame_cache): Likewise.
* v850-tdep.c (v850_frame_cache): Likewise.
* vax-tdep.c (vax_frame_cache): Likewise.
The following patch drops the overloading going on with the trad_frame_saved_reg
struct and defines a new struct with a KIND enum and a union of different
fields.
The new struct looks like this:
struct trad_frame_saved_reg
{
setters/getters
...
private:
trad_frame_saved_reg_kind m_kind;
union {
LONGEST value;
int realreg;
LONGEST addr;
const gdb_byte *value_bytes;
} m_reg;
};
And the enums look like this:
/* Describes the kind of encoding a stored register has. */
enum class trad_frame_saved_reg_kind
{
/* Register value is unknown. */
UNKNOWN = 0,
/* Register value is a constant. */
VALUE,
/* Register value is in another register. */
REALREG,
/* Register value is at an address. */
ADDR,
/* Register value is a sequence of bytes. */
VALUE_BYTES
};
The patch also adds setters/getters and updates all the users of the old
struct.
It is worth mentioning that due to the previous overloaded nature of the
fields, some tdep files like to store negative offsets and indexes in the ADDR
field, so I kept the ADDR as LONGEST instead of CORE_ADDR. Those cases may
be better supported by a new enum entry.
I have not addressed those cases in this patch to prevent unwanted breakage,
given I have no way to test some of the targets. But it would be nice to
clean those up eventually.
The change to frame-unwind.* is to constify the parameter being passed to the
unwinding functions, given we now accept a "const gdb_byte *" for value bytes.
Tested on aarch64-linux/Ubuntu 20.04/18.04 and by building GDB with
--enable-targets=all.
gdb/ChangeLog:
2021-01-04 Luis Machado <luis.machado@linaro.org>
Update all users of trad_frame_saved_reg to use the new member
functions.
Remote all struct keywords from declarations of trad_frame_saved_reg
types, except on forward declarations.
* aarch64-tdep.c: Update.
* alpha-mdebug-tdep.c: Update.
* alpha-tdep.c: Update.
* arc-tdep.c: Update.
* arm-tdep.c: Update.
* avr-tdep.c: Update.
* cris-tdep.c: Update.
* csky-tdep.c: Update.
* frv-tdep.c: Update.
* hppa-linux-tdep.c: Update.
* hppa-tdep.c: Update.
* hppa-tdep.h: Update.
* lm32-tdep.c: Update.
* m32r-linux-tdep.c: Update.
* m32r-tdep.c: Update.
* m68hc11-tdep.c: Update.
* mips-tdep.c: Update.
* moxie-tdep.c: Update.
* riscv-tdep.c: Update.
* rs6000-tdep.c: Update.
* s390-linux-tdep.c: Update.
* s390-tdep.c: Update.
* score-tdep.c: Update.
* sparc-netbsd-tdep.c: Update.
* sparc-sol2-tdep.c: Update.
* sparc64-fbsd-tdep.c: Update.
* sparc64-netbsd-tdep.c: Update.
* sparc64-obsd-tdep.c: Update.
* sparc64-sol2-tdep.c: Update.
* tilegx-tdep.c: Update.
* v850-tdep.c: Update.
* vax-tdep.c: Update.
* frame-unwind.c (frame_unwind_got_bytes): Make parameter const.
* frame-unwind.h (frame_unwind_got_bytes): Likewise.
* trad-frame.c: Update.
Remove TF_REG_* enum.
(trad_frame_alloc_saved_regs): Add a static assertion to check for
a trivially-constructible struct.
(trad_frame_reset_saved_regs): Adjust to use member function.
(trad_frame_value_p): Likewise.
(trad_frame_addr_p): Likewise.
(trad_frame_realreg_p): Likewise.
(trad_frame_value_bytes_p): Likewise.
(trad_frame_set_value): Likewise.
(trad_frame_set_realreg): Likewise.
(trad_frame_set_addr): Likewise.
(trad_frame_set_unknown): Likewise.
(trad_frame_set_value_bytes): Likewise.
(trad_frame_get_prev_register): Likewise.
* trad-frame.h: Update.
(trad_frame_saved_reg_kind): New enum.
(struct trad_frame_saved_reg) <addr, realreg, data>: Remove.
<m_kind, m_reg>: New member fields.
<set_value, set_realreg, set_addr, set_unknown, set_value_bytes>
<kind, value, realreg, addr, value_bytes, is_value, is_realreg>
<is_addr, is_unknown, is_value_bytes>: New member functions.
This commits the result of running gdb/copyright.py as per our Start
of New Year procedure...
gdb/ChangeLog
Update copyright year range in copyright header of all GDB files.
A later patch in this series will rewrite enum_flags fixing some API
holes. That would cause build failures around code using
type_instance_flags. Or rather, that should be using it, but wasn't.
This patch fixes it by using type_instance_flags throughout instead of
plain integers.
Note that we can't make the seemingly obvious change to struct
type::instance_flags:
- unsigned instance_flags : 9;
+ ENUM_BITFIELD (type_instance_flag_value) instance_flags : 9;
Because G++ complains then that 9 bits isn't sufficient for holding
all values of type_instance_flag_value.
So the patch adds an type::instance_flags() method, which takes care
of casting appropriately, and adds a separate type::set_instance_flags
method, following the pattern of the ongoing TYPE_XXX macro
elimination. This converts uses of TYPE_INSTANCE_FLAGS to
type::instance_flags() in the places where the code was already being
touched, but there are still many references to the
TYPE_INSTANCE_FLAGS macro left behind. Those could/should be fully
replaced at some point.
gdb/ChangeLog:
* avr-tdep.c (avr_address_class_type_flags): Return
type_instance_flags.
(avr_address_class_type_flags_to_name): Take a
type_instance_flags.
(avr_address_class_name_to_type_flags): Return bool and take a
type_instance_flags.
* d-lang.c (build_d_types): Use type::set_instance_flags.
* ft32-tdep.c (ft32_address_class_type_flags): Return
type_instance_flags.
(ft32_address_class_type_flags_to_name): Take a
type_instance_flags.
(ft32_address_class_name_to_type_flags): Return bool and take a
type_instance_flags.
(ft32_gdbarch_init): Use type::set_instance_flags.
* eval.c (fake_method::fake_method): Use type::set_instance_flags.
* gdbarch.h, gdbarch.c: Regenerate.
* gdbarch.sh (address_class_type_flags): Use type_instance_flags.
(address_class_name_to_type_flags): Use type_instance_flags and
bool.
* gdbtypes.c (address_space_name_to_int)
(address_space_int_to_name, make_qualified_type): Use
type_instance_flags.
(make_qualified_type): Use type_instance_flags and
type::set_instance_flags.
(make_type_with_address_space, make_cv_type, make_vector_type)
(check_typedef): Use type_instance_flags.
(recursive_dump_type): Cast type_instance_flags to unsigned for
printing.
(copy_type_recursive): Use type::set_instance_flags.
(gdbtypes_post_init): Use type::set_instance_flags.
* gdbtypes.h (struct type) <instance_flags>: Rename to ...
<m_instance_flags>: ... this.
<instance_flags, set_instance_flags>: New methods.
(TYPE_INSTANCE_FLAGS): Use the instance_flags method.
(SET_TYPE_INSTANCE_FLAGS): New.
(address_space_name_to_int, address_space_int_to_name)
(make_type_with_address_space): Pass flags using
type_instance_flags instead of int.
* stabsread.c (cleanup_undefined_types_noname): Use
type::set_instance_flags.
* s390-tdep.c (s390_address_class_type_flags): Return
type_instance_flags.
(s390_address_class_type_flags_to_name): Take a
type_instance_flags.
(s390_address_class_name_to_type_flags): Return bool and take a
type_instance_flags.
* type-stack.c (type_stack::follow_types): Use
type_instance_flags.
* dwarf2/read.c (read_tag_pointer_type): Use type_instance_flags.
The AVR architecture is a Harvard one, meaning it has different memory
spaces for code and data. In GDB, this is dealt with by having the data
(SRAM) addresses start at 0x00800000. When interpreting an integer as
an address (converting to a CORE_ADDR), we currently always generate a
data address. This doesn't work for some cases described below, where
the integer is meant to represent a code address.
This patch changes avr_integer_to_address so that it generates the
correct type of address (code or data) based on the passed type.
Using the simavr.exp board, I didn't see any regressions when running
the gdb.base/*.exp tests. A few tests go from fail to pass, but none
from pass to fail. There are a few new fails and unresolved, but it's
just because some tests manage to make more progress before failing in a
different way.
In practice, it fixes disassembling by address, as described in the PR:
- (gdb) disassemble 0x12a,0x12b
- Dump of assembler code from 0x12a to 0x12b:
- 0x0000012a <main+0>: push r28
- End of assembler dump.
+ (gdb) disassemble 0x12a,0x12b
+ Dump of assembler code from 0x80012a to 0x80012b:
+ 0x0080012a: nop
+ End of assembler dump.
And also, setting a breakpoint by address:
- (gdb) p &main
- $1 = (int (*)(void)) 0x12a <main>
- (gdb) b *0x12a
- Breakpoint 1 at 0x80012a
+ (gdb) p &main
+ $1 = (int (*)(void)) 0x12a <main>
+ (gdb) b *0x12a
+ Breakpoint 1 at 0x12a: file test-avr.c, line 3.
+ Note: automatically using hardware breakpoints for read-only addresses.
gdb/ChangeLog:
PR gdb/13519
* avr-tdep.c (avr_integer_to_address): Return data or code
address accordingly to the second 'type' argument of the
function.
Change-Id: Iaea1587d053e86f4ab8aebdcabec8d31a6d262cd
Remove TYPE_CODE, changing all the call sites to use type::code
directly. This is quite a big diff, but this was mostly done using sed
and coccinelle. A few call sites were done by hand.
gdb/ChangeLog:
* gdbtypes.h (TYPE_CODE): Remove. Change all call sites to use
type::code instead.
