From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26344 invoked by alias); 16 Mar 2009 22:52:34 -0000 Received: (qmail 26333 invoked by uid 22791); 16 Mar 2009 22:52:34 -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 22:52:28 +0000 Received: (qmail 32491 invoked from network); 16 Mar 2009 22:52:27 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 16 Mar 2009 22:52:27 -0000 From: Pedro Alves To: Joel Brobecker Subject: Re: [RFC] How to get target_ops from to_kill method? Date: Tue, 17 Mar 2009 00:05:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb-patches@sourceware.org, Tristan Gingold References: <20090316162247.GE9576@adacore.com> <20090316173104.GH9294@adacore.com> <20090316221103.GC384@adacore.com> In-Reply-To: <20090316221103.GC384@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903162252.26346.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/msg00289.txt.bz2 On Monday 16 March 2009 22:11:03, Joel Brobecker wrote: > Do you think that the implementation for "target_kill" is good? > That was my first implementation until I realized that the to_kill > field is inherited. So perhaps I can simplify the implementation by > calling the to_kill field from the target layer that's at the top > of the current target stack? The implementation of the function itself is good. What happens is that we're switching from having the stack "hardcoded" at push time, to have it traversed on demand, so, this method doesn't need to be inherited and shouldn't be defaulted anymore. You can also delete debug_to_kill, it becomes unreacheable code, since you start the lookup at current_target.beneath, and you now handle the debug outputting in the new target_kill function. At some point, I'd like to implement some of the ideas at: http://sourceware.org/ml/gdb-patches/2009-02/msg00156.html The most important/annoying part is to convert the targets and the method interfaces, due to the need to touch "native" files. > Other than that, I think I got all implementations, and I recompiled > all the files that I could recompile on my x86_64-linux machine. > I also built GDB with --enable-targets=all, even if I don't think > it help test that much more since most impacted files are "native" > units. Yeah, that's the problem with these conversions. :-) > static void > -hpux_thread_kill_inferior (void) > +hpux_thread_kill_inferior (struct target_ops *ops) > { > - deprecated_child_ops.to_kill (); > + deprecated_child_ops.to_kill (ops); Doesn't matter much for a deprecated_child_ops target user, but, this should be: deprecated_child_ops.to_kill (&deprecated_child_ops); ... so the next target in the chain can again do find_target_beneath (ops)->to_kill (find_target_beneath (ops)), and so on. -- Pedro Alves