From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11103 invoked by alias); 16 May 2012 20:46:49 -0000 Received: (qmail 11094 invoked by uid 22791); 16 May 2012 20:46:49 -0000 X-SWARE-Spam-Status: No, hits=-3.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from elasmtp-kukur.atl.sa.earthlink.net (HELO elasmtp-kukur.atl.sa.earthlink.net) (209.86.89.65) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 16 May 2012 20:46:36 +0000 Received: from [68.96.200.16] (helo=macbook2.local) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1SUl6z-0008Cd-08; Wed, 16 May 2012 16:46:21 -0400 Message-ID: <4FB41216.2080508@earthlink.net> Date: Wed, 16 May 2012 20:46:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Tom Tromey CC: gdb-patches@sourceware.org Subject: Re: [PATCH v2] dynamic printf References: <4FA8BC97.2000801@earthlink.net> <4FA8D049.109@codesourcery.com> <4FB12A8E.7040905@earthlink.net> <87ipfvop8i.fsf@fleche.redhat.com> In-Reply-To: <87ipfvop8i.fsf@fleche.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: ae6f8838ff913eba0cc1426638a40ef67e972de0d01da94068cda819a15f3e90e1bf2f01861abecf350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-05/txt/msg00627.txt.bz2 On 5/16/12 1:17 PM, Tom Tromey wrote: >>>>>> "Stan" == Stan Shebs writes: > Sorry about the delay on this. > > Stan> + /* Manufacture a printf/continue sequence. */ > Stan> + if (printf_line) > Stan> + { > Stan> + struct command_line *printf_cmd_line, *cont_cmd_line = NULL; > Stan> + > Stan> + cont_cmd_line = xmalloc (sizeof (struct command_line)); > Stan> + cont_cmd_line->control_type = simple_control; > Stan> + cont_cmd_line->body_count = 0; > Stan> + cont_cmd_line->body_list = NULL; > Stan> + cont_cmd_line->next = NULL; > Stan> + cont_cmd_line->line = xstrdup ("continue"); > Stan> + > Stan> + printf_cmd_line = xmalloc (sizeof (struct command_line)); > Stan> + printf_cmd_line->control_type = simple_control; > Stan> + printf_cmd_line->body_count = 0; > Stan> + printf_cmd_line->body_list = NULL; > Stan> + printf_cmd_line->next = cont_cmd_line; > Stan> + printf_cmd_line->line = printf_line; > Stan> + > Stan> + breakpoint_set_commands (b, printf_cmd_line); > > I thought this approach would break "next"ing over a dprintf location. Indeed, thus this part of the introduction to this patch: :-) "... Joel previously noted a problem with the "continue" in the command list, which is that stepping/nexting over a dprintf becomes a continue instead (this is a problem for general breakpoint command lists as well). I tinkered with bpstats a bit, but didn't come up with a good solution. One possibility might be a new pseudo-command for breakpoint command lists, that resumes the program using the same proceed() arguments as the command that caused the breakpoint hit." If nobody comes up with a good idea here, it should probably be documented as a limitation. I wonder if some relatively recent infrun tinkering changed the breakpoint command behavior - you'd think *somebody* would have bumped into it sometime in the past 20 years... Ironically, the agent version doesn't have this problem, because the resume happens automatically inside GDBserver, and GDB is oblivious. > Stan> +void > Stan> +dprintf_command (char *arg, int from_tty) > > I think this could be static. > Good point, I tweaked it for the agent patch. Stan