How to distinguish inheritance from containment?

How to distinguish inheritance from containment?

[Paul Pluzhnikov]

Greetings,

Consider this source:

--- cut ---
struct foo {
  int x;
};

struct is_a_foo : public foo {
  int y;
};

struct has_a_foo {
  foo f;
  int z;
};

int main()
{
  is_a_foo a;
  has_a_foo b;

  return a.x + b.f.x;
}
--- cut ---

Suppose I want to define a pretty printer for anything that "is a foo",
but which should not apply to things which "contain a foo" as the first
field.

The only way I figured out how to do this currently feels very "hacky":
(assume gdb.Value('a') is bound to python variable a).

  field0 = a.type.fields()[0]
  if "foo" == field0.name and "foo" == str(field0.type):
    print "is a foo"

In addition, above test is not fool-proof: if I rename 'f' member of
has_a_foo to 'foo':

  struct has_a_foo {
    struct foo foo;
    int z;
  };

then above test answers 'is a foo' for 'b' as well.

Would adding an 'inherited' pre-defined attribute to gdb.Field be a bad idea?
It would make 'is a foo' determination straightforward:

  if "foo" == str(field0.type) and field0.inherited:
    print "is a foo"


I'll send a patch if y'all think this is reasonable.

Thanks,
--
Paul Pluzhnikov

Re: How to distinguish inheritance from containment?

[Richard Ward]

Paul Pluzhnikov wrote:
> Greetings,
> 
> Consider this source:
> 
> --- cut ---
> struct foo {
>   int x;
> };
> 
> struct is_a_foo : public foo {
>   int y;
> };
> 
> struct has_a_foo {
>   foo f;
>   int z;
> };
> 
> int main()
> {
>   is_a_foo a;
>   has_a_foo b;
> 
>   return a.x + b.f.x;
> }
> --- cut ---
> 
> Suppose I want to define a pretty printer for anything that "is a foo",
> but which should not apply to things which "contain a foo" as the first
> field.
> 
> The only way I figured out how to do this currently feels very "hacky":
> (assume gdb.Value('a') is bound to python variable a).
> 
>   field0 = a.type.fields()[0]
>   if "foo" == field0.name and "foo" == str(field0.type):
>     print "is a foo"
> 
> In addition, above test is not fool-proof: if I rename 'f' member of
> has_a_foo to 'foo':
> 
>   struct has_a_foo {
>     struct foo foo;
>     int z;
>   };
> 
> then above test answers 'is a foo' for 'b' as well.
> 
> Would adding an 'inherited' pre-defined attribute to gdb.Field be a bad idea?
> It would make 'is a foo' determination straightforward:
> 
>   if "foo" == str(field0.type) and field0.inherited:
>     print "is a foo"
> 
> 
> I'll send a patch if y'all think this is reasonable.
> 
> Thanks,
> --
> Paul Pluzhnikov

I sent a patch to archer that did just that about two weeks ago, if you 
want it (not that it take that long to write one yourself). It had "Info 
about base class in gdb.Type" in the subject line.

Re: How to distinguish inheritance from containment?

[Paul Pluzhnikov]

On Wed, Jul 1, 2009 at 1:51 PM, Richard
Ward<richard.j.ward1@googlemail.com> wrote:

> I sent a patch to archer that did just that about two weeks ago, if you want
> it (not that it take that long to write one yourself). It had "Info about
> base class in gdb.Type" in the subject line.

Ah, missed it the first time. The patch looks good to me, except I think
"inherited" is clearer than "base_class". If you don't like "inherited",
perhaps "is_base_class" ?

Also, you'll need a proper ChangeLog entry for both gdb/ChangeLog and
gdb/doc/ChangeLog. Something like:


ChangeLog:

2009-05-28  Richard Ward  <richard.j.ward1@googlemail.com>

	* python/python-type.c (convert_field): New attribute "base_class".


doc/ChangeLog:

2009-05-28  Richard Ward  <richard.j.ward1@googlemail.com>

	* gdb.texinfo (Types In Python): Describe "base_class".


Tom, any chance this could go in?


Thanks,
-- 
Paul Pluzhnikov

Re: How to distinguish inheritance from containment?

[Richard Ward]

