[gdb/tdep] Handle M1 ldp in aarch64_stopped_data_address

In test-case gdb.base/watchpoint-unaligned.exp, in function write_size8twice,
two adjacent 8-byte vars are written.  For aarch64, we use a single stp
instruction for that.

If we do the same in function read_size8twice for two adjacent 8-byte var reads
using aarch64 insn ldp, on an aarch64-linux M1 system we get a hang:
...
(gdb) continue^M
Continuing.^M
FAIL: $exp: fun=read_size8twice: offset=0: index=1: continue (timeout)
FAIL: $exp: fun=read_size8twice: offset=0: index=1: $got_hit
...

The same problem was observed for stp in PR tdep/29423, fixed by commit
9a03f218534 ("[gdb/tdep] Fix gdb.base/watchpoint-unaligned.exp on aarch64").

See that commit for an explanation of the hang.

That commit introduced max_access_size in aarch64_stopped_data_address:
...
	   The access size also can be larger than that of the watchpoint
	   itself.  For instance, the access size of an stp instruction is 16.
	   So, if we use stp to store to address p, and set a watchpoint on
	   address p + 8, the reported ADDR_TRAP can be p + 8 (observed on
	   RK3399 SOC). But it also can be p (observed on M1 SOC).  Checking
	   for this situation introduces the possibility of false positives,
	   so we only do this for hw_write watchpoints.  */
	const CORE_ADDR max_access_size = type == hw_write ? 16 : 8;
...

If we say that hangs are worse than false positives, then we should also fix
this case.

Fix this by setting max_access_size to 16 for all watchpoint types.

Tested on aarch64-linux, both on an M1 SOC and an RK3399 SOC.

Approved-By: Luis Machado <luis.machado.foss@gmail.com>

0 files changed, 0 insertions, 0 deletions