From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15748 invoked by alias); 22 Jun 2010 16:09:38 -0000 Received: (qmail 15717 invoked by uid 22791); 22 Jun 2010 16:09:30 -0000 X-SWARE-Spam-Status: No, hits=-5.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 22 Jun 2010 16:09:17 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o5MG9BY2003796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Jun 2010 12:09:11 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o5MG9Bts001131; Tue, 22 Jun 2010 12:09:11 -0400 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id o5MG9AkY021111; Tue, 22 Jun 2010 12:09:11 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 3F9B088804F; Tue, 22 Jun 2010 10:09:09 -0600 (MDT) From: Tom Tromey To: Steffen Dettmer Cc: gdb@sourceware.org Subject: Re: gdb "automation" question References: Reply-To: tromey@redhat.com Date: Tue, 22 Jun 2010 16:09:00 -0000 In-Reply-To: (Steffen Dettmer's message of "Tue, 22 Jun 2010 16:50:53 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00099.txt.bz2 >>>>> "Steffen" == Steffen Dettmer 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