This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH 0/2] Support the new PPC476 processor
On Thursday 31 December 2009 16:27:59, Daniel Jacobowitz wrote:
> On Thu, Dec 31, 2009 at 06:06:48AM +0200, Eli Zaretskii wrote:
> > > Date: Wed, 30 Dec 2009 17:15:35 -0500
> > > From: Daniel Jacobowitz <email@example.com>
> > > Cc: firstname.lastname@example.org, email@example.com,
> > > firstname.lastname@example.org
> > >
> > > > Thanks for the explanations. I think we should emulate this on
> > > > architectures that don't have this in hardware (it doesn't sound
> > > > hard).
> > >
> > > How do you mean? It seems basically impossible to me.
> > How is it impossible to put several breakpoints covering a range of
> > addresses?
> I think ranged breakpoints are typically used with a large range of
> addresses. For instance, I can imagine using them to cover an entire
> shared library - say 1MB of code. Also we don't know which part of
> the range is code and which is data, so using software breakpoints
> indiscriminately could break the program.
There are systems with unlimited hardware watchpoints, though.
Then, there's always the last resort of of single-stepping all-the-way, and
implementing "breakpoints" by stopping when the PC steps into
breakpointed area, a-la software watchpoints.
Also, and nicer, systems with a MMU can implement this without special
debug register support. E.g., by setting the watched/breakpointed
pages to unreadable/unwritable, and trapping on page
faults (filtering out hits that are uninteresting, of course) --- works
best with OS/paging coordination. Wasn't it Solaris' procfs that