This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA/commit] arm-tdep.c: Do not single-step after hitting a watchpoint

On 09/30/2014 09:57 AM, Will Deacon wrote:
> On Mon, Sep 29, 2014 at 07:23:05PM +0100, Peter Maydell wrote:
>> Joel Brobecker wrote:
>>> I have been trying to understand the various contributions, and
>>> I admit I am still not quite sure...
>>> Does it look like the patch I proposed is correct? It seems to be
>>> supported by Terry Guo's experiments as well...
>> Note that the ARMv7 architecture allows watchpoints to
>> be implemented as *asynchronous*, in which case what
>> you will see is that you take a watchpoint exception
>> but it may not fire until after the instruction that
>> triggers the watchpoint and possibly several following
>> instructions have all finished execution. This may be
>> what you are seeing in your hardware tests.
> No you won't; the kernel will swallow the async watchpoint and complain in
> dmesg. 

It doesn't seem to swallow it; only warn.  In hw_breakpoint_pending:

	/* Perform perf callbacks. */
	switch (ARM_DSCR_MOE(dscr)) {
		breakpoint_handler(addr, regs);
		WARN(1, "Asynchronous watchpoint exception taken. Debugging results may be unreliable\n");
		watchpoint_handler(addr, fsr, regs);

Note the fallthrough.

In any case, GDB has to care about halt mode, jtag, system, etc.
debugging, not just Linux.

> I'm not aware of any CPU implementations that actually generate these.

Thanks.  Until we hear a clearer report otherwise, that's what I'll
assume going forward.

Pedro Alves

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]