From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30715 invoked by alias); 18 Jun 2010 14:35:14 -0000 Received: (qmail 30696 invoked by uid 22791); 18 Jun 2010 14:35:13 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 18 Jun 2010 14:35:02 +0000 Received: (qmail 17097 invoked from network); 18 Jun 2010 14:35:01 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 Jun 2010 14:35:01 -0000 From: Pedro Alves To: Jan Kratochvil Subject: Re: [patch 3/3] bpstat_what removal [rediff] Date: Fri, 18 Jun 2010 14:35:00 -0000 User-Agent: KMail/1.13.2 (Linux/2.6.32-22-generic; KDE/4.4.2; x86_64; ; ) Cc: gdb-patches@sourceware.org, Stan Shebs References: <20100503200217.GD30386@host0.dyn.jankratochvil.net> <201006181242.30972.pedro@codesourcery.com> <20100618140936.GA24028@host0.dyn.jankratochvil.net> In-Reply-To: <20100618140936.GA24028@host0.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006181534.52615.pedro@codesourcery.com> 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/msg00407.txt.bz2 On Friday 18 June 2010 15:09:36, Jan Kratochvil wrote: > There is missing and planned "new invisible breakpoints, with Python code > attached" stated in: > Tom Tromey: Re: [patch 3/3] bpstat_what removal [rediff] > http://sourceware.org/ml/gdb-patches/2010-06/msg00376.html > > which can happen for (after re-hits start to be prevented): > call_func_without_debuginfo (); > line_with_python_invisible_breakpoint; > > > > let's put thread event breakpoints and other kind of event breakpoints we'll > > come up with, or even gdb side tracepoints in the mix. > > I assume you mean the case I have described now above. Yes, those too. By gdb side tracepoints, I mean tracepoints that are all handled by gdb core, with regular software breakpoint locations, instead of relying on the target backend to implement them. Conceptually, I think those python breakpoints, gdb side tracepoints, solib-, jit- and thread- event breakpoints are all pretty much the same in infrun's perpective. When they're hit, some callback is called, which does its own thing, and returns one of "I cause a stop", or "I don't cause a stop, step over me and let the inferior carry on doing what it was doing", or "I don't cause a stop, and I'm now gone, so no need to step over me.". Those python breakpoints sounds a lot like tracepoints to me, and goes in line with what we've discussed before that "tracepoint" as more of an attribute feeling an breakpoint-kind feeling. Actually user breakpoints are pretty much the same too, if you consider that the callback in question something like bpstat_check_breakpoint_conditions. Anyways, there's clearly a distinction between infrun specific breakpoints, and all other kinds of breakpoints. -- Pedro Alves