diff options
author | Simon Marchi <simon.marchi@efficios.com> | 2023-12-01 11:27:14 -0500 |
---|---|---|
committer | Simon Marchi <simon.marchi@efficios.com> | 2023-12-14 16:04:49 +0000 |
commit | c3a03de70fd373c0f8fc4ba5df1c0db29445112c (patch) | |
tree | fcf6af29ebec724411273970601430b588c53f39 /gdbsupport | |
parent | 1d2f86b6b74e6caae77951353a4c353ce9816374 (diff) | |
download | binutils-c3a03de70fd373c0f8fc4ba5df1c0db29445112c.zip binutils-c3a03de70fd373c0f8fc4ba5df1c0db29445112c.tar.gz binutils-c3a03de70fd373c0f8fc4ba5df1c0db29445112c.tar.bz2 |
gdb: don't handle i386 k registers as pseudo registers
I think that i386 k registers are raw registers, and therefore shouldn't
be handled in the various functions handling pseudo registers.
What tipped me off is the code in i386_pseudo_register_read_into_value:
else if (i386_k_regnum_p (gdbarch, regnum))
{
regnum -= tdep->k0_regnum;
/* Extract (always little endian). */
status = regcache->raw_read (tdep->k0_regnum + regnum, raw_buf);
We take regnum (the pseudo register number we want to read), subtract
k0_regnum, add k0_regnum, and pass the result to raw_read. So we would
end up calling raw_read with the same regnum as the function received
which is supposedly a pseudo register number.
Other hints are:
- The command `maint print raw-registers` shows the k registers.
- Printing $k0 doesn't cause i386_pseudo_register_read_into_value to be
called.
- There's code in i387-tdep.c to save/restore the k registers.
Remove handling of the k registers from:
- i386_pseudo_register_read_into_value
- i386_pseudo_register_write
- i386_ax_pseudo_register_collect
Change-Id: Ic97956ed59af6099fef6d36a0b61464172694562
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
Diffstat (limited to 'gdbsupport')
0 files changed, 0 insertions, 0 deletions