gdb remote protocol breakpoints (Z0 command)

gdb remote protocol breakpoints (Z0 command)

[David Taylor]

In the manual the Z0 (insert memory breakpoint) command is summarized
thusly:

    Z0,addr,kind[;cond_list...][;cmds:persist,cmd_list...]

Now, cond_list 'is comprised of a series of expressions, concatenated
without separators.  Each expression has the following form:

    X len,expr

len is the length of the bytecode expression and expr is the actual
conditional expression in bytecode form.

That part is fine.  Most of the time when I want a conditional
breakpoint, the expression is expressible in bytecode form.  (In fact,
while I won't attest that they've always been so expressible, I don't
recall any that weren't so expressible).

But, it then goes on to describe cmd_list in similar terms.

There are many things you might want to do at a breakpoint that lack
bytecode operators.  Just for starters,

    . there is no bytecode operator for setting memory

    . there is no bytecode operator for setting registers

    . there is no bytecode operator for calling arbitrary functions

    . there is no 'continue' option (as in: ``after performing the
    requested commands, continue the current thread'')

There are other capabilities that I would like as well, but without the
four mentioned above, I don't consider it very useful at all.

Has anyone else thought about these issuses and possibly sketched out
extensions to allow such capabilities?

[The 'continue' command would likely be an extension to the Z0 command,
the others would likely be extensions to the bytecode language.]

If we (EMC) were to do something in our gdb and/or remote stub, I would
want it to be compatible with what others are doing / thinking of doing.

Thanks.

David
--
David Taylor
dtaylor at emc dot com

Re: gdb remote protocol breakpoints (Z0 command)

[Tom Tromey]

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.

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.

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

Re: gdb remote protocol breakpoints (Z0 command)

[Yao Qi]

On 06/19/2014 10:44 PM, David Taylor wrote:
> There are many things you might want to do at a breakpoint that lack
> bytecode operators.  Just for starters,
> 
>     . there is no bytecode operator for setting memory
> 
>     . there is no bytecode operator for setting registers

It is fine to extend bytecode for setting memory and registers...

> 
>     . there is no bytecode operator for calling arbitrary functions

... but calling functions is too complex to be operated by bytecode.
Each bytecode operator just does simple/primitive operation.  If we've
already had bytecode for setting memory and registers, GDB may generate
a sequence of bytecode (including setting memory and registers) to do
function call.  However, I am not very sure.

> 
>     . there is no 'continue' option (as in: ``after performing the
>     requested commands, continue the current thread'')
> 
> There are other capabilities that I would like as well, but without the
> four mentioned above, I don't consider it very useful at all.
> 
> Has anyone else thought about these issuses and possibly sketched out
> extensions to allow such capabilities?
> 
> [The 'continue' command would likely be an extension to the Z0 command,
> the others would likely be extensions to the bytecode language.]

We have a kind of breakpoint, dprintf, which is a breakpoint plus
printing and a 'continue' command at the end.  It has some flaws, but
closed to your needs.

If you don't require much interactive operations, tracepoint is a better
choice, IMO.

-- 
Yao (齐尧)

Re: gdb remote protocol breakpoints (Z0 command)

[Frank Ch. Eigler]

David Taylor <dtaylor@emc.com> writes:

> [...]
>     . there is no bytecode operator for setting memory
>     . there is no bytecode operator for setting registers
> [...]

Can you elaborate why you wish to modify state in breakpoint
conditionals?


- FChE

Re: gdb remote protocol breakpoints (Z0 command)

[David Taylor]

Tom Tromey <tromey@redhat.com> 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.

Re: gdb remote protocol breakpoints (Z0 command)

[David Taylor]

Frank Ch. Eigler <fche@redhat.com> wrote:

> 
> David Taylor <dtaylor@emc.com> writes:
> 
> > [...]
> >     . there is no bytecode operator for setting memory
> >     . there is no bytecode operator for setting registers
> > [...]
> 
> Can you elaborate why you wish to modify state in breakpoint
> conditionals?

One of the options with Z0 breakpoints is 'persist' -- you can create a
breakpoint that sticks around when GDB disconnects.  I don't know why I
would want a persistent breakpint if it could neither alter state and
nor call functions.

Things that I envision using them for include

. quick and dirty patching before rebuilding

. collecting debugging information

If you can alter memory you can turn logging / event recording on and
off to just collect information in the areas of interest and generate
fewer messages / fewer records.

I think that pushing the 'conditional' part of the breakpoint to the
stub -- with existing limitations -- is very useful.  I think that
without extensions the 'persistence' and 'command list' parts aren't
very useful.

I'm curious, how do you envision using the 'persistence' and 'command
list' parts given the current limitations?

Re: gdb remote protocol breakpoints (Z0 command)

[David Taylor]

Yao Qi <yao@codesourcery.com> wrote:

> If you don't require much interactive operations, tracepoint is a better
> choice, IMO.

Actually, we use tracepoints quite extensively.

Both our old and our new stubs support tracepoints; our use of
tracepoints preceeds GDB support for tracepoints.

My first use of function calling at a breapoint goes back more than a
decade.  I've used it for things like setting a breakpoint on a
troublesome functions and then creating a command list like --

    print that the function was called and its arguments; for
    structures, possibly print key elements of the structure

    print interesting global variables

    print a backtrace

    disable the current breakpoint

    set $retval = <current function>(<current arguments>)

    print return value

    re-enable breakpoint

    return $retval

    continue

So, we end up with the function arguments, the return value, and
selected other interesting information each time the function is called.

Re: gdb remote protocol breakpoints (Z0 command)

[Frank Ch. Eigler]

dtaylor wrote:

> [...]
> Both our old and our new stubs support tracepoints; our use of
> tracepoints preceeds GDB support for tracepoints.

I think I remember those early days.


> I've used it for things like setting a breakpoint on a
> troublesome functions and then creating a command list like --
>
>     print that the function was called and its arguments; for
>     structures, possibly print key elements of the structure
> [...]
>     print a backtrace
> [...]
>     set $retval = <current function>(<current arguments>)
> [...]

Uploading enough intelligence & information into the gdbstub
to perform inferior function calls, or especially backtraces,
is going to be a tough hill to climb.


>     re-enable breakpoint
>
> So, we end up with the function arguments, the return value, and
> selected other interesting information each time the function is called.

(Hey, you guys need to try out systemtap. :-)


- FChE