This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] aarch64: PR 19806: watchpoints: false negatives -> false positives
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Yao Qi <qiyaoltc at gmail dot com>, gdb-patches at sourceware dot org
- Date: Mon, 20 Jun 2016 16:12:53 +0200
- Subject: Re: [patch] aarch64: PR 19806: watchpoints: false negatives -> false positives
- Authentication-results: sourceware.org; auth=none
- References: <20160606075945 dot GA19395 at host1 dot jankratochvil dot net> <86eg89w2sr dot fsf at gmail dot com> <48622de4-dc45-c48f-7172-495b669f2334 at redhat dot com> <86a8ixvx5k dot fsf at gmail dot com> <7fabd183-eb46-e916-77f2-f62d5c4e4ce7 at redhat dot com> <86oa7bvdi0 dot fsf at gmail dot com> <4f4d2f70-3931-6467-37c7-f97f99ad5c63 at redhat dot com> <380b5288-f46f-3e20-c9c3-8cc8738ee322 at redhat dot com> <20160619182909 dot GA9883 at host1 dot jankratochvil dot net> <d6066c45-e767-59f6-d861-7c75f63f876d at redhat dot com>
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