This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Faster stepping amidst breakpoints
- From: Daniel Jacobowitz <dan at codesourcery dot com>
- To: Maxim Grigoriev <maxim at tensilica dot com>
- Cc: Joel Brobecker <brobecker at adacore dot com>, "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>, Marc Gauthier <marc at tensilica dot com>, Maxim Grigoriev <maxim at mail dot tensilica dot com>
- Date: Fri, 4 Feb 2011 11:32:59 -0500
- Subject: Re: Faster stepping amidst breakpoints
- References: <4D3A114D.7010301@tensilica.com> <20110123001433.GA6352@caradoc.them.org> <20110131044951.GG2384@adacore.com> <4D4B31F4.7040407@tensilica.com>
On Thu, Feb 03, 2011 at 02:53:40PM -0800, Maxim Grigoriev wrote:
> 2) I think in the embedded-system world it does matter
> when crashing / detaching GDB leaves target memory
> and/or registers changed.
Yes - if your agent does breakpoint management using z/Z, then it has
the opportunity to clean up as long as the agent doesn't crash. IMO
that's a reasonable expectation; if the agent crashes, your target is
probably in an unrecoverable state anyway.
> What I meant was a target agent, which can
>
> -- realize it's about to single-step over an inserted
> breakpoint and then handle it properly ;
>
> -- watch out for shutting-down GDB communications,
> while counting time-outs, and then return target to the
> reliable state essentially making GDB non-intrusive.
I suggest separating these and dealing with them as separate concerns.
A related issue is watchpoints; different agents (and SoCs) handle
the current instruction after hitting a watchpoint differently. For
instance, GDB assumes all MIPS targets have nonsteppable watchpoints
and we have one where that's clearly not true...
--
Daniel Jacobowitz
CodeSourcery