aboutsummaryrefslogtreecommitdiff
path: root/gdb/filesystem.c
diff options
context:
space:
mode:
authorMaciej W. Rozycki <macro@mips.com>2018-05-22 22:52:14 +0100
committerMaciej W. Rozycki <macro@mips.com>2018-05-22 22:52:14 +0100
commit7e947ad3438b2954e0bd248fd2c95a86bd9fe33b (patch)
tree2e6f5b0c8a534bd76ca963b3ca0892165313206b /gdb/filesystem.c
parent6b8edb5101861228778b7c2d014e20c5ba0c156a (diff)
downloadbinutils-7e947ad3438b2954e0bd248fd2c95a86bd9fe33b.zip
binutils-7e947ad3438b2954e0bd248fd2c95a86bd9fe33b.tar.gz
binutils-7e947ad3438b2954e0bd248fd2c95a86bd9fe33b.tar.bz2
MIPS/gdbserver: Correctly handle narrow big-endian register transfers
Fix an issue with `gdbserver' on big-endian n64 MIPS targets, where $dspctl is 32-bit while the `ptrace' transfer data type is 64-bit. Such register data is held in the low order 32 bits of the 64-bit data quantity exchanged with the buffer used by `fetch_register' and `store_register', however `supply_register' and `collect_register' access the same data as a 32-bit quantity. Consequently the register is presented and written as all-zeros held in the most-significant part of the big-endian 64-bit data quantity represented in the buffer: (gdb) info registers zero at v0 v1 R0 0000000000000000 0000000000000001 0000000000000001 0000000000000000 a0 a1 a2 a3 R4 00000001200212b0 0000000000000000 0000000000000021 000000012001a260 a4 a5 a6 a7 R8 000000012001a260 0000000000000004 800000010c60c000 fffffffffffffff8 t0 t1 t2 t3 R12 0000000000000000 000000fff7edab68 0000000000000001 0000000000000000 s0 s1 s2 s3 R16 000000fff7ee2068 0000000120008b80 0000000000000000 0000000000000000 s4 s5 s6 s7 R20 000000000052e5c8 000000000052f008 0000000000000000 0000000000000000 t8 t9 k0 k1 R24 0000000000000000 00000001200027c0 0000000000000000 0000000000000000 gp sp s8 ra R28 00000001200212b0 000000ffffffc850 000000ffffffc850 0000000120005ee8 status lo hi badvaddr 0000000000109cf3 0000000000943efe 000000000000000e 000000012001a008 cause pc 0000000000800024 0000000120005ee8 fcsr fir hi1 lo1 0e800000 00f30000 0000000000000000 0101010101010101 hi2 lo2 hi3 lo3 0202020202020202 0303030303030303 0404040404040404 0505050505050505 dspctl restart 00000000 0000000000000000 (gdb) Correct this problem then by using the `mips_supply_register' `mips_collect_register' accessors for 32-bit registers where the `ptrace' data type is 64-bit. These accessors already operate on 32-bit data quantities held in 64-bit containers: (gdb) info registers zero at v0 v1 R0 0000000000000000 0000000000000001 0000000000000001 0000000000000000 a0 a1 a2 a3 R4 00000001200212b0 0000000000000000 0000000000000021 000000012001a260 a4 a5 a6 a7 R8 000000012001a260 0000000000000004 800000010d82e900 fffffffffffffff8 t0 t1 t2 t3 R12 0000000000000000 000000fff7edab68 0000000000000001 0000000000000000 s0 s1 s2 s3 R16 000000fff7ee2068 0000000120008b80 0000000000000000 0000000000000000 s4 s5 s6 s7 R20 000000000052e5c8 000000000052f008 0000000000000000 0000000000000000 t8 t9 k0 k1 R24 0000000000000000 00000001200027c0 0000000000000000 0000000000000000 gp sp s8 ra R28 00000001200212b0 000000ffffffc850 000000ffffffc850 0000000120005ee8 status lo hi badvaddr 0000000000109cf3 0000000000943efe 000000000000000e 000000012001a008 cause pc 0000000000800024 0000000120005ee8 fcsr fir hi1 lo1 0e800000 00f30000 0000000000000000 0101010101010101 hi2 lo2 hi3 lo3 0202020202020202 0303030303030303 0404040404040404 0505050505050505 dspctl restart 55aa33cc 0000000000000000 (gdb) gdb/gdbserver/ * linux-mips-low.c [HAVE_PTRACE_GETREGS] (mips_collect_register) (mips_supply_register): Move outside HAVE_PTRACE_GETREGS. (mips_collect_ptrace_register, mips_supply_ptrace_register): New functions. (the_low_target): Wire them.
Diffstat (limited to 'gdb/filesystem.c')
0 files changed, 0 insertions, 0 deletions