This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC v2 01/38] add "this" pointers to more target APIs
- From: Doug Evans <dje at google dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: gdb-patches <gdb-patches at sourceware dot org>
- Date: Wed, 12 Feb 2014 12:22:14 -0800
- Subject: Re: [RFC v2 01/38] add "this" pointers to more target APIs
- Authentication-results: sourceware.org; auth=none
- References: <1391720136-2121-1-git-send-email-tromey at redhat dot com> <1391720136-2121-2-git-send-email-tromey at redhat dot com> <CADPb22TN_4Osy_6Tbah9XuNRCP5MhzTcCEO_rc6PhE5JcD2Wjg at mail dot gmail dot com> <CADPb22ShQrOW1ocmj6EBcM5oEN1AfsNUPd_m1_=hx4v7-42CWQ at mail dot gmail dot com> <87ha84t88v dot fsf at fleche dot redhat dot com>
On Wed, Feb 12, 2014 at 11:56 AM, Tom Tromey <tromey@redhat.com> wrote:
> Doug> As an example (just in case there's some confusion),
> Doug> one thing I'm thinking about is global state used by targets.
> Doug> If, for example, we support multiple remote connections then we're
> Doug> going to have multiple open sockets/descriptors and IWBN if the
> Doug> target_ops methods fetched such things from "self" instead of global
> Doug> variables (*1).
>[...]
> My plan is outlined on the multi-target wiki page and on the patches on
> the corresponding branch. The wiki page is here:
>
> https://sourceware.org/gdb/wiki/MultiTarget
>
> Basically the question is whether it is better to turn target_ops into a
> real vtable and separate the vtable bits from the state bits. I think
> this is undeniably cleaner.
>
> One concrete benefit of the cleanliness aspect is that it exposes the
> API difficulties around to_open; namely that we need to properly
> instantiate target objects in spots like find_default_run_target. This
> is not properly handled on the branch.
>
> But, as I said, it is more typing to do this conversion, especially as
> I'll now have to redo it, which is somewhat demotivating. Not to
> mention that this would be another sub-series requiring unusual amounts
> of testing, as it touches code everywhere. And, it isn't strictly
> necessary, as to_data can be used. And, if I were to do it again, I'd
> probably do it a bit differently. So I'm not sure.
Ah, so this series is just an interim step, and a follow-up will
replace "struct target_ops *self" with "struct foo *self" with foo
containing "struct target_ops *".
Thanks for the clarification.