Re: [RFA]: pending breakpoint support [1/3]

[Jeff Johnston <jjohnstn at redhat dot com>]

Daniel Jacobowitz wrote:

> On Fri, Jan 30, 2004 at 01:51:07PM -0500, Jeff Johnston wrote:
>  
>
> > > > +  input_radix = b->input_radix;
> > > > +  rc = break_command_1 (b->addr_string, b->flag, b->from_tty, b);
> > > > +  
> > > > +  if (rc == GDB_RC_OK)
> > > > +    /* Pending breakpoint has been resolved.  */
> > > > +    printf_filtered ("Resolves pending breakpoint \"%s\"\n", 
> > > > b->addr_string);
> > > >  
> > > >
> > > >        
> > > Spelling error, though.
> > >
> > >
> > >      
> > Actually, I meant it to be:
> >
> > Breakpoint set at.....
> > Resolves pending breakpoint "....."
> >
> > So the bottom line ties to the breakpoint just set.  If this isn't very 
> > clear I can put "which" in front or just make it "Resolved" which I 
> > think you are alluding to.  If there is some other spelling error, 
> > please point it out as I don't see it.
> >    
>
> I read it and assumed that you meant "Resolved".  I think that
> "resolves" is grammatically confusing here, since there's no implicit
> subject.  How about "Pending breakpoint \"%s\" resolved"?
>  
Ok.

>  
>
> > >      
> > >
> > > > @@ -4779,6 +4888,26 @@ create_breakpoints (struct symtabs_and_l
> > > > 	b->ignore_count = ignore_count;
> > > > 	b->enable_state = bp_enabled;
> > > > 	b->disposition = disposition;
> > > > +	/* If resolving a pending breakpoint, a check must be made to see if
> > > > +	   the user has specified a new condition or commands for the 
> > > > +	   breakpoint.  A new condition will override any condition that was 
> > > > +	   initially specified with the initial breakpoint command.  */
> > > > +	if (pending_bp)
> > > > +	  {
> > > > +	    char *arg;
> > > > +	    if (pending_bp->cond_string)
> > > > +	      {
> > > > +		arg = pending_bp->cond_string;
> > > > +		b->cond_string = savestring (arg, strlen (arg));
> > > > +		b->cond = parse_exp_1 (&arg, block_for_pc (b->loc->address), 
> > > > 0);
> > > > +		if (*arg)
> > > > +		  error ("Junk at end of pending breakpoint condition 
> > > > expression");
> > > > +	      }
> > > > +	    /* If there are commands associated with the breakpoint, they 
> > > > should +	       be copied too.  */
> > > > +	    if (pending_bp->commands)
> > > > +	      b->commands = copy_command_lines (pending_bp->commands);
> > > > +	  }
> > > > 	mention (b);
> > > >     }
> > > > }    
> > > >  
> > > >
> > > >        
> > > Here's the one question.
> > >
> > > The only way to get here with a PENDING_BP is from break_command_1 from
> > > resolve_pending_breakpoint.  So I don't think it is possible for there
> > > to be a condition already set on B, which makes the comment about
> > > "overriding" such a condition a little strange.  Am I right, or is
> > > there some other way to get a condition to here?
> > >
> > >
> > >      
> > The scenario would be:  1. User creates a pending breakpoint with a 
> > condition in the break location.  2. User specifies a condition for the 
> > breakpoint number given back for the pending breakpoint using the 
> > condition command.  3. The shared library gets loaded that resolves the 
> > breakpoint.  The resolution of the breakpoint will find the original 
> > condition in the location string, but won't know about the 2nd one which 
> > gets stored in the pending breakpoint cond_string (see condition_command 
> > support for pending breakpoint).
> >    
>
> I'd have thought the original condition would have been removed from
> addr_string already.  Can we not do that without being able to parse
> the location?  Won't this produce confusing "info breakpoints" output?
>
>  
Well, therein lies the problem.  The word "if" might or might not be 
part of the symbol.  The
regular logic relies on parsing out the symbol first and then looking at 
the aftermath.  I don't have
that luxury so I punt.  It may be slightly confusing if the user does 
the scenario above, but the
displayed pending breakpoint info is meant to be the "original 
breakpoint string" so I don't anticipate
the user will object too much.  Ok or do you have a better idea?

-- Jeff J.