From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31523 invoked by alias); 16 Mar 2009 16:42:37 -0000 Received: (qmail 31510 invoked by uid 22791); 16 Mar 2009 16:42:35 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 16 Mar 2009 16:42:30 +0000 Received: (qmail 10149 invoked from network); 16 Mar 2009 16:42:28 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 16 Mar 2009 16:42:28 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [RFC] How to get target_ops from to_kill method? Date: Mon, 16 Mar 2009 17:02:00 -0000 User-Agent: KMail/1.9.10 Cc: Joel Brobecker , Tristan Gingold References: <20090316162247.GE9576@adacore.com> In-Reply-To: <20090316162247.GE9576@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903161642.27406.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: 2009-03/txt/msg00266.txt.bz2 On Monday 16 March 2009 16:22:47, Joel Brobecker wrote: > As I was hinting in one of my earlier emails, there is a nasty error > in darwin-nat.c, in the fact that we set the darwin_ops->to_kill method > to a procedure that has the wrong profile: darwin_kill_inferior takes > a target_ops * as its parameter, whereas the to_kill method is supposed > to take none! Thank you very much for handling these breakages. > As it turns out, all the routines being used by darwin_kill_inferior > don't use the target_ops. So what my second patch did was extract out > each of these routines inside another identical function, but without > the target_ops parameter. What this does, basically, is defined the > target_ops methods as wrappers to the real routines. This is what my > second patch does. I much prefer this version over the other. It's incremental, and doesn't add any hack or reference to the current_target global. > > However, I'm really wondering whether it would make sense to have > *all* the methods take the target_ops as the first parameter. We've > been slowly adding this parameter as we need them, but really, why > not be consistent across the board? Mostly, because it's a bunch of work that affects most native targets. I tried hard to avoid missing any conversion in the last set of changes, but, it ended up I broke a lot of stuff... But, yeah, there's a lot of inconsistency here. -- Pedro Alves