From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9217 invoked by alias); 23 Jun 2010 17:12:07 -0000 Received: (qmail 9189 invoked by uid 22791); 23 Jun 2010 17:12:05 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org Received: from mail-ew0-f41.google.com (HELO mail-ew0-f41.google.com) (209.85.215.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 23 Jun 2010 17:11:58 +0000 Received: by ewy21 with SMTP id 21so349508ewy.0 for ; Wed, 23 Jun 2010 10:11:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.114.13 with SMTP id c13mr1992722ebq.97.1277313115371; Wed, 23 Jun 2010 10:11:55 -0700 (PDT) Received: by 10.213.35.145 with HTTP; Wed, 23 Jun 2010 10:11:55 -0700 (PDT) In-Reply-To: References: Date: Wed, 23 Jun 2010 17:12:00 -0000 Message-ID: Subject: Re: gdb "automation" question From: Steffen Dettmer To: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-06/txt/msg00112.txt.bz2 Hi, thank you for your quick response. On Tue, Jun 22, 2010 at 6:09 PM, Tom Tromey wrote: >>>>>> "Steffen" =3D=3D Steffen Dettmer wr= ites: > > 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? >=A0What you do is write a new convenience function in Python. =A0Do > 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> =A0 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 =3D 0 > > define target ours > =A0target remote etc > =A0set var $flag =3D 1 > end > > define hook-stop > =A0if $flag > =A0 =A0show_log > =A0endif > 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 =A0set var $flag =3D 0 =A0kill 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> =A0 .... other default actions ... > Steffen> =A0 define hook-stop > Steffen> =A0 =A0 =A0show_log > Steffen> =A0 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. =A0I don't have a tree before 7.0 handy, so if you're > using something older, maybe upgrading would help this. =A0Or 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 :-). =A0But you could also CC yourself on the bug: > http://sourceware.org/bugzilla/show_bug.cgi?id=3D11669 > > 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. =A0There 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