From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5229 invoked by alias); 4 May 2010 14:10:07 -0000 Received: (qmail 5219 invoked by uid 22791); 4 May 2010 14:10:06 -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; Tue, 04 May 2010 14:10:00 +0000 Received: (qmail 3837 invoked from network); 4 May 2010 14:09:58 -0000 Received: from unknown (HELO macbook-2.local) (stan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 4 May 2010 14:09:58 -0000 Message-ID: <4BE02AB0.6060609@codesourcery.com> Date: Tue, 04 May 2010 14:10:00 -0000 From: Stan Shebs User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Jan Kratochvil CC: gdb-patches@sourceware.org Subject: Re: [patch 3/3] bpstat_what removal References: <20100503200217.GD30386@host0.dyn.jankratochvil.net> In-Reply-To: <20100503200217.GD30386@host0.dyn.jankratochvil.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 2010-05/txt/msg00064.txt.bz2 Jan Kratochvil wrote: > Hi, > > the simple idea is to inline bpstat_what into handle_inferior_event. This > removes enum bpstat_what_main_action and struct bpstat_what currently acting > just as an interface between these two functions. > There's a reason for this actually, which is that it helps keep the myriad of random breakpoint types from infecting the rest of GDB. Breakpoint types are visible globally, and individual breakpoint types are mentioned here and there in the code, but I think it's worthwhile to keep the type enumerations / switches in breakpoint.c as much as possible. There is a pretty good chance that we're going to be doing some refactoring on how breakpoint types are handled - people are interested in the idea of "tracing watchpoints" (or "watching tracepoints" :-) ) for instance - so there's a practical reason to provide interfaces that define the net effect of types, rather than requiring callers to know aracane details of each. Stan