From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18582 invoked by alias); 23 Jun 2010 14:42:16 -0000 Received: (qmail 18570 invoked by uid 22791); 23 Jun 2010 14:42:15 -0000 X-SWARE-Spam-Status: No, hits=-5.8 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, 23 Jun 2010 14:42:06 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o5NEfwrh004793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Jun 2010 10:41:58 -0400 Received: from host0.dyn.jankratochvil.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o5NEftRf030276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Jun 2010 10:41:57 -0400 Received: from host0.dyn.jankratochvil.net (localhost [127.0.0.1]) by host0.dyn.jankratochvil.net (8.14.4/8.14.4) with ESMTP id o5NEft50027947; Wed, 23 Jun 2010 16:41:55 +0200 Received: (from jkratoch@localhost) by host0.dyn.jankratochvil.net (8.14.4/8.14.4/Submit) id o5NEfsdx027946; Wed, 23 Jun 2010 16:41:54 +0200 Date: Wed, 23 Jun 2010 14:42:00 -0000 From: Jan Kratochvil To: Tom Tromey Cc: Pedro Alves , gdb-patches@sourceware.org, Stan Shebs Subject: Re: [patch 3/3] bpstat_what removal [rediff] Message-ID: <20100623144154.GA26869@host0.dyn.jankratochvil.net> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-12-10) 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: 2010-06/txt/msg00498.txt.bz2 On Wed, 16 Jun 2010 22:39:44 +0200, Tom Tromey wrote: > >>>>> "Jan" == Jan Kratochvil writes: [...] > 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.) It gets fixed AFAIK. Or at least improved, not sure if the fix is complete. It needs also a patch of this series: Re: [patch 2/3] bpstat_print should consider all candidates http://sourceware.org/ml/gdb-patches/2010-05/msg00368.html As explained by Pedro currently some events are ignored but they get re-hit on a vain attempt to resume at a breakpoint location and all the events get executed properly. Described by Pedro's "Well, not cancel, but postpone." ...: Re: [patch 3/3] bpstat_what removal [rediff] http://sourceware.org/ml/gdb-patches/2010-06/msg00404.html > * bpstat_what is difficult to understand & modify, particularly the table. > (You fixed this.) The table part gets removed even in the Pedro's generally agreed simplification: Re: [patch 3/3] bpstat_what removal [rediff] http://sourceware.org/ml/gdb-patches/2010-06/msg00372.html Other code readability issues are both not agreed upon and they are strongly bound to the "re-hit" bug-to-bug compatibility described above. > * It is too hard to add new kinds of breakpoints. See ifunc or > next-over-throw. > (Maybe partially fixed?) It should become generally easy now even with the Pedro's generally agreed simplification: Re: [patch 3/3] bpstat_what removal [rediff] http://sourceware.org/ml/gdb-patches/2010-06/msg00372.html The is the major change it has been design-approved the actions can get executed in breakpoint.c instead of infrun.c which simplified it a lot. > 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. As the action can get executed from breakpoint.c now it can accordingly set the bpstat_what() result making the "new invisible breakpoints" simple IMO. > 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. There are three levels of independence: No independence - current FSF GDB - everything is encoded as a single decision. This is wrong, some functionality gets lost - PR 9436. Partial independence - Pedro's simplification Re: [patch 3/3] bpstat_what removal [rediff] http://sourceware.org/ml/gdb-patches/2010-06/msg00372.html which makes BPSTAT_WHAT_CHECK_SHLIBS and BPSTAT_WHAT_CHECK_JIT independent thus no longer breaking PR 9436. But it still hides some information as shown in my `set debug infrun' reproducer in Re: [patch 3/3] bpstat_what removal [rediff] http://sourceware.org/ml/gdb-patches/2010-06/msg00403.html unfortunately current GDB code is (reportedly - I do not know a reproducer) relies on this "re-hit" bug as described by Pedro in: Re: [patch 3/3] bpstat_what removal [rediff] http://sourceware.org/ml/gdb-patches/2010-06/msg00404.html Full independence - my original proposals [patch 3/3] bpstat_what removal http://sourceware.org/ml/gdb-patches/2010-05/msg00050.html and with an interface Re: [patch 3/3] bpstat_what removal http://sourceware.org/ml/gdb-patches/2010-05/msg00370.html which have been generally approved as a future goal but currently they (a) seem to be a too large change to be approved in a single step and (b) it may break some bug-to-bug compatibility relying on the "re-hit"s. Thanks, Jan