[-- Attachment #1: Type: text/plain, Size: 1370 bytes --]

Paul Pluzhnikov wrote:
> On Wed, Jul 1, 2009 at 1:51 PM, Richard
> Ward<richard.j.ward1@googlemail.com> wrote:
> 
>> I sent a patch to archer that did just that about two weeks ago, if you want
>> it (not that it take that long to write one yourself). It had "Info about
>> base class in gdb.Type" in the subject line.
> 
> Ah, missed it the first time. The patch looks good to me, except I think
> "inherited" is clearer than "base_class". If you don't like "inherited",
> perhaps "is_base_class" ?
> 
> Also, you'll need a proper ChangeLog entry for both gdb/ChangeLog and
> gdb/doc/ChangeLog. Something like:
> 
> 
> ChangeLog:
> 
> 2009-05-28  Richard Ward  <richard.j.ward1@googlemail.com>
> 
> 	* python/python-type.c (convert_field): New attribute "base_class".
> 
> 
> doc/ChangeLog:
> 
> 2009-05-28  Richard Ward  <richard.j.ward1@googlemail.com>
> 
> 	* gdb.texinfo (Types In Python): Describe "base_class".
> 
> 
> Tom, any chance this could go in?
> 
> 
> Thanks,

Thanks for the tips.
I've changed it to is_base_class.
Is the attached better?

2009-05-28  Richard Ward  <richard.j.ward1@googlemail.com>
     add is_base_class to gdb.Type.Fields
         * gdb/python/python-type.c
	convert_field adds a new bool entry "is_base_class"
	indicating whether the field represents a base class
	* gdb/doc/gdb.texinfo
	updated to refelect the above.

Richard Ward

[-- Attachment #2: pythonbaseclass.patch --]
[-- Type: text/x-patch, Size: 2765 bytes --]

From 4a517176209e441c4335c79d76deb134e584f1ff Mon Sep 17 00:00:00 2001
From: Richard Ward <richard@elemental-lin.(none)>
Date: Wed, 1 Jul 2009 23:17:44 +0100
Subject: [PATCH] add is_base_class to gdb.Type.fields

	* gdb/python/python-type.c
	convert_field adds a new bool entry "is_base_class"
	indicating whether the field represents a base class
	* gdb/doc/gdb.texinfo
	updated to refelect the above.
---
 gdb/ChangeLog            |    4 ++++
 gdb/doc/ChangeLog        |    4 ++++
 gdb/doc/gdb.texinfo      |    6 ++++++
 gdb/python/python-type.c |    5 +++++
 4 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 517b4f2..f86f42a 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,7 @@
+2009-05-28  Richard Ward  <richard.j.ward1@googlemail.com>
+
+	* python/python-type.c (convert_field): New attribute "is_base_class".
+
 2009-02-08  Jim Blandy  <jimb@red-bean.com>
 
 	* python/python-value.c (convert_value_from_python):
diff --git a/gdb/doc/ChangeLog b/gdb/doc/ChangeLog
index b42d473..b5da06e 100644
--- a/gdb/doc/ChangeLog
+++ b/gdb/doc/ChangeLog
@@ -1,3 +1,7 @@
+2009-05-28  Richard Ward  <richard.j.ward1@googlemail.com>
+
+	* gdb.texinfo (Types In Python): Describe "is_base_class".
+
 2009-02-06  Thiago Jung Bauermann  <bauerman@br.ibm.com>
 
 	* gdb.texinfo (Commands In Python):  Update names of COMMAND_
diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index 958a74f..2c09641 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -18516,6 +18516,12 @@ This is @code{True} if the field is artificial, usually meaning that
 it was provided by the compiler and not the user.  This attribute is
 always provided, and is @code{False} if the field is not artificial.
 
+@item is_base_class
+This is @code{True} if the field represents a base class of a C@t{++}
+structure.  This attribute is always provided, and is @code{False}
+if the field is not a base class of the type on which @code{fields} was
+called, or if that type was not a C@t{++} class.
+
 @item bitsize
 If the field is packed, or is a bitfield, then this will have a
 non-zero value, which is the size of the field in bits.  Otherwise,
diff --git a/gdb/python/python-type.c b/gdb/python/python-type.c
index 53a7eab..fa980aa 100644
--- a/gdb/python/python-type.c
+++ b/gdb/python/python-type.c
@@ -168,6 +168,11 @@ convert_field (struct type *type, int field)
   if (PyObject_SetAttrString (result, "artificial", arg) < 0)
     goto failarg;
 
+  arg = field < TYPE_N_BASECLASSES (type) ? Py_True : Py_False;
+  Py_INCREF (arg);
+  if (PyObject_SetAttrString (result, "is_base_class", arg) < 0)
+    goto failarg;
+
   arg = PyLong_FromLong (TYPE_FIELD_BITSIZE (type, field));
   if (!arg)
     goto fail;
-- 
1.6.0.4

Re: How to distinguish inheritance from containment?

[Tom Tromey]

>>>>> "Richard" == Richard Ward <richard.j.ward1@googlemail.com> writes:

Richard> Thanks for the tips.
Richard> I've changed it to is_base_class.
Richard> Is the attached better?

Looks good to me, I'll push it shortly.

Looking at this, it seems to me that value[field] ought to work, where
value is a Value object and field is a Field object from the value's
type.  It seems strange that this doesn't work.

Tom

Re: How to distinguish inheritance from containment?

[Tom Tromey]

>>>>> "Richard" == Richard Ward <richard.j.ward1@googlemail.com> writes:

Richard> I sent a patch to archer that did just that about two weeks ago, if
Richard> you want it (not that it take that long to write one yourself). It had
Richard> "Info about base class in gdb.Type" in the subject line.

Oops, I did not mean to ignore this patch.
Just as a general note -- ping patches after a week or two.

I'm sorry if I asked this already, but what is your gdb copyright
assignment situation?

Tom

Re: How to distinguish inheritance from containment?

[Paul Pluzhnikov]

On Thu, Jul 2, 2009 at 10:20 AM, Tom Tromey<tromey@redhat.com> wrote:

> I'm sorry if I asked this already, but what is your gdb copyright
> assignment situation?

http://sourceware.org/ml/archer/2009-q2/msg00176.html

Richard> PS. asked about this (and other patches I'll hopefully be sending) on
Richard> IRC and was told to sign the copyright waiver thing for the FSF before
Richard> submitting. Not sure if I need to give any info on that but the FSF say
Richard> they have it now.


-- 
Paul Pluzhnikov

Re: How to distinguish inheritance from containment?

[Richard Ward]

Tom Tromey wrote:
>>>>>> "Richard" == Richard Ward <richard.j.ward1@googlemail.com> writes:
> 
> Richard> I sent a patch to archer that did just that about two weeks ago, if
> Richard> you want it (not that it take that long to write one yourself). It had
> Richard> "Info about base class in gdb.Type" in the subject line.
> 
> Oops, I did not mean to ignore this patch.
> Just as a general note -- ping patches after a week or two.
> 
> I'm sorry if I asked this already, but what is your gdb copyright
> assignment situation?
> 
> Tom

Ok, will ping patches in future if necessary.

Its completed and gone through, I received a mail with a pdf of the 
document (and was given some lovely GNU/FSF stickers :)). If you need 
any details about it just ask.

Thanks.