From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15038 invoked by alias); 10 Apr 2013 10:48:18 -0000 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 Received: (qmail 15027 invoked by uid 89); 10 Apr 2013 10:48:18 -0000 X-Spam-SWARE-Status: No, score=-8.9 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 10 Apr 2013 10:48:18 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r3AAmCeR010414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Apr 2013 06:48:13 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r3AAmAGf001428; Wed, 10 Apr 2013 06:48:11 -0400 Message-ID: <5165436A.80900@redhat.com> Date: Wed, 10 Apr 2013 19:45:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Marc Khouzam CC: Hui Zhu , Eli Zaretskii , Hui Zhu , "gdb-patches@sourceware.org" Subject: Re: [PATCH] add -s option to make -break-insert support dprintf References: <515451EA.1000200@mentor.com> <83y5d7wpvq.fsf@gnu.org> ,<516454DA.9040109@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-04/txt/msg00274.txt.bz2 Hi Marc, On 04/10/2013 11:31 AM, Marc Khouzam wrote: > In the orginal patch, having both 'hardware' and 'dprintf' true would > create a hardware breakpoint (not dprintf), but would still set 'ops' > to &dprintf_breakpoint_ops. This didn't look right to me. In fairness, it actually wouldn't, because of: >>> + if (hardware && dprintf) >>> + error (_("-break-insert: -h and -s cannot be use together")); I guess my change at least makes it more obvious in that other spot too. > A side-effect of Pedro's change is that the hardware dprintf case > will be handled properly. I think that is a good thing. However, > I wanted to mention it, as I don't know if there are other changes > needed to handle a hardware dprintf (or if it really should be allowed). > I am allowed to create a hardware breakpoint with a printf condition, > so I guess a hardware dprintf would make sense, but I'm not sure. Yeah, I don't see why it couldn't work. Any kind of watchpoint/breakpoint, really. To me, this exposes that the whole dprintf feature hasn't been exposed to the user at the right abstraction level. It should have been something lower level that allowed constructing dprintfs, or hardware-dprintfs, or watchpoints-dprintfs, etc. The python Stop hook is close, except for the agent side part. Maybe equipping breakpoints with a separate list of "commands that don't interfere with the current execution command at time of hit" would have been closer to home. -- Pedro Alves