Re: [RFA]: breakpoint.c patch (prelude to pending breakpoint support)

[Daniel Jacobowitz <drow at mvista dot com>]

On Thu, Dec 11, 2003 at 03:33:34PM -0500, Jim Blandy wrote:
> 
> Daniel Jacobowitz <drow@mvista.com> writes:
> > Right now, there are five possible enable states:
> >   enabled
> >   disabled
> >   permanent
> >   call_disabled
> >   shlib_disabled
> > 
> > I'm not convinced that permanent should even be on the list.  It's a
> > real oddball; and there's no reason that GDB couldn't virtually
> > "disable" a permanent breakpoint (step over it automatically when
> > hitting it; give it an always-false condition, in effect).
> 
> I'm responsible for adding the permanent breakpoint kludge.
> 
> Permanent breakpoints were added for HP-UX, where the dynamic linker
> lives in a special region of memory that the debugger cannot modify.
> The breakpoint instruction is hard-coded into the function; and GDB
> cannot write to that address to remove it.  pa64solib.c seems to be
> the only code that creates them.
> 
> In an earlier message, you said:
> > It's not clear what to do with permanent breakpoints (I don't think
> > that should be an enable state, long term!) so I chose the version
> > with minimal textual changes.
> 
> Do you mean, here, that having breakpoint_enabled return false for
> permanent breakpoints results in fewer changes overall?  I would
> expect the opposite --- permanent breakpoints really are enabled.

Yes, but most code either:
  - Doesn't know about permanent breakpoints
or
  - Doesn't want to deal with permanent breakpoints

Take a look at the patch Jeff posted yesterday for breakpoint.c to see
how this happens.  I suspect it's mostly the former; if you wanted to
add permanent breakpoints to breakpoint_enabled() you'd have to review
all its callers to see the effect (which would be easier now).

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer