Re: [rfc] fbreak (Finish Breakpoints by Name)

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Phil" == Phil Muldoon <pmuldoon@redhat.com> writes:

Phil> This command is a usability skin for finish breakpoints.  The command,
Phil> "fbreak" takes a location, and sets a breakpoint on that location.
Phil> When the breakpoint is hit, the "stop" callback on the initial
Phil> breakpoint is called.  This initial breakpoint then turns on process
Phil> record, and places a finish breakpoint in that function to catch
Phil> function exit.  When the function completes, the finish breakpoint
Phil> will print a message.

I think it is cool but I'm not sure about tying it to process record.
Process record has a lot of limitations.

It seems to me that it would really great as a user if I could attach
commands to a breakpoint like this.  However, right now such commands
would attach to the initial breakpoint -- not the one that is hit when
the internal finish breakpoint is hit.

I suppose if we could set commands on both the initial and the finish
breakpoints, then it would be easy to ask for "record" behavior by hand.

Anyway I think maybe more experimentation is needed.

We could use a place to keep things like this -- useful Python hacks
that we think aren't quite fully baked enough to put in the core.

Phil> +        gdb.write("The finish breakpoint has triggered.  If the target\n\

I was under the impression we preferred normal "print" to the use of
gdb.write.

Phil> +       def invoke (self, arg, from_tty):
Phil> +           if arg != "":
Phil> +               linespec = gdb.decode_line (str(arg))

You shouldn't need 'str' here.

Phil> +               # Before we set the breakpoint, warn if there was anything
Phil> +               # unparsed.
Phil> +               if linespec[0] != None:
Phil> +                   gdb.write("Warning: parts of the expression are unparsed.\n")

IMO this ought to be an error.

Tom