This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: gdb "automation" question
Hi,
thank you for your quick response.
On Tue, Jun 22, 2010 at 6:09 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "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?
I am using arm-elf-gdb-6.8.
> Yeah, we've recently been discussing this use case (as a tangent from
> the main discussion) on the patch list.
Ohh, so this means that this is not yet possible...
> 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.
Yes, I think this would solve this.
> I did find a trick you can use to accomplish this with a
> python-enabled gdb.
Ohh, until now I did not even knew that there is a python-enabled
gdb. I found http://sourceware.org/gdb/current/onlinedocs/gdb/Python.html.
http://sourceware.org/gdb/wiki/PythonGdb sounds as this would be
an experimental feature. Are the parts I need stable?
Should I work on branch origin/archer-tromey-python on a git
clone?
>?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.
sounds promising.
Where can I learn more?
> This is ugly, but it does seem to work.
(python extended gdb seems as it could become a lovely feature! :))
I'd have interesting things to learn (GIT, python, gdb...).
Is there some recommended tutorial?
> With a recent enough GDB you can write a Python script to do the
> enabling, which will give you more control over what happens.
Is it needed from repo (as wiki/PythonGdb):
git clone git://sourceware.org/git/archer.git
cd archer; git checkout --track -b python origin/archer-tromey-python
or is there already a released version recent enough?
> 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".
(the "target" inside the define uses the original "target"?
Shouldn't it recurse...)
Not sure if I get this...
shall I add:
define kill mykill
?set var $flag = 0
?kill
end
but what for the crashes? Sometimes gdb shows my that some
trapReset was caught. Should I hook it in some way?
> 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?
No, in my tests there were no other default actions. It was 6.8.
I hope I can re-check with 7.1 tomorrow.
> 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.
It is great to watch gdb improving. Also really great that now
such great documentation exists. And so many new exciting
features added in the last years. Just great.
A big THANK YOU to everyone involved!!!
oki,
Steffen