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

[Luis Machado <luis.machado@arm.com>]

Hi Tom,

On 3/13/24 17:12, Tom de Vries wrote:
> 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.

I'm not sure if there is one filed upstream, but the kernel folks are aware of the situation. From what we discussed in the past, this is either clumsy to do on the kernel's side right now or is not worth it for the gains. It could also be the case the kernel itself doesn't get precise information (it escapes me now), so can't send down precise information down to userspace. I'm aware there are efforts to improve this in the future.

I was thinking a bit about this the other day, and one (kinda brute force) way of not getting stuck in an endless loop is to try to remove hardware watchpoints one by one whenever we trigger one of them. Then gdb will eventually be able to step over.

Determining which particular watchpoint triggered is still a bit tricky, as we may have to remove multiple hardware watchpoints. Still, the thread is stopped anyway, and the debug registers are per-thread. Removing them all at the same time may also work without disturbing all the other threads.

Right now we don't explore per-thread debug registers properly in gdb. But being pre-thread, those registers give us some flexibility that we don't have with software breakpoints (we can't remove a software breakpoint without affecting all the other running threads), for example.

> 
>> 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