[patch] aarch64: PR 19806: watchpoints: false negatives -> false positives

[Jan Kratochvil]

On Mon, 20 Jun 2016 13:47:12 +0200, Pedro Alves wrote:
> On 06/19/2016 07:29 PM, Jan Kratochvil wrote:
> > On Wed, 08 Jun 2016 20:46:35 +0200, Pedro Alves wrote:
> >> ... if the program writes to global.buf[3], and the target
> >> reports a memory access to 'global.buf + 1' (because that's the
> >> first watchpoint in its own watchpoint list that overlaps
> >> the global.buf[0]..global.buf[3] range (what is really being
> >> watched)), gdb will believe that watchpoint 1 triggered, notice
> >> the value didn't change, and thus incorrectly ignore the watchpoint hit.
> > 
> > Here if the program really does 'global.buf[3] = 0xff;' then it still does
> > work as despite GDB places watchpoint at &global.buf[0] for 4 bytes aarch64
> > still reports the exact 1-byte location &global.buf[3]:
> > 	echo -e 'union { char buf[8]; unsigned long ul; } u; int main(void) {\n u.buf[3]=0xff;\n return 0; }'|gcc -Wall -g -x c -;./gdb -data-directory ./data-directory/ ./a.out -ex start -ex 'watch u.buf[1]' -ex 'watch u.buf[3]' -ex c -ex 'p u.buf[1]' -ex 'p u.buf[3]'
> > 	Hardware watchpoint 2: u.buf[1]
> > 	Hardware watchpoint 3: u.buf[3]
> > 	Continuing.
> > 	Hardware watchpoint 3: u.buf[3]
> > 	Old value = 0 '\000'
> > 	New value = 255 '\377'
> 
> Sounds what would happen when gdbserver looks for the first watchpoint
> that overlaps the kernel-reported siginfo.si_addr trap address, it finds
> watchpoint 3 first.

What I was saying is that it is really not possible because for
	u.buf[3]=0xff;
kernel does report
	siginfo.si_addr=0x4109bb
And 'Hardware watchpoint 2' is only 2 bytes long (0x4109b8..0x4109b9
inclusive).


> Which is entirely plausible because gdbserver actually iterates backwards:

It really does not matter in which order the watchpoints are because only one
watchpoint range (Hardware watchpoint 3) does match the reported address.

Please verify the technical topics you are unsure about before correcting
people.


Thanks,
Jan