Re: gdb remote protocol breakpoints (Z0 command)

Tom Tromey <[email protected]> wrote:

> David> There are many things you might want to do at a breakpoint that lack
> David> bytecode operators.  Just for starters,
> [...]
> David>     . there is no bytecode operator for calling arbitrary functions
> 
> I think this one is a pain to push into the remote, probably why it
> wasn't done.

It would be reasonable to restrict the number of arguments to a small
integer.  Another option might be to assume that previous operations
have set up the registers and stack and just call that address -- assume
that the arguments have already been 'pushed' -- should be doable on
most architectures; but, I admit it wouldn't be easy and would involve a
fair bit ot GDB work, not just stub work, to make it useful.

> David>     . there is no 'continue' option (as in: ``after performing the
> David>     requested commands, continue the current thread'')
> 
> This seems like a different kind of thing altogether.  Though I'm not
> sure I understand the use case.  As a breakpoint condition it could be
> done by always returning zero.

Sometimes I want to set a breakpoint that does something (e.g., modify
variables, call functions) and then continues.

For example, if you have an elusive bug, you might want to call a
function that collects or prints some debugging information.

Our you might want to set a variable -- suppose foo should always be 42
when a particular function is called, but sometimes it is called with
other values.

If you're involving GDB, you could set a breakpoint with a condition of
(foo != 42), and then have commands like:

    set foo=42
    where
    continue

or, if you plan on disconnecting, maybe just

    set foo=42
    continue

The more that can be pushed to the target, the fewer round trips that
will be required and the less overall impact on the target system
performance.

Reasons why you might want to do this include -- suppose it takes 5-10
minutes to rebuild and then another 5-10 minutes to download and reboot.
So, you're talking 10-20 minutes *plus* whatever time was required to
get the system into the current 'misbehaving' state.

> David> Has anyone else thought about these issuses and possibly sketched out
> David> extensions to allow such capabilities?
> 
> We're looking at extending the "compile" command to add "compile cond",
> where the compiled condition is injected into the inferior.  This is
> still a little ways down the road for us.
> 
> This isn't entirely straightforward, though, and has other tradeoffs.
> Also extending agent expressions would be reasonable.  I suppose some
> feature negotiation here would be needed.
> 
> Tom

We aren't yet at the point of implementing condition lists and command
lists for the Z0 command for our new stub.  It's probably at least a few
months off.  There's certainly higher priority items on the list.