This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: question about ARM watchpoints
- From: Pedro Alves <palves at redhat dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: Gareth McMullin <gareth at blacksphere dot co dot nz>, gdb at sourceware dot org
- Date: Fri, 05 Sep 2014 09:17:37 +0100
- Subject: Re: question about ARM watchpoints
- Authentication-results: sourceware.org; auth=none
- References: <20140901085743 dot GG4981 at adacore dot com> <CAL8qUbqTyBAkrXnN=DxmL5d3h5nwnfv=dO-vDdqxB+kVrZNzSQ at mail dot gmail dot com> <540903B0 dot 3000009 at redhat dot com> <20140905035127 dot GA27655 at adacore dot com>
On 09/05/2014 04:51 AM, Joel Brobecker wrote:
>> So sounds like this line should be skipped on ARMv7-M:
>>
>> arm-tdep.c: set_gdbarch_have_nonsteppable_watchpoint (gdbarch, 1);
>>
>> Could you try removing it?
>>
>> But then I wonder why we never heard of this before. Are there
>> ARMv7-M's that behave differently? And what about ARMv6-M ?
>
> That's what I wanted to try too, and will do soon. As to why we never
> heard of this before - the only affirmative answer would be from someone
> better able to undertand the docs than me. But here's a wild guess: the
> fact that GDB stopped one instruction too late is invisible to the user
> 99% of the time. What triggered me seeing it was a change in code
> generation which caused the update to be at the penultimate instruction
> of a function. I wouldn't have seen it if the update was anywhere before
> that.
Ah, indeed.
Hmm. Sounds like we need a test to catch this. :-)
Most preferably, a portable one, which may be tricky.
I've written something like this before:
volatile int i1;
volatile int i2;
volatile int i3;
int main ()
{
i1 = 1;
i2 = 2;
i3 = 3;
}
assuming each write would be one insn, but, then that turned
out to be a wrong assumption, for ARM even, I think.
Hmm... I had an idea. How about:
volatile int global;
set_global (int val)
{
global = val;
}
main ()
{
set_global (1);
set_global (2);
}
#01 - run to main
#02 - set a _software_ watchpoint on i1 (w/ hw watchpoints force-disabled)
#03 - continue
#04 - (GDB single-steps the inferior, and checks the watchpoint's
value at each step.)
#05 - watchpoint triggers
#06 - the PC now points to the instruction right after the instruction that
actually caused the memory write. So this is the address a hardware
watchpoint should present the stop to the user too. Store the PC address.
#07 - delete the software watchpoint
#08 - set a _hardware_ watchpoint on i1.
#09 - continue
#10 - hardware watchpoint triggers. PC should point to the address
stored in #6.
Thanks,
Pedro Alves