From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1724 invoked by alias); 4 Oct 2008 23:07:37 -0000 Received: (qmail 1504 invoked by uid 22791); 4 Oct 2008 23:07:37 -0000 X-Spam-Check-By: sourceware.org Received: from igw3.br.ibm.com (HELO igw3.br.ibm.com) (32.104.18.26) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 04 Oct 2008 23:06:53 +0000 Received: from d24relay01.br.ibm.com (unknown [9.8.31.16]) by igw3.br.ibm.com (Postfix) with ESMTP id 73754390044 for ; Sat, 4 Oct 2008 19:44:18 -0300 (BRST) Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46]) by d24relay01.br.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m94N6grY2683064 for ; Sat, 4 Oct 2008 20:06:42 -0300 Received: from d24av01.br.ibm.com (loopback [127.0.0.1]) by d24av01.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m94N6o5h029570 for ; Sat, 4 Oct 2008 20:06:51 -0300 Received: from [9.18.200.69] ([9.18.200.69]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m94N6ov6029564; Sat, 4 Oct 2008 20:06:50 -0300 Subject: Re: [PATCH 1/4] 'catch syscall' feature -- Architecture-independent part From: =?ISO-8859-1?Q?S=E9rgio?= Durigan =?ISO-8859-1?Q?J=FAnior?= To: Daniel Jacobowitz Cc: Joel Brobecker , gdb-patches@sourceware.org In-Reply-To: <20081003175145.GA15469@caradoc.them.org> References: <1222798409.30389.23.camel@miki> <20081002211256.GO3665@adacore.com> <1223001252.9858.11.camel@miki> <20081003060629.GQ3665@adacore.com> <20081003175145.GA15469@caradoc.them.org> Content-Type: text/plain; charset=iso-8859-1 Date: Sat, 04 Oct 2008 23:07:00 -0000 Message-Id: <1223161694.5956.29.camel@miki> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit 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: 2008-10/txt/msg00122.txt.bz2 Hi Daniel, On Fri, 2008-10-03 at 13:51 -0400, Daniel Jacobowitz wrote: > On Thu, Oct 02, 2008 at 11:06:29PM -0700, Joel Brobecker wrote: > > That's correct. The short answer is that, if we make your catchpoint > > use a more generic type and base the actual implementation of > > breakpoint_ops methods, then, later on, when someone decides to > > implement a new kind of catchpoint with similar functionality, > > then all he should have to do is create a new breakpoint_ops vector > > with appropriate methods, and voila. > > Right. This is what's supposed to be possible, at least. I'm not sure if I understood correctly, but you're saying that the approach that Joel proposed is already working, right? If that's the case, then there should be no problem in "converting" my patch to this new way. Regards, -- Sérgio Durigan Júnior Linux on Power Toolchain - Software Engineer Linux Technology Center - LTC IBM Brazil