From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4636 invoked by alias); 8 Nov 2013 16:32:28 -0000 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 Received: (qmail 4626 invoked by uid 89); 8 Nov 2013 16:32:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE,SPF_HELO_PASS autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 08 Nov 2013 16:31:06 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rA8GUxbC013026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 8 Nov 2013 11:30:59 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id rA8GUwpF013364; Fri, 8 Nov 2013 11:30:58 -0500 Message-ID: <527D11C1.4030202@redhat.com> Date: Fri, 08 Nov 2013 16:34:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Tom Tromey CC: gdb-patches@sourceware.org Subject: Re: [PATCH v4 3/9] add target method delegation References: <1382464769-2465-1-git-send-email-tromey@redhat.com> <1382464769-2465-4-git-send-email-tromey@redhat.com> <526E8B54.8040104@redhat.com> <87eh75cmig.fsf@fleche.redhat.com> In-Reply-To: <87eh75cmig.fsf@fleche.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-11/txt/msg00242.txt.bz2 On 10/28/2013 05:51 PM, Tom Tromey wrote: >>>>>> "Pedro" == Pedro Alves writes: > > Pedro> Could you please split out the patch for the second problem? I > Pedro> think it'll be a small one. > > Sure. > > Pedro> What's the plan for the existing target methods that > Pedro> currently already do a similar beneath lookup? I'd like it that > Pedro> there's be at least a plan, so we don't end up with yet another > Pedro> way of doing things, two incomplete transitions, and no clear direction. > > Do you mean things like target_detach? Yes. > > If so, then I think these are two different things. > > target.h declares things both for users of the target API and for the > implementation of targets. > > Something like target_detach is a public API. My understanding of the > current scheme is that a public-facing method can either be implemented > by a function like target_detach, which encodes all the needed logic; or > by a macro that just calls into the target_ops, in which case the method > must use the inherit/default machinery. Right. I'm thinking the public functions that do the run time target beneath walk, instead of the inherit/default mechanism, and about having them defer to the delegation version, avoiding the need to implement basically the same twice. Like, to take a simple example: int target_has_all_memory_1 (void) { struct target_ops *t; for (t = current_target.beneath; t != NULL; t = t->beneath) if (t->to_has_all_memory (t)) return 1; return 0; } becomes: #define target_has_all_memory_1 \ target_delegate_has_all_memory (¤t_target) target_detach becomes (completely untested): void target_detach (char *args, int from_tty) { struct target_ops* t; if (gdbarch_has_global_breakpoints (target_gdbarch ())) /* Don't remove global breakpoints here. They're removed on disconnection from the target. */ ; else /* If we're in breakpoints-always-inserted mode, have to remove them before detaching. */ remove_breakpoints_pid (ptid_get_pid (inferior_ptid)); prepare_for_detach (); target_delegate_detach (¤t_target, args, from_tty); if (targetdebug) fprintf_unfiltered (gdb_stdlog, "target_detach (%s, %d)\n", args, from_tty); } etc. So basically, whether that was in the plan. Is there something about the delegate mechanism that would make this not work? If so, could we make it work? Having this considered was the sort of plan thing I had in mind. -- Pedro Alves