This is the mail archive of the gdb-patches@sourceware.org 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: [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 <drow@false.org>
> > > Cc: gdb-patches@sourceware.org, luisgpm@linux.vnet.ibm.com,
> > > 	tyrlik@us.ibm.com
> > > 
> > > > 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
implemented this? 

-- 
Pedro Alves


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