[0/4] baby step toward multi-target

Message ID m3wqaf8tcr.fsf@sspiff.org
State New, archived

Commit Message

Doug Evans Aug. 11, 2014, 5:53 a.m. UTC
  Doug Evans <dje@google.com> writes:
> On Tue, Jul 29, 2014 at 10:45 AM, Tom Tromey <tromey@redhat.com> wrote:
>> The more invasive branch took a different approach to target identity.
>> Rather than the to_identity field, it split target_ops into a const
>> vtable part and a payload part.  Then it aimed to require all targets to
>> instantiate a new object.
> Hi.  I'd like to understand this more.
> By way of analogy, are you talking about something akin to RTTI, or
> something else?
> [How would the problem of target identity be solved if one went with
> the "all targets instantiate a new object" approach?]
>> This obviously has to touch a lot of code.  And, it runs into some
>> difficulties where the target code must work with uninstantiated
>> targets.
> By way of analogy, is all such code akin to static methods?
>> I don't think this is as much of an issue on the new branch.
>> At least from what I recall the uninstantiated business isn't a big
>> issue because this only affects a subset of methods, which can simply
>> avoid looking at the payload.
> Avoid looking at the payload how?
> Do you mean said "methods" would get passed an argument they are
> explicitly not supposed to touch?

Regarding avoiding looking at the payload ...

I noticed this in 4/4.  I think(!) it's unrelated, though I'm still
unclear on what you're referring to.  At any rate, the following is odd.

Several "methods" take a "self" or "ops" pointer but then don't use it
and instead go search the target stack for what I'd expect to be the
same thing.


The intuitive thing to do here is assert t is a core ops,
and then use it.  Instead the code calls get_core_target_ops.

I realize you mentioned in another email that you probably wouldn't
be inclined to check this in.  But if corelow is to be the example
on which other targets are based I'd like to understand all the
oddities I find.  [Maybe the above is just oversight, in which case
no worries.  But gdb's target support isn't always intuitive, and
I don't always trust my intuition with it.]


diff --git a/gdb/corelow.c b/gdb/corelow.c
index 1775a66..212665d 100644
--- a/gdb/corelow.c
+++ b/gdb/corelow.c
@@ -611,7 +639,9 @@  get_core_registers (struct target_ops *ops,
 static void
 core_files_info (struct target_ops *t)
-  print_section_info (core_data, core_bfd);
+  struct core_target_ops_with_data *cops = get_core_target_ops ();
+  print_section_info (&cops->core_data, core_bfd);
 struct spuid_list