From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1923 invoked by alias); 16 Jun 2010 20:40:12 -0000 Received: (qmail 1905 invoked by uid 22791); 16 Jun 2010 20:40:06 -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; Wed, 16 Jun 2010 20:39:55 +0000 Received: from int-mx04.intmail.prod.int.phx2.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.17]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o5GKdkMJ003167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Jun 2010 16:39:47 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx04.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o5GKdkRc008883; Wed, 16 Jun 2010 16:39:46 -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 o5GKdjLY004518; Wed, 16 Jun 2010 16:39:45 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id A2F7F3792D1; Wed, 16 Jun 2010 14:39:44 -0600 (MDT) From: Tom Tromey To: Jan Kratochvil Cc: Pedro Alves , gdb-patches@sourceware.org, Stan Shebs Subject: Re: [patch 3/3] bpstat_what removal [rediff] References: <20100503200217.GD30386@host0.dyn.jankratochvil.net> <20100517214507.GC25843@host0.dyn.jankratochvil.net> <20100612170137.GA2636@host0.dyn.jankratochvil.net> <201006151608.20224.pedro@codesourcery.com> <20100615215402.GA29723@host0.dyn.jankratochvil.net> Reply-To: tromey@redhat.com Date: Wed, 16 Jun 2010 20:40:00 -0000 In-Reply-To: <20100615215402.GA29723@host0.dyn.jankratochvil.net> (Jan Kratochvil's message of "Tue, 15 Jun 2010 23:54:02 +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-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: 2010-06/txt/msg00376.txt.bz2 >>>>> "Jan" == Jan Kratochvil writes: Pedro> Do you think it would be hard to split this into smaller pieces? Jan> Yes, I will do - just later. IMO we should probably more talk Jan> about its goal than about specifics of the implementation. Yeah. I read this thread and I had some trouble following it. I hope this note doesn't further confuse things. Pedro> - It should be possible to fix PR 9436 without Jan> We can pretend PR 9436 does not exist. One thing I would like to understand better is the long-term design. It seems to me that right now we have a few problems. I would like to understand (1) whether and how your patch fixes them, and (2) what our (by which I guess I mostly mean Pedro's :-) ideal design would look like. My understanding of the problems: * We don't nicely handle multiple breakpoints at one location. (AFAIK not touched by your change.) * bpstat_what is difficult to understand & modify, particularly the table. (You fixed this.) * It is too hard to add new kinds of breakpoints. See ifunc or next-over-throw. (Maybe partially fixed?) For multiple breakpoints ... to me it seems like we want to have some way to notify *all* the breakpoints at a given spot, with some kind of decision making coming later about how to proceed. A case that has come up a couple times is having a way for Python to add new invisible breakpoints, with Python code attached. E.g., suppose you wanted to track malloc+free. You would want to put breakpoints on these that don't interfere with stepping, but you would also want to make sure that the Python handler is run every time the breakpoint is hit -- even if the user also does "break malloc". So here you'd like some sorting: have the internal breakpoint actions trigger first, collect their responses ("continue the current operation") and then the user breakpoints. I suppose we'd have to look at a lot more cases to see if there is some sensible generic approach. Pedro> To recap, IMO, the current problem with bpstat_main_action is Pedro> that a few of its values aren't really independent and mutually Pedro> exclusive with the others -- BPSTAT_WHAT_CHECK_SHLIBS and Pedro> BPSTAT_WHAT_CHECK_JIT. Jan> What if a new breakpoint type wants to stop? What if a new Jan> breakpoint type does not want to stop? And how they combine if Jan> they happend together with other events? While there exists answer Jan> for it I do not know offhand. I know offhand with my Jan> implementation. I should post a patch introducing new breakpoint Jan> types in both variants of the bpstat_what implementation. Are you saying that the bpstat_main_action actually encodes several things which should actually be independent? I think that is consistent with what I see in your patch, I just wanted to be sure. Pedro> - I feel that even getting rid of the table bpstat_what_main_action Pedro> table Jan> Yes, it has to be done. Yes. Tom