From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11279 invoked by alias); 4 Oct 2008 23:04:46 -0000 Received: (qmail 11269 invoked by uid 22791); 4 Oct 2008 23:04:45 -0000 X-Spam-Check-By: sourceware.org Received: from igw1.br.ibm.com (HELO igw1.br.ibm.com) (32.104.18.24) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 04 Oct 2008 23:03:55 +0000 Received: from d24relay01.br.ibm.com (unknown [9.8.31.16]) by igw1.br.ibm.com (Postfix) with ESMTP id 5D39D32C0B0 for ; Sat, 4 Oct 2008 19:32:08 -0300 (BRT) 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 m94N3iJr2670724 for ; Sat, 4 Oct 2008 20:03:44 -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 m94N3q8W027792 for ; Sat, 4 Oct 2008 20:03:52 -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 m94N3pI2027787; Sat, 4 Oct 2008 20:03:52 -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: Joel Brobecker Cc: gdb-patches@sourceware.org In-Reply-To: <20081003060629.GQ3665@adacore.com> References: <1222798409.30389.23.camel@miki> <20081002211256.GO3665@adacore.com> <1223001252.9858.11.camel@miki> <20081003060629.GQ3665@adacore.com> Content-Type: text/plain; charset=iso-8859-1 Date: Sat, 04 Oct 2008 23:04:00 -0000 Message-Id: <1223161515.5956.25.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/msg00121.txt.bz2 Hello Joel, On Thu, 2008-10-02 at 23:06 -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, so I think I got your idea ;-). > Now, going back to your patch, I think it's important not to let > best be the enemy of good either. I think that the feature that > you are proposing is interesting and would like to make sure that > we don't lose your work. I am about to go away on a trip, so will > have little time to review the details of your patch, but looks like > Michael has started on that. I would love for you to investigate > my (ahem) Vision (double-ahem), and I'm ready to guide you as much > as I can. But I am equally happy to incorporate your approach > if another maintainer looks at your code and OKays it. I really appreciate your review, and will certainly investigate your vision about how things should work. Also, let me know when you have more time (probably when you get back from your trip) so we can talk more about this and work together to implement things better. Meanwhile, I'll try to understand and improve things by my own :-). Regards, -- Sérgio Durigan Júnior Linux on Power Toolchain - Software Engineer Linux Technology Center - LTC IBM Brazil