From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3962 invoked by alias); 18 May 2012 15:38:58 -0000 Received: (qmail 3860 invoked by uid 22791); 18 May 2012 15:38:57 -0000 X-SWARE-Spam-Status: No, hits=-7.4 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,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; Fri, 18 May 2012 15:38:42 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q4IFcevA010400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 May 2012 11:38:40 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q4IFcc4E024821; Fri, 18 May 2012 11:38:39 -0400 Message-ID: <4FB66CFE.6050500@redhat.com> Date: Fri, 18 May 2012 15:38:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Tom Tromey CC: Stan Shebs , 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> <4FB41216.2080508@earthlink.net> <4FB4137C.6000107@redhat.com> <4FB4293B.9030303@earthlink.net> <87396zmuyk.fsf@fleche.redhat.com> In-Reply-To: <87396zmuyk.fsf@fleche.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg00690.txt.bz2 On 05/17/2012 02:56 AM, Tom Tromey wrote: > In this particular case, though, I think you could do it by just having > the 'printf' invocation not be 'commands' stuck onto a breakpoint, but > instead a per-dprintf method that is run at the appropriate moment, a la > the Python 'Breakpoint.stop' method. I agree. I can't be within bkpt_ops->check_status (even though that'd be hacky), as I think you'd want to support conditions on dprintf, and those are checked after check_status is consulted. Another question is, is the user supposed to set commands on dprintf? Currently you get: (gdb) dprintf 36, "hello" Dprintf 2 at 0x4005e0: file ../../../src/gdb/testsuite/gdb.base/dprintf.c, line 36. (gdb) info breakpoints 2 dprintf keep y 0x00000000004005e0 in main at ../../../src/gdb/testsuite/gdb.base/dprintf.c:36 printf "hello" continue (gdb) commands 2 Type commands for breakpoint(s) 2, one per line. End with a line saying just "end". >echo "world" >end (gdb) info breakpoints Num Type Disp Enb Address What 2 dprintf keep y 0x00000000004005e0 in main at ../../../src/gdb/testsuite/gdb.base/dprintf.c:36 breakpoint already hit 1 time echo "world" Another related weekness of the current implementation is that a regular breakpoint that should cause a stop set at the same address as a dprintf no longer works correctly, due to the forced "continue". E.g., (gdb) dprintf 36, "hello" Dprintf 2 at 0x4005e0: file ../../../src/gdb/testsuite/gdb.base/dprintf.c, line 36. (gdb) b 36 Note: breakpoint 2 also set at pc 0x4005e0. Breakpoint 3 at 0x4005e0: file ../../../src/gdb/testsuite/gdb.base/dprintf.c, line 36. (gdb) info breakpoints Num Type Disp Enb Address What 2 dprintf keep y 0x00000000004005e0 in main at ../../../src/gdb/testsuite/gdb.base/dprintf.c:36 printf "hello" continue 3 breakpoint keep y 0x00000000004005e0 in main at ../../../src/gdb/testsuite/gdb.base/dprintf.c:36 (gdb) b 39 Breakpoint 4 at 0x40060e: file ../../../src/gdb/testsuite/gdb.base/dprintf.c, line 39. (gdb) c Continuing. Breakpoint 2, main (argc=1, argv=0x7fffffffdd48) at ../../../src/gdb/testsuite/gdb.base/dprintf.c:36 36 printf ("kickoff\n"); hellokickoff also to stderr Breakpoint 4, main (argc=1, argv=0x7fffffffdd48) at ../../../src/gdb/testsuite/gdb.base/dprintf.c:39 39 foo (loc++); (gdb) Breakpoint 3 causes a stop, but GDB starts by running the commands of breakpoint 2 (the dprintf), just because it has a lower number, and that includes the "continue", so breakpoint 3 is lost. A similar issue happens with more than one dprintf installed on the same location -- only one would run. Multiple dprintfs on the same location would be useful when you set different conditions on each (like with multiple breakpoints on the same location). -- Pedro Alves