PR gdb/22286: linux-nat-trad: Support arbitrary register widths

Update `fetch_register' and `store_register' code to support arbitrary
register widths rather than only ones that are a multiply of the size of
the `ptrace' data type used with PTRACE_PEEKUSR and PTRACE_POKEUSR
requests to access registers.  Remove associated assertions, correcting
an issue with accessing the DSPControl (`$dspctl') register on n64 MIPS
native targets:

(gdb) print /x $dspctl
.../gdb/linux-nat-trad.c:50: internal-error: void linux_nat_trad_target::fetch_register(regcache*, int): Assertion `(size % sizeof (PTRACE_TYPE_RET)) == 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) n

This is a bug, please report it.  For instructions, see:
<http://www.gnu.org/software/gdb/bugs/>.

.../gdb/linux-nat-trad.c:50: internal-error: void linux_nat_trad_target::fetch_register(regcache*, int): Assertion `(size % sizeof (PTRACE_TYPE_RET)) == 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) n
Command aborted.
(gdb)

All registers are now reported correctly and their architectural
hardware widths respected:

(gdb) print /x $dspctl
$1 = 0x55aa33cc
(gdb) info registers
                  zero               at               v0               v1
 R0   0000000000000000 0000000000000001 000000fff7ffeb20 0000000000000000
                    a0               a1               a2               a3
 R4   0000000000000001 000000ffffffeaf8 000000ffffffeb08 0000000000000000
                    a4               a5               a6               a7
 R8   000000fff7ee3800 000000fff7ede8f0 000000ffffffeaf0 2f2f2f2f2f2f2f2f
                    t0               t1               t2               t3
 R12  0000000000000437 0000000000000002 000000fff7ffd000 0000000120000ad0
                    s0               s1               s2               s3
 R16  000000fff7ee2068 0000000120000e60 0000000000000000 0000000000000000
                    s4               s5               s6               s7
 R20  0000000000521ec8 0000000000522608 0000000000000000 0000000000000000
                    t8               t9               k0               k1
 R24  0000000000000000 0000000120000d9c 0000000000000000 0000000000000000
                    gp               sp               s8               ra
 R28  0000000120019030 000000ffffffe990 000000ffffffe990 000000fff7d5b88c
                status               lo               hi         badvaddr
      0000000000109cf3 0000000000005ea5 0000000000000211 000000fff7fc6fe0
                 cause               pc
      0000000000800024 0000000120000dbc
                  fcsr              fir              hi1              lo1
              00000000         00f30000 0000000000000000 0101010101010101
                   hi2              lo2              hi3              lo3
      0202020202020202 0303030303030303 0404040404040404 0505050505050505
                dspctl          restart
              55aa33cc 0000000000000000
(gdb)

NB due to the lack of access to 64-bit DSP hardware all DSP register
values in the dumps are artificial and have been created with a debug
change applied to the kernel handler of the `ptrace' syscall.

The use of `store_unsigned_integer' and `extract_unsigned_integer'
unconditionally in all cases rather than when actual data occupies a
part of the data quantity exchanged with `ptrace' makes code perhaps
marginally slower, however I think avoiding it is not worth code
obfuscation it would cause.  If this turns out unfounded, then there
should be no problem with optimizing this code later.

	gdb/
	PR gdb/22286
	* linux-nat-trad.c (linux_nat_trad_target::fetch_register):
	Also handle registers whose width is not a multiple of
	PTRACE_TYPE_RET.
	(linux_nat_trad_target::store_register): Likewise.

0 files changed, 0 insertions, 0 deletions