Re: about how to add support to new c++ compiler in GDB

["Wu Zhou" <woodzltc at cn dot ibm dot com>]

> BTW. I had verify your patch, It did worked. No SEGV error any more.
> Althought there are still some error, most of them should be XLC specific
I
> believe. I could work with XLC guys to improve them.

Daniel, after playing with your patch for some more time, I had the
following questions. Would you please answer these? Thanks a lot!

1. Could you please add the following code to let GDB get the vtable pointer
from XLC-generated code?

--- dwarf2read.c        2005-04-29 07:49:59.070865984 -0700
+++ dwarf2read.c.zw     2005-04-29 07:53:05.715856648 -0700
@@ -4031,6 +4031,28 @@
                    }
                }
            }
+          else if (cu->producer
+                   && strncmp (cu->producer,
+                               "IBM(R) XL C/C++ Advanced Edition V7.0 for
Linux(R)", 50) == 0)
+            {
+              /* The IBM XLC compiler does not provide direct indication
+                 of the containing type, but the vtable pointer is
+                 always named __vfp.  */
+
+              int i;
+
+              for (i = TYPE_NFIELDS (type) - 1;
+                   i >= TYPE_N_BASECLASSES (type);
+                   --i)
+                {
+                  if (strcmp (TYPE_FIELD_NAME (type, i), "__vfp") == 0)
+                    {
+                      TYPE_VPTR_FIELDNO (type) = i;
+                      TYPE_VPTR_BASETYPE (type) = type;
+                      break;
+                    }
+                }
+            }
        }

       do_cleanups (back_to);

2. I am curious about how your code skip the vtable pointer while printing
out the definition of a virtual class. As I understand this, there should be
some code in function c_type_print_base to skip member named "__vptr", just
like how the following code skip "_vptr.CLASSNAME":

              if (strncmp (TYPE_FIELD_NAME (type, i), "_vptr", 5) == 0
                  && is_cplus_marker ((TYPE_FIELD_NAME (type, i))[5]))
                continue;

To make it more general, I am now thinking of adding the following code to
achieve this:

              if (i == TYPE_VPTR_FIELDNO(type)
                  && type == TYPE_VPTR_BASETYPE (type))
                continue;

Do you think that it make any sense?

3. After applying your patch and running gdb testsuite against IBM's xlc++
compiler, I found a strange behavior: GDB can't print out the virtual
modifier of any class's virtual function. To name an example, the class VB
in virtfunc.cc is defined as below:

class VB
{
public:
    int vb;
    int fvb();
    virtual int vvb();
};

"ptype VB" will output the following:

type = class VB {
  public:
    int vb;

    int fvb();
    int vvb();
}

The debuginfo for function vvb is attached below, wishing that it could help
identify the cause. Thanks.

 <2><2fb>: Abbrev Number: 12 (DW_TAG_subprogram)
     DW_AT_sibling     : <325>
     DW_AT_name        : vvb
     DW_AT_accessibility: 1     (public)
     DW_AT_declaration : 1
     DW_AT_type        : <235>
     DW_AT_virtuality  : 1      (virtual)
     DW_AT_vtable_elem_location: 5 byte block: 23 0 6 23 4
(DW_OP_plus_uconst: 0; DW_OP_deref; DW_OP_plus_uconst: 4)
     DW_AT_MIPS_linkage_name: _ZN2VB3vvbEv
 <3><31e>: Abbrev Number: 11 (DW_TAG_formal_parameter)
     DW_AT_artificial  : 1
     DW_AT_type        : <d71>