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: [RFA 2/3] Demote to sw watchpoint only in update_watchpoint


On Wed, 2011-05-04 at 06:06 +0300, Eli Zaretskii wrote:
> > From: Thiago Jung Bauermann <bauerman@br.ibm.com>
> > Cc: Pedro Alves <pedro@codesourcery.com>, gdb-patches@sourceware.org,
> >         uweigand@de.ibm.com
> > Date: Tue, 03 May 2011 21:03:06 -0300
> > 
> > On Tue, 2011-05-03 at 23:29 +0300, Eli Zaretskii wrote:
> > > > From: Pedro Alves <pedro@codesourcery.com>
> > > > Date: Tue, 3 May 2011 19:12:42 +0100
> > > > Cc: bauerman@br.ibm.com,
> > > >  uweigand@de.ibm.com
> > > > 
> > > > I'm proposing getting rid of target_can_use_hardware_watchpoint
> > > > as being part of the core accounting infrastructure.
> > > 
> > > I'm fine with heading that way.  It will certainly be cleaner than the
> > > current mess, which needs a face-lift every few months.
> > 
> > For this scheme to work, GDB will have to be changed to use
> > always-inserted mode exclusively, right? Or at least insert all
> > breakpoints and watchpoints when probing whether a new
> > breakpoint/watchpoint can be created.
> 
> I think what Pedro suggests can (and should) work only for hardware
> watchpoints and breakpoints.  Normal breakpoints and watchpoints
> cannot work that way, they must be inserted at "resume" time.
> 
> So I think always-inserted mode is not the right way here, unless I'm
> missing something.

Ok, I think I'm a bit slow today. Is the following description correct?

Current scheme:

1. The inferior is stopped and all bp_locations are removed.
2. The user asks for a new watchpoint.
3. GDB evaluates the expression and creates the bp_locations.
4. GDB counts all existing watchpoint bp_locations and asks the target 
   whether there's room for one more. Depending on the answer, decides 
   for a hw or sw watch.
5. GDB registers the new watchpoint for insertion.
6. The user asks the inferior to be continued.
7. GDB inserts all breakpoints and watchpoints and resumes the inferior.

Pedro's suggestion:

1. The inferior is stopped and software bp_locations (both breakpoints 
   and watchpoints) are removed. Hardware ones stay in place.
2. The user asks for a new watchpoint.
3. GDB evaluates the expression and creates the bp_locations.
4. GDB tries to insert the bp_locations as hw watches. If that fails, 
   then converts to sw and registers the watchpoint for insertion.
5. The user asks the inferior to be continued.
6. GDB inserts sw breakpoints and watchpoints and resumes the inferior.
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center


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