]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit - gdb/ChangeLog
gdb: Extend target description processing of unknown registers
authorAndrew Burgess <andrew.burgess@embecosm.com>
Tue, 16 Jun 2020 12:14:04 +0000 (13:14 +0100)
committerAndrew Burgess <andrew.burgess@embecosm.com>
Thu, 25 Jun 2020 17:07:31 +0000 (18:07 +0100)
commitbe64fd0776f78d8285e6c27125c0558386865e2f
treea3d6c0bf34c481c793041cae46158a3ad6c1e676
parent3b9fce9660539584e869ea2d77610434e6baa2a2
gdb: Extend target description processing of unknown registers

This commit adds a new step to the processing of a target description
done in tdesc_use_registers, this new step is about how unknown
registers are processed.

Currently an architecture looks through the target description and
calls tdesc_numbered_register for each register is was expecting (or
hoping) to find.  This builds up a map from GDB's register numbers to
the tdesc_reg object.  Later the architecture calls
tdesc_use_registers.

In tdesc_use_registers we build a hash with keys being all the
tdesc_reg object pointers, from this hash we remove all of the
tdesc_reg objects that were assigned register numbers using
tdesc_numbered_register.

Finally we walk through all of the tdesc_reg objects, and if it was
not already assigned a number we assign that register the next
available number.

The problem with this is that the architecture has no visibility of
which unknown registers exist, and which tdesc_feature the register
came from, in some cases this might be important.

For example, on RISC-V GDB overrides the use of
tdesc_register_reggroup_p, with riscv_register_reggroup_p to modify
some of the register group choices.  In this function GDB wants to
treat all registers from a particular feature in a certain way.  This
is fine for registers that GDB knows might be in that feature, but for
unknown registers the RISC-V parts of GDB have no easy way to figure
out which unknown registers exist, and what numbers they were
assigned.

We could figure this information out by probing the register
structures after calling tdesc_use_registers, but this would be
horrible, much better to have tdesc_use_registers tell the
architecture about unknown registers.

This is what this commit does.  A new phase of tdesc_use_registers,
just before the unknown registers are assigned a number, we loop over
each tdesc_reg object, if it has not been assigned a number then we
figure out what number would be assigned and then call back into the
architecture passing the tdesc_feature, register name, and the
proposed register number.

The architecture is free to return the proposed register number, or it
can return a different number (which has a result identical to having
called tdesc_numbered_register).  Alternatively the architecture can
return -1 to indicate the register should be numbered later.

After calling the callback for every tdesc_reg object any registers
still don't have a number assigned (because the architecture returned
-1), then a new register number is assigned, which might be different
from the proposed number that was suggested earlier.

This commit adds the general target-description parts of this
mechanism.  No targets are currently using this code.  The RISC-V
target will make use of this in the next commit.

There should be no user visible changes after this commit.

gdb/ChangeLog:

* target-descriptions.c (tdesc_use_registers): Add new parameter a
callback, use the callback (when not null) to help number unknown
registers.
* target-descriptions.h (tdesc_unknown_register_ftype): New typedef.
(tdesc_use_registers): Add extra parameter to declaration.
gdb/ChangeLog
gdb/target-descriptions.c
gdb/target-descriptions.h