I think permanent breakpoints are fundamentally broken as is (was: Re: [PATCH] Permanent breakpoints degrade to normal breakpoints on enable)

[Pedro Alves <palves at redhat dot com>]

On 10/18/2013 03:47 PM, Andrew Burgess wrote:
> This patch:
>    https://sourceware.org/ml/gdb-patches/2012-01/msg00964.html
> 
> introduced what I believe is a stray line that causes permanent
> breakpoints to become normal breakpoints if the user ever tries
> to "enable" the permanent breakpoint.

I actually think "permanent breakpoints" are quite weird beasts,
both from a user interface, and implementation perspectives.

First, they're displayed as enabled=='n':

(gdb) b main
Breakpoint 3 at 0x40053c: file ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S, line 29.
(gdb) info breakpoints
Num     Type           Disp Enb Address            What
3       breakpoint     keep n   0x000000000040053c ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S:29

If one can't ever disable those, then that's just ... odd,
to say the least.

Then, why can't you really disable them?  If one adds
commands to such a breakpoint, they're _always_ ran:

(gdb) start
Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.arch/i386-permbkpt
...
Temporary breakpoint 1, main () at ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S:29
29              int3
(gdb) b main
Breakpoint 2 at 0x40053c: file ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S, line 29.
(gdb) info breakpoints
Num     Type           Disp Enb Address            What
2       breakpoint     keep n   0x000000000040053c ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S:29
(gdb) commands
Type commands for breakpoint(s) 2, one per line.
End with a line saying just "end".
>echo "hello!"
>end
(gdb) disable 2
(gdb) start
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Temporary breakpoint 3 at 0x40053c: file ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S, line 29.
Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.arch/i386-permbkpt

Breakpoint 2, main () at ../../../src/gdb/testsuite/gdb.arch/i386-permbkpt.S:29
29              int3
"hello!"(gdb)

I claim that one should be able to disable such a breakpoint,
and that GDB would behave just like it the user hadn't
created it that case.

And then, "permanent"-ness is a property of the breakpoint.
But it should actually be an implementation detail of a _location_.

This bit in infrun.c:

  /* Normally, by the time we reach `resume', the breakpoints are either
     removed or inserted, as appropriate.  The exception is if we're sitting
     at a permanent breakpoint; we need to step over it, but permanent
     breakpoints can't be removed.  So we have to test for it here.  */
  if (breakpoint_here_p (aspace, pc) == permanent_breakpoint_here)
    {
      if (gdbarch_skip_permanent_breakpoint_p (gdbarch))
	gdbarch_skip_permanent_breakpoint (gdbarch, regcache);
      else
	error (_("\
The program is stopped at a permanent breakpoint, but GDB does not know\n\
how to step past a permanent breakpoint on this architecture.  Try using\n\
a command like `return' or `jump' to continue execution."));
    }

will do nasty things if we have a multiple location breakpoint
where the whole breakpoint was set to "permanent" if one of
the locations happened to be permanent, but the one GDB is
resuming from is not...


(I'm not even sure the whole "if you want to have GDB move past
a hardcoded trap for you, set a breakpoint on top" user interface
is actually sane at all.  Could make more sense to actually have
a "permanent breakpoint" command, distinct from a normal
breakpoint.  Then, continuing from a normal breakpoint on top
of a trap would actually execute the trap, and report the SIGTRAP
to the user, giving the user control over whether to pass that
signal back to the program).

-- 
Pedro Alves