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

[Jim Blandy <jimb@redhat.com>]

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.