Re: [PATCH 1/2] [gdb/tdep] Fix gdb.base/watchpoint-unaligned.exp on aarch64

[Tom de Vries <tdevries@suse.de>]

On 3/7/24 11:50, Luis Machado wrote:
> Hi Tom,
> 
> Raising the alignment enforcement means we will cover a bigger range of addresses, potentially covering our target watchpoint/trap address,
> but I'm afraid it also means we will raise the potential for false positives, if watchpoints are placed within the alignment range.
> 

True.  I've submitted a v2 that should address that, by limiting the 
impact of the patch to regular hw watchpoints.

> Furthermore, we are not limited to 16-byte accesses. For SVE and SME we may be looking at even bigger accesses. And, more generally, the memset/memcpy
> instructions (not yet widely used) can potentially access arbitrary amounts of memory. So tweaking the alignment is only a focused fix towards the most often
> used instructions and access sizes at the moment.
> 

I don't have access atm to an SVE or SME or MOPS machine.

We can guess that those larger accesses will cause issues, but we don't 
know until we try.  For instance, in the case of the stp instruction, it 
didn't cause issues with say a RK3399 SOC, but it did with an M1 SOC, so 
just the existence of larger accesses doesn't mean there are issues.

> The more general problem of not being able to tell which particular watchpoint caused the trap remains.
>

Yes.  I think we need to file a linux kernel bug for this.  I looked for 
one and didn't find it.  My current idea for a concrete solution for 
this is that the kernel should communicate back the state of the 2 debug 
registers (control and value) for which it thinks the watchpoint 
triggered.  That should resolve any ambiguity on the user space side.

> How does the above fix behave on the overall testsuite in terms of watchpoint tests?

The v2, as the v1, fixes the test-case and doesn't cause regressions.

Thanks,
- Tom