From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25791 invoked by alias); 14 Mar 2012 15:28:07 -0000 Received: (qmail 25781 invoked by uid 22791); 14 Mar 2012 15:28:07 -0000 X-SWARE-Spam-Status: No, hits=-6.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; Wed, 14 Mar 2012 15:27:54 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q2EFRnIV032371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Mar 2012 11:27:49 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q2EFRmm6014172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 14 Mar 2012 11:27:49 -0400 From: Tom Tromey To: Stan Shebs Cc: Andreas Schwab , gdb-patches@sourceware.org Subject: Re: [PATCH] dynamic printf References: <4F4DCDD5.2040807@earthlink.net> <4F5FD3A6.1090106@earthlink.net> Date: Wed, 14 Mar 2012 15:28:00 -0000 In-Reply-To: <4F5FD3A6.1090106@earthlink.net> (Stan Shebs's message of "Tue, 13 Mar 2012 16:09:26 -0700") Message-ID: <87d38fdwy3.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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-03/txt/msg00481.txt.bz2 >>>>> "Stan" == Stan Shebs writes: Stan> Another consideration is how the collection looks in an info break Stan> command. If dynamic prints are a different kind of breakpoint, then Stan> you can (in theory) filter the breakpoint listing to a single Stan> category, but if they are just breakpoints with special commands, Stan> they'll continue to be in the big list. I tend to prefer a new command for this reason and also KISS. Stan> My intuition isn't giving me a strong read on which approach users Stan> will like better. As the goal is at least partly to entice Stan> printf()+recompile users into using a GDB command instead, I think it Stan> needs to be among GDB's simpler commands. Maybe include both Stan> syntaxes, mapping down to same functionality? dprintf breakpoints have different semantics from regular breakpoints, too, don't they? They are non-stopping. It seems to me that if you go the suffix route, then you also need ways to control the stopping-ness, and to change or delete the printf stuff. I think it is simpler and hardly any less convenient for users to just have dprintf and regular breakpoints be separate things. If we get a flood of bug reports to the contrary, we can always go back and add the printf qualifier later. Tom