aboutsummaryrefslogtreecommitdiff
path: root/libctf/ctf-open.c
diff options
context:
space:
mode:
authorAndrew Burgess <andrew.burgess@embecosm.com>2020-06-16 13:14:04 +0100
committerAndrew Burgess <andrew.burgess@embecosm.com>2020-06-25 18:07:31 +0100
commitbe64fd0776f78d8285e6c27125c0558386865e2f (patch)
treea3d6c0bf34c481c793041cae46158a3ad6c1e676 /libctf/ctf-open.c
parent3b9fce9660539584e869ea2d77610434e6baa2a2 (diff)
downloadgdb-be64fd0776f78d8285e6c27125c0558386865e2f.zip
gdb-be64fd0776f78d8285e6c27125c0558386865e2f.tar.gz
gdb-be64fd0776f78d8285e6c27125c0558386865e2f.tar.bz2
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.
Diffstat (limited to 'libctf/ctf-open.c')
0 files changed, 0 insertions, 0 deletions