Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* "struct target_ops" -> "struct gdbtarg" || "struct target"
@ 2003-10-09 13:39 Andrew Cagney
  2003-10-09 13:51 ` Andrew Cagney
  0 siblings, 1 reply; 4+ messages in thread
From: Andrew Cagney @ 2003-10-09 13:39 UTC (permalink / raw)
  To: gdb

Hello,

The current "target_ops" structure appeared with GDB 4.  The original 
implementation containing only methods.  Since then the target_ops have 
evolved to include data vis:

     struct section_table
      *to_sections;
     struct section_table
      *to_sections_end;

I think, the vector should be re-named to "struct target" or "struct 
gdbtarg" (consistent with gdbarch, and more name space proof) so that it 
correctly reflects its current implementation.

I'd like to do this now, before the target methods start being 
explicitly parameterized with their target vector.

thoughts?
Andrew


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: "struct target_ops" -> "struct gdbtarg" || "struct target"
  2003-10-09 13:39 "struct target_ops" -> "struct gdbtarg" || "struct target" Andrew Cagney
@ 2003-10-09 13:51 ` Andrew Cagney
  2003-10-09 19:42   ` Jim Blandy
  0 siblings, 1 reply; 4+ messages in thread
From: Andrew Cagney @ 2003-10-09 13:51 UTC (permalink / raw)
  To: Andrew Cagney; +Cc: gdb

> Hello,
> 
> The current "target_ops" structure appeared with GDB 4.  The original implementation containing only methods.  Since then the target_ops have evolved to include data vis:
> 
>     struct section_table
>      *to_sections;
>     struct section_table
>      *to_sections_end;
> 
> I think, the vector should be re-named to "struct target" or "struct gdbtarg" (consistent with gdbarch, and more name space proof) so that it correctly reflects its current implementation.
> 
> I'd like to do this now, before the target methods start being explicitly parameterized with their target vector.

I should note that an alternative is to have "struct gdbarch" as the 
object and "struct target_ops" as the methods vis:

	struct target
	{
	  .. data elements ...;
	  const struct target_ops *ops;
	};

Andrew



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: "struct target_ops" -> "struct gdbtarg" || "struct target"
  2003-10-09 13:51 ` Andrew Cagney
@ 2003-10-09 19:42   ` Jim Blandy
  2003-10-09 20:52     ` Andrew Cagney
  0 siblings, 1 reply; 4+ messages in thread
From: Jim Blandy @ 2003-10-09 19:42 UTC (permalink / raw)
  To: Andrew Cagney; +Cc: gdb

Andrew Cagney <ac131313@redhat.com> writes:

> > Hello,
> > The current "target_ops" structure appeared with GDB 4.  The
> > original implementation containing only methods.  Since then the
> > target_ops have evolved to include data vis:
> >     struct section_table
> >      *to_sections;
> >     struct section_table
> >      *to_sections_end;
> > I think, the vector should be re-named to "struct target" or "struct
> > gdbtarg" (consistent with gdbarch, and more name space proof) so
> > that it correctly reflects its current implementation.
> > I'd like to do this now, before the target methods start being
> > explicitly parameterized with their target vector.
> 
> I should note that an alternative is to have "struct gdbarch" as the
> object and "struct target_ops" as the methods vis:
> 
> 	struct target
> 	{
> 	  .. data elements ...;
> 	  const struct target_ops *ops;
> 	};

You mean 'struct target' not 'struct gdbarch', right?  The second
alternative seems better to me, since it separates the static stuff
from the dynamic stuff.  (Except, of course, that the 'static' stuff
isn't actually static, because of update_current_target...)


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: "struct target_ops" -> "struct gdbtarg" || "struct target"
  2003-10-09 19:42   ` Jim Blandy
@ 2003-10-09 20:52     ` Andrew Cagney
  0 siblings, 0 replies; 4+ messages in thread
From: Andrew Cagney @ 2003-10-09 20:52 UTC (permalink / raw)
  To: Jim Blandy; +Cc: gdb

> Andrew Cagney <ac131313@redhat.com> writes:
> 
> 
>> > Hello,
>> > The current "target_ops" structure appeared with GDB 4.  The
>> > original implementation containing only methods.  Since then the
>> > target_ops have evolved to include data vis:
>> >     struct section_table
>> >      *to_sections;
>> >     struct section_table
>> >      *to_sections_end;
>> > I think, the vector should be re-named to "struct target" or "struct
>> > gdbtarg" (consistent with gdbarch, and more name space proof) so
>> > that it correctly reflects its current implementation.
>> > I'd like to do this now, before the target methods start being
>> > explicitly parameterized with their target vector.
> 
>> 
>> I should note that an alternative is to have "struct gdbarch" as the
>> object and "struct target_ops" as the methods vis:
>> 
>> 	struct target
>> 	{
>> 	  .. data elements ...;
>> 	  const struct target_ops *ops;
>> 	};
> 
> 
> You mean 'struct target' not 'struct gdbarch', right?

Obviously.

 > The second
> alternative seems better to me, since it separates the static stuff
> from the dynamic stuff.  (Except, of course, that the 'static' stuff
> isn't actually static, because of update_current_target...)

While it seems better, it's significantly harder.  It will involve a 
period of rope jumping (which will likely trip up everyone) during which 
code wanting to modify things like "target_ops.to_section_end" will 
co-exist with code wanting to modify "target.to_section_end".  There are 
likely ways to ease the pain, but lets not ignore that there will be pain.

Given this, I think the most straight forward step is a straight:

	"struct target_ops" -> "struct gdbtarg"

transformation.  Moving the "ops" to a separate "static" vector being a 
second pass.

Andrew



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2003-10-09 20:52 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-10-09 13:39 "struct target_ops" -> "struct gdbtarg" || "struct target" Andrew Cagney
2003-10-09 13:51 ` Andrew Cagney
2003-10-09 19:42   ` Jim Blandy
2003-10-09 20:52     ` Andrew Cagney

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox