A recent patch from Andrew pointed out that gdbarch_inner_than returns
'int', while it should really return 'bool'.
Approved-By: Pedro Alves <pedro@palves.net>
In another patch I'm working on I needed to ask: does the stack grow
down, or grow up?
Looking around I found in infcall.c some code where we needed to ask
the same question, what we do there is ask:
gdbarch_inner_than (gdbarch, 1, 2)
which should do the job. However, I don't particularly like copying
this, it feels like we're asking something slightly different that
just happens to align with the question we're actually asking.
I propose adding a new function `gdbarch_stack_grows_down`. This is
not going to be a gdbarch method that can be overridden, instead, this
will just call the gdbarch_inner_than function. We already have some
gdbarch methods like this, checkout arch-utils.c for examples.
I think it's now clearer what we're actually doing.
A new self-test ensures that all architectures have a stack that
either grows down, or grows up.
There should be no user visible changes after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
I don't like the name `target_so_ops`, because:
- The name `target` is so overloaded, and in this case it's not even
related to target_ops or anything else called "target".
- We do have an implementation that actually fetches solibs from the
target (solib_target_so_op in solib-target.c), so it's confusing for
the "base class" to be called target_something as well.
Rename to solib_ops.
Change-Id: I46a983d44e81400470e22deb09aaf26ad8a3587f
Approved-By: Tom Tromey <tom@tromey.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.
tdesc_data is not part of a union, since commit 4f3681cc33 ("Fix thread's
gdbarch when SVE vector length changes"). Remove the stale comment and
constructor.
Change-Id: Ie895ce36614930e8bd9c4967174c8bf1b321c503
This function is just a wrapper around the current inferior's gdbarch.
I find that having that wrapper just obscures where the arch is coming
from, and that it's often used as "I don't know which arch to use so
I'll use this magical target_gdbarch function that gets me an arch" when
the arch should in fact come from something in the context (a thread,
objfile, symbol, etc). I think that removing it and inlining
`current_inferior ()->arch ()` everywhere will make it a bit clearer
where that arch comes from and will trigger people into reflecting
whether this is the right place to get the arch or not.
Change-Id: I79f14b4e4934c88f91ca3a3155f5fc3ea2fadf6b
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
set_target_gdbarch is basically a setter for the current inferior's
arch, that notifies other parts of GDB of the architecture change. Move
the code of set_target_gdbarch to the inferior::set_arch method.
Add gdbarch_initialized_p, so we can keep the assertion.
Change-Id: I276e28eafd4740c94bc5233c81a86c01b4a6ae90
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
Add gdbarch_core_read_x86_xsave_layout to fetch the x86 XSAVE layout
structure from a core file.
Current OS's do not export the offsets of XSAVE state components in
core dumps, so provide an i387_guess_xsave_layout helper function to
set offsets based on known combinations of XCR0 masks and total state
sizes. Eventually when core dumps do contain this information this
function should only be used as a fall back for older core dumps.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Add a gdbarch_up unique pointer type, that calls gdbarch_free on
deletion. This is used in the ROCm support patch at the end of this
series.
Change-Id: I4b808892d35d69a590ce83180f41afd91705b2c8
Approved-By: Andrew Burgess <aburgess@redhat.com>
In the ROCm GDB port, there are some amdgcn architectures known by BFD
that we don't actually support in GDB. We don't want
gdbarch_printable_names to return these architectures.
gdbarch_printable_names is used for a few things:
- completion of the "set architecture" command
- the gdb.architecture_names function in Python
- foreach-arch selftests
Add an optional callback to gdbarch_register that is a predicate
indicating whether the gdbarch supports the given bfd_arch_info. by
default, it is nullptr, meaning that the gdbarch accepts all "mach"s for
that architecture known by BFD.
Change-Id: I712f94351b0b34ed1f42e5cf7fc7ba051315d860
Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
Approved-By: Andrew Burgess <aburgess@redhat.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.
When the inferior program changes the SVE length, GDB can stop tracking
some registers as it obtains the new gdbarch that corresponds to the
updated length:
Breakpoint 1, do_sve_ioctl_test () at sve-ioctls.c:44
44 res = prctl(PR_SVE_SET_VL, i, 0, 0, 0, 0);
(gdb) print i
$2 = 32
(gdb) info registers
⋮
[ snip registers x0 to x30 ]
⋮
sp 0xffffffffeff0 0xffffffffeff0
pc 0xaaaaaaaaa8ac 0xaaaaaaaaa8ac <do_sve_ioctl_test+112>
cpsr 0x60000000 [ EL=0 BTYPE=0 C Z ]
fpsr 0x0 0
fpcr 0x0 0
vg 0x8 8
tpidr 0xfffff7fcb320 0xfffff7fcb320
(gdb) next
45 if (res < 0) {
(gdb) info registers
⋮
[ snip registers x0 to x30 ]
⋮
sp 0xffffffffeff0 0xffffffffeff0
pc 0xaaaaaaaaa8cc 0xaaaaaaaaa8cc <do_sve_ioctl_test+144>
cpsr 0x200000 [ EL=0 BTYPE=0 SS ]
fpsr 0x0 0
fpcr 0x0 0
vg 0x4 4
(gdb)
Notice that register tpidr disappeared when vg (which holds the vector
length) changed from 8 to 4. The tpidr register is provided by the
org.gnu.gdb.aarch64.tls feature.
This happens because the code that searches for a new gdbarch to match the
new vector length in aarch64_linux_nat_target::thread_architecture doesn't
take into account the features present in the target description associated
with the previous gdbarch. This patch makes it do that.
Since the id member of struct gdbarch_info is now unused, it's removed.
gdbarch implements its own registry-like approach. This patch changes
it to instead use registry.h. It's a rather large patch but largely
uninteresting -- it's mostly a straightforward conversion from the old
approach to the new one.
The main benefit of this change is that it introduces type safety to
the gdbarch registry. It also removes a bunch of code.
One possible drawback is that, previously, the gdbarch registry
differentiated between pre- and post-initialization setup. This
doesn't seem very important to me, though.
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.
This commit makes use of gdb::checked_static_cast when casting the
generic gdbarch_tdep pointer to a specific sub-class type. This means
that, when compiled in developer mode, GDB will validate that the cast
is correct.
In order to use gdb::checked_static_cast the types involved must have
RTTI, which is why the gdbarch_tdep base class now has a virtual
destructor.
Assuming there are no bugs in GDB where we cast a gdbarch_tdep pointer
to the wrong type, then there should be no changes after this commit.
If any bugs do exist, then GDB will now assert (in a developer build).
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.
A rather straightforward patch to change an instance of callback +
void pointer to gdb::function_view, allowing pasing lambdas that
capture, and eliminating the need for the untyped pointer.
Change-Id: I73ed644e7849945265a2c763f79f5456695b0037
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.
This patch splits gdbarch.h into two files -- gdbarch.h now is
editable and hand-maintained, and the new gdbarch-gen.h file is the
only thing generated by gdbarch.sh. This lets us avoid maintaining
boilerplate in the gdbarch.sh file.
Note that gdbarch.sh still generates gdbarch.h after this patch. This
makes it easier to re-run when rebasing. This code is removed in a
subsequent patch.
Add aliases read_core_file_mappings_loop_ftype and
read_core_file_mappings_pre_loop_ftype. Intended for use with
read_core_file_mappings.
Also add build_id parameter to read_core_file_mappings_loop_ftype.
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
I noticed that gdbarch_selftest::operator() leaked the value returned by
gdbarch_printable_names. Make gdbarch_printable_names return an
std::vector and update callers. That makes it easier for everyone
involved, less manual memory management.
Change-Id: Ia8fc028bdb91f787410cca34f10bf3c5a6da1498
When the architecture supports memory tagging, we handle
pointer/reference types in a special way, so we can validate tags and
show mismatches.
Unfortunately, the currently implementation errors out when the user
prints non-address values: composite types, floats, references, member
functions and other things.
Vector registers:
(gdb) p $v0
Value can't be converted to integer.
Non-existent internal variables:
(gdb) p $foo
Value can't be converted to integer.
The same happens for complex types and printing struct/union types.
There are a few problems here.
The first one is that after print_command_1 evaluates the expression
to print, the tag validation code call value_as_address
unconditionally, without making sure we have have a suitable type
where it makes to sense to call it. That results in value_as_address
(if it isn't given a pointer-like type) trying to treat the value as
an integer and convert it to an address, which #1 - doesn't make sense
(i.e., no sense in validating tags after "print 1"), and throws for
non-integer-convertible types. We fix this by making sure we have a
pointer or reference type first, and only if so then proceed to check
if the address-like value has tags.
The second is that we're calling value_as_address even if we have an
optimized out or unavailable value, which throws, because the value's
contents aren't fully accessible/readable. This error currently
escapes out and aborts the print. This case is fixed by checking for
optimized out / unavailable explicitly.
Third, the tag checking process does not gracefully handle exceptions.
If any exception is thrown from the tag validation code, we abort the
print. E.g., the target may fail to access tags via a running thread.
Or the needed /proc files aren't available. Or some other untold
reason. This is a bit too rigid. This commit changes print_command_1
to catch errors, print them, and still continue with the normal
expression printing path instead of erroring out and printing nothing
useful.
With this patch, printing works correctly again:
(gdb) p $v0
$1 = {d = {f = {2.0546950501119882e-81, 2.0546950501119882e-81}, u = {3399988123389603631, 3399988123389603631}, s = {
3399988123389603631, 3399988123389603631}}, s = {f = {1.59329203e-10, 1.59329203e-10, 1.59329203e-10, 1.59329203e-10}, u = {
791621423, 791621423, 791621423, 791621423}, s = {791621423, 791621423, 791621423, 791621423}}, h = {bf = {1.592e-10,
1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10}, f = {0.11224, 0.11224, 0.11224, 0.11224, 0.11224,
0.11224, 0.11224, 0.11224}, u = {12079, 12079, 12079, 12079, 12079, 12079, 12079, 12079}, s = {12079, 12079, 12079, 12079,
12079, 12079, 12079, 12079}}, b = {u = {47 <repeats 16 times>}, s = {47 <repeats 16 times>}}, q = {u = {
62718710765820030520700417840365121327}, s = {62718710765820030520700417840365121327}}}
(gdb) p $foo
$2 = void
(gdb) p 2 + 2i
$3 = 2 + 2i
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28110
While reviewing another patch, I realized that gdbarch_info_init could
easily be removed in favor of initializing gdbarch_info fields directly
in the struct declaration. The only odd part is the union. I don't
know if it's actually important for it to be zero-initialized, but I
presume it is. I added a constructor to gdbarch_info to take care of
that. A proper solution would be to use std::variant. Or, these could
also be separate fields, the little extra space required wouldn't
matter.
gdb/ChangeLog:
* gdbarch.sh (struct gdbarch_info): Initialize fields, add
constructor.
* gdbarch.h: Re-generate.
* arch-utils.h (gdbarch_info_init): Remove, delete all usages.
* arch-utils.c (gdbarch_info_init): Remove.
Change-Id: I7502e08fe0f278d84eef1667a072e8a97bda5ab5
This field is not actually used, remove it.
gdb/ChangeLog:
* gdbarch.sh (struct gdbarch_info) <tdep_info>: Remove.
(gdbarch_find_by_info): Remove print.
* gdbarch.c, gdbarch.h: Re-generate.
Change-Id: I00af4681b8e1a27727441cbadc3827f5914bd8eb
We need some new gdbarch hooks to help us manipulate memory tags without having
to have GDB call the target methods directly.
This patch adds the following hooks:
gdbarch_memtag_to_string
--
Returns a printable string corresponding to the tag.
gdbarch_tagged_address_p
--
Checks if a particular address is protected with memory tagging.
gdbarch_memtag_matches_p
--
Checks if the logical tag of a pointer and the allocation tag from the address
the pointer points to matches.
gdbarch_set_memtags:
--
Sets either the allocation tag or the logical tag for a particular value.
gdbarch_get_memtag:
--
Gets either the allocation tag or the logical tag for a particular value.
gdbarch_memtag_granule_size
--
Sets the memory tag granule size, which represents the number of bytes a
particular allocation tag covers. For example, this is 16 bytes for
AArch64's MTE.
I've used struct value as opposed to straight CORE_ADDR so other architectures
can use the infrastructure without having to rely on a particular type for
addresses/pointers. Some architecture may use pointers of 16 bytes that don't
fit in a CORE_ADDR, for example.
gdb/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* arch-utils.c (default_memtag_to_string, default_tagged_address_p)
(default_memtag_matches_p, default_set_memtags)
(default_get_memtag): New functions.
* arch-utils.h (default_memtag_to_string, default_tagged_address_p)
(default_memtag_matches_p, default_set_memtags)
(default_get_memtag): New prototypes.
* gdbarch.c: Regenerate.
* gdbarch.h: Regenerate.
* gdbarch.sh (memtag_to_string, tagged_address_p, memtag_matches_p)
(set_memtags, get_memtag, memtag_granule_size): New gdbarch hooks.
(enum memtag_type): New enum.
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.
Today, GDB only allows a single displaced stepping operation to happen
per inferior at a time. There is a single displaced stepping buffer per
inferior, whose address is fixed (obtained with
gdbarch_displaced_step_location), managed by infrun.c.
In the case of the AMD ROCm target [1] (in the context of which this
work has been done), it is typical to have thousands of threads (or
waves, in SMT terminology) executing the same code, hitting the same
breakpoint (possibly conditional) and needing to to displaced step it at
the same time. The limitation of only one displaced step executing at a
any given time becomes a real bottleneck.
To fix this bottleneck, we want to make it possible for threads of a
same inferior to execute multiple displaced steps in parallel. This
patch builds the foundation for that.
In essence, this patch moves the task of preparing a displaced step and
cleaning up after to gdbarch functions. This allows using different
schemes for allocating and managing displaced stepping buffers for
different platforms. The gdbarch decides how to assign a buffer to a
thread that needs to execute a displaced step.
On the ROCm target, we are able to allocate one displaced stepping
buffer per thread, so a thread will never have to wait to execute a
displaced step.
On Linux, the entry point of the executable if used as the displaced
stepping buffer, since we assume that this code won't get used after
startup. From what I saw (I checked with a binary generated against
glibc and musl), on AMD64 we have enough space there to fit two
displaced stepping buffers. A subsequent patch makes AMD64/Linux use
two buffers.
In addition to having multiple displaced stepping buffers, there is also
the idea of sharing displaced stepping buffers between threads. Two
threads doing displaced steps for the same PC could use the same buffer
at the same time. Two threads stepping over the same instruction (same
opcode) at two different PCs may also be able to share a displaced
stepping buffer. This is an idea for future patches, but the
architecture built by this patch is made to allow this.
Now, the implementation details. The main part of this patch is moving
the responsibility of preparing and finishing a displaced step to the
gdbarch. Before this patch, preparing a displaced step is driven by the
displaced_step_prepare_throw function. It does some calls to the
gdbarch to do some low-level operations, but the high-level logic is
there. The steps are roughly:
- Ask the gdbarch for the displaced step buffer location
- Save the existing bytes in the displaced step buffer
- Ask the gdbarch to copy the instruction into the displaced step buffer
- Set the pc of the thread to the beginning of the displaced step buffer
Similarly, the "fixup" phase, executed after the instruction was
successfully single-stepped, is driven by the infrun code (function
displaced_step_finish). The steps are roughly:
- Restore the original bytes in the displaced stepping buffer
- Ask the gdbarch to fixup the instruction result (adjust the target's
registers or memory to do as if the instruction had been executed in
its original location)
The displaced_step_inferior_state::step_thread field indicates which
thread (if any) is currently using the displaced stepping buffer, so it
is used by displaced_step_prepare_throw to check if the displaced
stepping buffer is free to use or not.
This patch defers the whole task of preparing and cleaning up after a
displaced step to the gdbarch. Two new main gdbarch methods are added,
with the following semantics:
- gdbarch_displaced_step_prepare: Prepare for the given thread to
execute a displaced step of the instruction located at its current PC.
Upon return, everything should be ready for GDB to resume the thread
(with either a single step or continue, as indicated by
gdbarch_displaced_step_hw_singlestep) to make it displaced step the
instruction.
- gdbarch_displaced_step_finish: Called when the thread stopped after
having started a displaced step. Verify if the instruction was
executed, if so apply any fixup required to compensate for the fact
that the instruction was executed at a different place than its
original pc. Release any resources that were allocated for this
displaced step. Upon return, everything should be ready for GDB to
resume the thread in its "normal" code path.
The displaced_step_prepare_throw function now pretty much just offloads
to gdbarch_displaced_step_prepare and the displaced_step_finish function
offloads to gdbarch_displaced_step_finish.
The gdbarch_displaced_step_location method is now unnecessary, so is
removed. Indeed, the core of GDB doesn't know how many displaced step
buffers there are nor where they are.
To keep the existing behavior for existing architectures, the logic that
was previously implemented in infrun.c for preparing and finishing a
displaced step is moved to displaced-stepping.c, to the
displaced_step_buffer class. Architectures are modified to implement
the new gdbarch methods using this class. The behavior is not expected
to change.
The other important change (which arises from the above) is that the
core of GDB no longer prevents concurrent displaced steps. Before this
patch, start_step_over walks the global step over chain and tries to
initiate a step over (whether it is in-line or displaced). It follows
these rules:
- if an in-line step is in progress (in any inferior), don't start any
other step over
- if a displaced step is in progress for an inferior, don't start
another displaced step for that inferior
After starting a displaced step for a given inferior, it won't start
another displaced step for that inferior.
In the new code, start_step_over simply tries to initiate step overs for
all the threads in the list. But because threads may be added back to
the global list as it iterates the global list, trying to initiate step
overs, start_step_over now starts by stealing the global queue into a
local queue and iterates on the local queue. In the typical case, each
thread will either:
- have initiated a displaced step and be resumed
- have been added back by the global step over queue by
displaced_step_prepare_throw, because the gdbarch will have returned
that there aren't enough resources (i.e. buffers) to initiate a
displaced step for that thread
Lastly, if start_step_over initiates an in-line step, it stops
iterating, and moves back whatever remaining threads it had in its local
step over queue to the global step over queue.
Two other gdbarch methods are added, to handle some slightly annoying
corner cases. They feel awkwardly specific to these cases, but I don't
see any way around them:
- gdbarch_displaced_step_copy_insn_closure_by_addr: in
arm_pc_is_thumb, arm-tdep.c wants to get the closure for a given
buffer address.
- gdbarch_displaced_step_restore_all_in_ptid: when a process forks
(at least on Linux), the address space is copied. If some displaced
step buffers were in use at the time of the fork, we need to restore
the original bytes in the child's address space.
These two adjustments are also made in infrun.c:
- prepare_for_detach: there may be multiple threads doing displaced
steps when we detach, so wait until all of them are done
- handle_inferior_event: when we handle a fork event for a given
thread, it's possible that other threads are doing a displaced step at
the same time. Make sure to restore the displaced step buffer
contents in the child for them.
[1] https://github.com/ROCm-Developer-Tools/ROCgdb
gdb/ChangeLog:
* displaced-stepping.h (struct
displaced_step_copy_insn_closure): Adjust comments.
(struct displaced_step_inferior_state) <step_thread,
step_gdbarch, step_closure, step_original, step_copy,
step_saved_copy>: Remove fields.
(struct displaced_step_thread_state): New.
(struct displaced_step_buffer): New.
* displaced-stepping.c (displaced_step_buffer::prepare): New.
(write_memory_ptid): Move from infrun.c.
(displaced_step_instruction_executed_successfully): New,
factored out of displaced_step_finish.
(displaced_step_buffer::finish): New.
(displaced_step_buffer::copy_insn_closure_by_addr): New.
(displaced_step_buffer::restore_in_ptid): New.
* gdbarch.sh (displaced_step_location): Remove.
(displaced_step_prepare, displaced_step_finish,
displaced_step_copy_insn_closure_by_addr,
displaced_step_restore_all_in_ptid): New.
* gdbarch.c: Re-generate.
* gdbarch.h: Re-generate.
* gdbthread.h (class thread_info) <displaced_step_state>: New
field.
(thread_step_over_chain_remove): New declaration.
(thread_step_over_chain_next): New declaration.
(thread_step_over_chain_length): New declaration.
* thread.c (thread_step_over_chain_remove): Make non-static.
(thread_step_over_chain_next): New.
(global_thread_step_over_chain_next): Use
thread_step_over_chain_next.
(thread_step_over_chain_length): New.
(global_thread_step_over_chain_enqueue): Add debug print.
(global_thread_step_over_chain_remove): Add debug print.
* infrun.h (get_displaced_step_copy_insn_closure_by_addr):
Remove.
* infrun.c (get_displaced_stepping_state): New.
(displaced_step_in_progress_any_inferior): Remove.
(displaced_step_in_progress_thread): Adjust.
(displaced_step_in_progress): Adjust.
(displaced_step_in_progress_any_thread): New.
(get_displaced_step_copy_insn_closure_by_addr): Remove.
(gdbarch_supports_displaced_stepping): Use
gdbarch_displaced_step_prepare_p.
(displaced_step_reset): Change parameter from inferior to
thread.
(displaced_step_prepare_throw): Implement using
gdbarch_displaced_step_prepare.
(write_memory_ptid): Move to displaced-step.c.
(displaced_step_restore): Remove.
(displaced_step_finish): Implement using
gdbarch_displaced_step_finish.
(start_step_over): Allow starting more than one displaced step.
(prepare_for_detach): Handle possibly multiple threads doing
displaced steps.
(handle_inferior_event): Handle possibility that fork event
happens while another thread displaced steps.
* linux-tdep.h (linux_displaced_step_prepare): New.
(linux_displaced_step_finish): New.
(linux_displaced_step_copy_insn_closure_by_addr): New.
(linux_displaced_step_restore_all_in_ptid): New.
(linux_init_abi): Add supports_displaced_step parameter.
* linux-tdep.c (struct linux_info) <disp_step_buf>: New field.
(linux_displaced_step_prepare): New.
(linux_displaced_step_finish): New.
(linux_displaced_step_copy_insn_closure_by_addr): New.
(linux_displaced_step_restore_all_in_ptid): New.
(linux_init_abi): Add supports_displaced_step parameter,
register displaced step methods if true.
(_initialize_linux_tdep): Register inferior_execd observer.
* amd64-linux-tdep.c (amd64_linux_init_abi_common): Add
supports_displaced_step parameter, adjust call to
linux_init_abi. Remove call to
set_gdbarch_displaced_step_location.
(amd64_linux_init_abi): Adjust call to
amd64_linux_init_abi_common.
(amd64_x32_linux_init_abi): Likewise.
* aarch64-linux-tdep.c (aarch64_linux_init_abi): Adjust call to
linux_init_abi. Remove call to
set_gdbarch_displaced_step_location.
* arm-linux-tdep.c (arm_linux_init_abi): Likewise.
* i386-linux-tdep.c (i386_linux_init_abi): Likewise.
* alpha-linux-tdep.c (alpha_linux_init_abi): Adjust call to
linux_init_abi.
* arc-linux-tdep.c (arc_linux_init_osabi): Likewise.
* bfin-linux-tdep.c (bfin_linux_init_abi): Likewise.
* cris-linux-tdep.c (cris_linux_init_abi): Likewise.
* csky-linux-tdep.c (csky_linux_init_abi): Likewise.
* frv-linux-tdep.c (frv_linux_init_abi): Likewise.
* hppa-linux-tdep.c (hppa_linux_init_abi): Likewise.
* ia64-linux-tdep.c (ia64_linux_init_abi): Likewise.
* m32r-linux-tdep.c (m32r_linux_init_abi): Likewise.
* m68k-linux-tdep.c (m68k_linux_init_abi): Likewise.
* microblaze-linux-tdep.c (microblaze_linux_init_abi): Likewise.
* mips-linux-tdep.c (mips_linux_init_abi): Likewise.
* mn10300-linux-tdep.c (am33_linux_init_osabi): Likewise.
* nios2-linux-tdep.c (nios2_linux_init_abi): Likewise.
* or1k-linux-tdep.c (or1k_linux_init_abi): Likewise.
* riscv-linux-tdep.c (riscv_linux_init_abi): Likewise.
* s390-linux-tdep.c (s390_linux_init_abi_any): Likewise.
* sh-linux-tdep.c (sh_linux_init_abi): Likewise.
* sparc-linux-tdep.c (sparc32_linux_init_abi): Likewise.
* sparc64-linux-tdep.c (sparc64_linux_init_abi): Likewise.
* tic6x-linux-tdep.c (tic6x_uclinux_init_abi): Likewise.
* tilegx-linux-tdep.c (tilegx_linux_init_abi): Likewise.
* xtensa-linux-tdep.c (xtensa_linux_init_abi): Likewise.
* ppc-linux-tdep.c (ppc_linux_init_abi): Adjust call to
linux_init_abi. Remove call to
set_gdbarch_displaced_step_location.
* arm-tdep.c (arm_pc_is_thumb): Call
gdbarch_displaced_step_copy_insn_closure_by_addr instead of
get_displaced_step_copy_insn_closure_by_addr.
* rs6000-aix-tdep.c (rs6000_aix_init_osabi): Adjust calls to
clear gdbarch methods.
* rs6000-tdep.c (struct ppc_inferior_data): New structure.
(get_ppc_per_inferior): New function.
(ppc_displaced_step_prepare): New function.
(ppc_displaced_step_finish): New function.
(ppc_displaced_step_restore_all_in_ptid): New function.
(rs6000_gdbarch_init): Register new gdbarch methods.
* s390-tdep.c (s390_gdbarch_init): Don't call
set_gdbarch_displaced_step_location, set new gdbarch methods.
gdb/testsuite/ChangeLog:
* gdb.arch/amd64-disp-step-avx.exp: Adjust pattern.
* gdb.threads/forking-threads-plus-breakpoint.exp: Likewise.
* gdb.threads/non-stop-fair-events.exp: Likewise.
Change-Id: I387cd235a442d0620ec43608fd3dc0097fcbf8c8
The last commit missed updating the doc of
gdbarch_displaced_step_hw_singlestep to avoid mentioning the removed
parameter, this one fixes it.
gdb/ChangeLog:
* gdbarch.sh (displaced_step_hw_singlestep): Adjust
documentation.
* gdbarch.h: Re-generate.
Change-Id: I33675d9a6c253443eee707e8285d16615ce20aaa
I noticed that the closure parameter of
gdbarch_displaced_step_hw_singlestep is never used by any
implementation of the method, so this patch removes it.
gdb/ChangeLog:
* gdbarch.sh (displaced_step_hw_singlestep): Remove closure
parameter.
* aarch64-tdep.c (aarch64_displaced_step_hw_singlestep):
Likewise.
* aarch64-tdep.h (aarch64_displaced_step_hw_singlestep):
Likewise.
* arch-utils.c (default_displaced_step_hw_singlestep):
Likewise.
* arch-utils.h (default_displaced_step_hw_singlestep):
Likewise.
* rs6000-tdep.c (ppc_displaced_step_hw_singlestep):
Likewise.
* s390-tdep.c (s390_displaced_step_hw_singlestep):
Likewise.
* gdbarch.c: Re-generate.
* gdbarch.h: Re-generate.
* infrun.c (resume_1): Adjust.
Change-Id: I7354f0b22afc2692ebff0cd700a462db8f389fc1
This patch starts by making the gdbarch_make_corefile_notes function
return a gdb::unique_xmalloc_ptr<char> and takes care of the fallouts,
mostly in linux-tdep.c and fbsd-tdep.c.
The difficulty in these files is that they use the BFD API for writing
core files, where you pass in a pointer to a malloc-ed buffer (or NULL
in the beginning), it re-allocs it if needed, and returns you the
possibly updated pointer. I therefore used this pattern everywhere:
note_data.reset (elfcore_write_note (obfd, note_data.release (), ...)
This hands over the ownership of note_data to the BFD function for the
duration of the call, and then puts its back in note_data right after
the call.
gdb/ChangeLog:
* gdbarch.sh (make_corefile_notes): Return unique pointer.
* gdbarch.c: Re-generate.
* gdbarch.h: Re-generate.
* gcore.c (write_gcore_file_1): Adjust.
* fbsd-tdep.c (struct fbsd_collect_regset_section_cb_data): Add
constructor.
<note_data>: Change type to unique pointer.
<abort_iteration>: Change type to bool.
(fbsd_collect_regset_section_cb): Adjust to unique pointer.
(fbsd_collect_thread_registers): Return void, adjust.
(struct fbsd_corefile_thread_data): Add construtor.
<note_data>: Change type to unique pointer.
(fbsd_corefile_thread): Adjust.
(fbsd_make_corefile_notes): Return unique pointer, adjust.
* linux-tdep.c (linux_make_mappings_corefile_notes): Change type
to unique pointer, adjust.
(struct linux_collect_regset_section_cb_data): Add constructor.
<note_data>: Change type to unique pointer.
<abort_iteration>: Change type to bool.
(linux_collect_thread_registers): Return void, adjust.
(struct linux_corefile_thread_data): Add constructor.
<note_data>: Change type to unique pointer.
(linux_corefile_thread): Adjust.
(linux_make_corefile_notes): Return unique pointer, adjust.
Change-Id: I1e03476bb47b87c6acb3e12204d193f38cc4e02b
gdbarch predicates (functions suffixed _p to check whether a gdbarch
implements a given method) currently return int. Make them return bool.
There is no expected behavior change.
gdb/ChangeLog:
* gdbarch.sh: Make generated predicates return bool.
* gdbarch.c: Re-generate.
* gdbarch.h: Re-generate.
Change-Id: Ie7ebc1acae62df83da9085ba69327fca551c5a30
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.
This adds support for the bfloat16 datatype, which can be seen as a short
version of FP32, skipping the least significant 16 bits of the mantissa.
Since the datatype is currently only supported by the AVX512 registers,
the printing of bfloat16 values is only supported for xmm, ymm and zmm
registers.
gdb/ChangeLog:
2020-09-11 Moritz Riesterer <moritz.riesterer@intel.com>
Felix Willgerodt <Felix.Willgerodt@intel.com>
* gdbarch.sh: Added bfloat16 type.
* gdbarch.c: Regenerated.
* gdbarch.h: Regenerated.
* gdbtypes.c (floatformats_bfloat16): New struct.
(gdbtypes_post_init): Add builtin_bfloat16.
* gdbtypes.h (struct builtin_type) <builtin_bfloat16>: New member.
(floatformats_bfloat16): New struct.
* i386-tdep.c (i386_zmm_type): Add field "v32_bfloat16"
(i386_ymm_type): Add field "v16_bfloat16"
(i386_gdbarch_init): Add set_gdbarch_bfloat16_format.
* target-descriptions.c (make_gdb_type): Add case TDESC_TYPE_BFLOAT16.
* gdbsupport/tdesc.cc (tdesc_predefined_types): New member bfloat16.
* gdbsupport/tdesc.h (tdesc_type_kind): New member TDESC_TYPE_BFLOAT16.
* features/i386/64bit-avx512.xml: Add bfloat16 type.
* features/i386/64bit-avx512.c: Regenerated.
* features/i386/64bit-sse.xml: Add bfloat16 type.
* features/i386/64bit-sse.c: Regenerated.
gdb/testsuite/ChangeLog:
2020-09-11 Moritz Riesterer <moritz.riesterer@intel.com>
Felix Willgerodt <Felix.Willgerodt@intel.com>
* x86-avx512bf16.c: New file.
* x86-avx512bf16.exp: Likewise.
* lib/gdb.exp (skip_avx512bf16_tests): New function.
The new gdbarch method, read_core_file_mappings, will be used for
reading file-backed mappings from a core file. It'll be used
for two purposes: 1) to construct a table of file-backed mappings
in corelow.c, and 2) for display of core file mappings.
For Linux, I tried a different approach in which knowledge of the note
format was placed directly in corelow.c. This seemed okay at first;
it was only one note format and the note format was fairly simple.
After looking at FreeBSD's note/mapping reading code, I concluded
that it's best to leave architecture specific details for decoding
the note in (architecture specific) tdep files.
With regard to display of core file mappings, I experimented with
placing the mappings display code in corelow.c. It has access to the
file-backed mappings which were read in when the core file was loaded.
And, better, still common code could be used for all architectures.
But, again, the FreeBSD mapping code convinced me that this was not
the best approach since it has even more mapping info than Linux.
Display code which would work well for Linux will leave out mappings
as well as protection info for mappings.
So, for these reasons, I'm introducing a new gdbarch method for
reading core file mappings.
gdb/ChangeLog:
* arch-utils.c (default_read_core_file_mappings): New function.
* arch-utils.c (default_read_core_file_mappings): Declare.
* gdbarch.sh (read_core_file_mappings): New gdbarch method.
* gdbarch.h, gdbarch.c: Regenerate.
This is a more general version of the existing handle_segmentation_fault
hook that is able to report information for an arbitrary signal, not
just SIGSEGV.
gdb/ChangeLog:
* gdbarch.c: Regenerate.
* gdbarch.h: Regenerate.
* gdbarch.sh (report_signal_info): New method.
* infrun.c (print_signal_received_reason): Invoke gdbarch
report_signal_info hook if present.
There are currently two remaining uses of deprecated_set_gdbarch_data,
both of which are needed because during gdbarch initialisation we call
gdbarch_data for a data field that is registered using:
gdbarch_data_register_post_init (....)
However, in both of these cases, the only thing that the call back
needs from the gdbarch struct is its obstack. Given this there is
nothing stopping us changing the post-init hooks into pre-init hooks.
The pre-init hooks don't get passed the full gdbarch, they only get
passed its obstack.
The IA64 change is completely untested. The user-regs change has been
tested a little by locally adding some user-regs to the x86-64 target,
and also by running the RISC-V tests, which do use user-regs.
gdb/ChangeLog:
* gdbarch.c: Regenerate.
* gdbarch.h: Regenerate.
* gdbarch.sh (deprecated_set_gdbarch_data): Delete.
(gdbarch_data): Use internal_error for the case where
deprecated_set_gdbarch_data was originally needed.
* ia64-libunwind-tdep.c (libunwind_descr_init): Update parameters,
and use passed in obstack.
(libunwind_frame_set_descr): Should no longer get back NULL from
gdbarch_data.
(_initialize_libunwind_frame): Register as a pre-init gdbarch data
type.
* user-regs.c (user_regs_init): Update parameters, and use passed
in obstack.
(user_reg_add): Should no longer get back NULL from gdbarch_data.
(_initialize_user_regs): Register as a pre-init gdbarch data type.
