Re: gdb "automation" question

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Steffen" == Steffen Dettmer <steffen.dettmer@googlemail.com> writes:

Steffen> I've got questions regarding gdb "automation" which I want to use
Steffen> to pass "log file" information from a remote target.

What version of gdb are you using?

Steffen> Best would be to show this right after a message was added. So in
Steffen> the log handler I added a call to an empty static function
Steffen> logHook() and tried:
Steffen> define ena_log
Steffen>   b logHook
Steffen>   commands
Steffen>     silent
Steffen>     show_log
Steffen>     continue
Steffen>   end
Steffen> end

Steffen> This has the big disadvantage that it breaks stepping (commands
Steffen> "next" and so on)

Yeah, we've recently been discussing this use case (as a tangent from
the main discussion) on the patch list.

Unless I really misread it, I think there is some agreement that we
should have a new flag on a breakpoint that would tell the gdb internals
"after the commands are done, continue stepping".

This would solve this problem plus a few other similar things.


I did find a trick you can use to accomplish this with a python-enabled
gdb.  What you do is write a new convenience function in Python.  Do all
the work in this function, then have the function always return 0.
Finally, make your breakpoint condition call this function.

This is ugly, but it does seem to work.

Steffen> Another problem is that to reconnect all breakpoints
Steffen> must be disabled ("dis") but afterwards cannot be enabled ("ena"
Steffen> would enable all breakpoints, including the breakpoints disabled
Steffen> before the "dis" - of course!). The numbers of the break points
Steffen> of course change, so the script cannot do something like "ena 12"
Steffen> or "enable breakpoint m/logHook/" or so.

With a recent enough GDB you can write a Python script to do the
enabling, which will give you more control over what happens.

Steffen> define hook-stop
Steffen>   show_log
Steffen> end

Steffen> Unfortunately directly after rebooting (before "target remote"
Steffen> and "continue"), the hook cannot work. I have to CTRL-C all the
Steffen> time to cancel hook execution.

I guess you could make a flag and a new phony "target":

set var $flag = 0

define target ours
  target remote etc
  set var $flag = 1
end

define hook-stop
  if $flag
    show_log
  endif
end

Then have users use "target ours" instead of "target remote".

Steffen> define defaction
Steffen>   .... other default actions ...
Steffen>   define hook-stop
Steffen>      show_log
Steffen>   end
Steffen> end
Steffen> but I get an error ("This command cannot be used at top level").

At least in the current sources this error only comes from the
tracepoint code.  I don't have a tree before 7.0 handy, so if you're
using something older, maybe upgrading would help this.  Or maybe the
"..." includes tracepoint commands?

Steffen> Best would be a kind of "at this position perform an action and
Steffen> continue" that would not interference with user breakpoints and
Steffen> stepping with "next".

A patch would be great :-).  But you could also CC yourself on the bug:
http://sourceware.org/bugzilla/show_bug.cgi?id=11669

FWIW, giving Python better access to "inferior control" (stuff like
noticing when the inferior stops, starts, is killed, etc) is also on our
wish list.  There were some initial patches from last year's Summer of
Code, but we haven't integrated those yet, and in any case I don't think
they went quite far enough.

Tom