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

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

[woodzltc]

> You can find the patch, against current CVS GDB, at:
>   http://return.false.org/~drow/gdb/combined-rvct-patches.diff

Got it, a really huge one. :-)

> You should give these a try with xlc++ and see if they help.  If not,
> we'll need to discuss the differences in xlc output.
> 

I just had a try. And it did help. No SEGV error any more. Followed is the
summary report against xlc++(I only run the testcases under gdb.cp directory):

# of expected passes            1514
# of unexpected failures        264
# of unexpected successes       1
# of known failures             29
# of unresolved testcases       2

I had some look at these failure report. Quite a lot of them are contributed by
"__vfp", which is the same as "_vptr.CLASSNAME". GDB treat it as a normal class
member. The debuginfo for "__vfp" is like this:

 <2><36a>: Abbrev Number: 17 (DW_TAG_member)
     DW_AT_name        : __vfp  
     DW_AT_accessibility: 1     (public)
     DW_AT_artificial  : 1      
     DW_AT_data_member_location: 2 byte block: 23 0     (DW_OP_plus_uconst: 0)
     DW_AT_type        : <348> 

 <1><348>: Abbrev Number: 10 (DW_TAG_pointer_type)
     DW_AT_address_class: 0     
     DW_AT_type        : <30c>  

 <1><30c>: Abbrev Number: 16 (DW_TAG_union_type)
     DW_AT_sibling     : <348>
     DW_AT_name        : __vftTypeGCCV3
     DW_AT_byte_size   : 4
     DW_AT_artificial  : 1
 <2><322>: Abbrev Number: 17 (DW_TAG_member)
     DW_AT_name        : __faddr
     DW_AT_accessibility: 1     (public)
     DW_AT_artificial  : 1
     DW_AT_data_member_location: 2 byte block: 23 0     (DW_OP_plus_uconst: 0)
     DW_AT_type        : <2ff>
 <2><334>: Abbrev Number: 17 (DW_TAG_member)
     DW_AT_name        : __offset
     DW_AT_accessibility: 1     (public)
     DW_AT_artificial  : 1
     DW_AT_data_member_location: 2 byte block: 23 0     (DW_OP_plus_uconst: 0)
     DW_AT_type        : <305>  

with which GDB will interpret as: 
  __vftTypeGCCV3 *__vfp;

Would you like to have a look at gdb.log. I could post that if you prefer. 

Thanks

- Wu Zhou

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

[Wu Zhou]

Hi Daniel,

Thanks a lot for your kind consideration.  A week passed.  Did you have any
plan to look into these questions in a near future?  

P.S: I am not trying to be annoying,  just curious to know whether you have 
any plan on this. Thanks.  

- Wu Zhou

Quoting Daniel Jacobowitz <drow@false.org>:

> On Fri, Apr 29, 2005 at 03:27:49PM +0800, Wu Zhou wrote:
> > > 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!
> 
> I am afraid that I'm not going to have time to answer these questions
> for a while :-(  I'll get back to you about them, but I wanted to let
> you know that I did see them.  I'll have to dig my head back into this
> code to answer them.
> 
> 
> -- 
> Daniel Jacobowitz
> CodeSourcery, LLC
> 
> 


Cheers
- Wu Zhou

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

[Wu Zhou]

Hello Daniel and all,

I am recently running GDB testsuite against IBM's xlc compiler, and found
some problems with c++ testcases, especially while handling virtual-table
related stuff. After some analysis, I found there are some difference
between the debuginfo output between xlc++ and g++. The main difference I
noted now is that the class in xlc++ didn't depend on DW_TAG_containing_type
to find its virutal function table. Instead, every virtual class in xlc++
had its own "__vfp", which act the same role as "_vptr.CLASSNAME" in g++.
This will make gdb crash (SEGV) on quite a few c++ testcase.

I am now considering add some code in GDB to fix this. After doing some
search in this mail-list, I found there are some discussion on similar
problem before, such as http://sourceware.org/ml/gdb/2004-12/msg00077.html.
So I think maybe some of you might have experience or thought or idea on
this already. So I write this mail to ask for your expert advice:

1. To support a new c++ compiler, what work need to bo done? I am now
thinking of is a new source file(maybe xlc-abi.c) to register its own cp-abi
operation, and some tweak in dwarf2read.c to let GDB understand xlc specific
debuginfo. Any else places need my special attention? Please advice.
2. while coding this support, what design consideration I need to take into
account? Is there any document on this? GDB internal didn't mention this.
Maybe there are some in somebody's mind, would you like to share with me?
Thanks a lot. :-)
3. To verify that my code does work ok and don't bring any other
side-effect, what I need to take into account? Running the testsuite against
the modified code might be a help. Any specific area need some more
attention?

Above is only my initial thought. Any idea, advice or comments are highly
appreciated.

Cheers.

- Wu Zhou

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

[Daniel Jacobowitz]

On Tue, Apr 26, 2005 at 10:53:03AM +0800, Wu Zhou wrote:
> Hello Daniel and all,
> 
> I am recently running GDB testsuite against IBM's xlc compiler, and found
> some problems with c++ testcases, especially while handling virtual-table
> related stuff. After some analysis, I found there are some difference
> between the debuginfo output between xlc++ and g++. The main difference I
> noted now is that the class in xlc++ didn't depend on DW_TAG_containing_type
> to find its virutal function table. Instead, every virtual class in xlc++
> had its own "__vfp", which act the same role as "_vptr.CLASSNAME" in g++.
> This will make gdb crash (SEGV) on quite a few c++ testcase.

I have some patches for this, originally developed for the ARM RVCT
compiler.  I haven't had the time to clean them up and post them.
They will probably be helpful to you.

If I haven't posted them by the end of this week, please, remind me.

> I am now considering add some code in GDB to fix this. After doing some
> search in this mail-list, I found there are some discussion on similar
> problem before, such as http://sourceware.org/ml/gdb/2004-12/msg00077.html.
> So I think maybe some of you might have experience or thought or idea on
> this already. So I write this mail to ask for your expert advice:
> 
> 1. To support a new c++ compiler, what work need to bo done? I am now
> thinking of is a new source file(maybe xlc-abi.c) to register its own cp-abi
> operation, and some tweak in dwarf2read.c to let GDB understand xlc specific
> debuginfo. Any else places need my special attention? Please advice.

Do you need an xlc-abi.c?  What ABI does this compiler follow?  If it
doesn't follow the Itanium C++ ABI or one of the older GNU ABIs, then
considerably more work may be required.

Is its ABI documented?

> 2. while coding this support, what design consideration I need to take into
> account? Is there any document on this? GDB internal didn't mention this.
> Maybe there are some in somebody's mind, would you like to share with me?
> Thanks a lot. :-)

I'd be glad to answer more specific questions, but I've not got any
answers for this general one.

Do you have arangements for copyright assignment?  I don't know how
exactly that works in IBM, but I suspect it's complicated.

> 3. To verify that my code does work ok and don't bring any other
> side-effect, what I need to take into account? Running the testsuite against
> the modified code might be a help. Any specific area need some more
> attention?

Testing with already supported C++ compilers is very important.  It's
easy to fix one ABI and break another.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

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

[Wu Zhou]

> On Tue, Apr 26, 2005 at 10:53:03AM +0800, Wu Zhou wrote:
> > Hello Daniel and all,
> >
> > I am recently running GDB testsuite against IBM's xlc compiler, and
found
> > some problems with c++ testcases, especially while handling
virtual-table
> > related stuff. After some analysis, I found there are some difference
> > between the debuginfo output between xlc++ and g++. The main difference
I
> > noted now is that the class in xlc++ didn't depend on
DW_TAG_containing_type
> > to find its virutal function table. Instead, every virtual class in
xlc++
> > had its own "__vfp", which act the same role as "_vptr.CLASSNAME" in
g++.
> > This will make gdb crash (SEGV) on quite a few c++ testcase.
>
> I have some patches for this, originally developed for the ARM RVCT
> compiler.  I haven't had the time to clean them up and post them.
> They will probably be helpful to you.
>
> If I haven't posted them by the end of this week, please, remind me.

Thank you, Daniel! I am very glad to try your patch.

>
> > I am now considering add some code in GDB to fix this. After doing some
> > search in this mail-list, I found there are some discussion on similar
> > problem before, such as
http://sourceware.org/ml/gdb/2004-12/msg00077.html.
> > So I think maybe some of you might have experience or thought or idea on
> > this already. So I write this mail to ask for your expert advice:
> >
> > 1. To support a new c++ compiler, what work need to bo done? I am now
> > thinking of is a new source file(maybe xlc-abi.c) to register its own
cp-abi
> > operation, and some tweak in dwarf2read.c to let GDB understand xlc
specific
> > debuginfo. Any else places need my special attention? Please advice.
>
> Do you need an xlc-abi.c?  What ABI does this compiler follow?  If it
> doesn't follow the Itanium C++ ABI or one of the older GNU ABIs, then
> considerably more work may be required.

I am not very sure. They(the developer of xlc) said that they also follow
GNU V3 C++ ABI. But there are quite a few difference between the debuginfo
generated by g++ and xlc++. An new file named xlc-abi.c is what I could
thought of at this time. It could verify my idea, and at the same time not
impact the debugging of g++ code. If the changes is not big, maybe we could
integrate them back into gnu-v3-abi.c at last.

>
> Is its ABI documented?
>

I am not very sure. I need to ask the compiler developer.

> > 2. while coding this support, what design consideration I need to take
into
> > account? Is there any document on this? GDB internal didn't mention
this.
> > Maybe there are some in somebody's mind, would you like to share with
me?
> > Thanks a lot. :-)
>
> I'd be glad to answer more specific questions, but I've not got any
> answers for this general one.
>
> Do you have arangements for copyright assignment?  I don't know how
> exactly that works in IBM, but I suspect it's complicated.

My manager are arranging this for me. Do I need to assign any document
myself? If yes, I am very glad to do so.

>
> > 3. To verify that my code does work ok and don't bring any other
> > side-effect, what I need to take into account? Running the testsuite
against
> > the modified code might be a help. Any specific area need some more
> > attention?
>
> Testing with already supported C++ compilers is very important.  It's
> easy to fix one ABI and break another.

Thanks. I will keep this in mind.

>
> -- 
> Daniel Jacobowitz
> CodeSourcery, LLC

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

[Daniel Jacobowitz]

On Tue, Apr 26, 2005 at 05:51:34PM +0800, Wu Zhou wrote:
> I am not very sure. They(the developer of xlc) said that they also follow
> GNU V3 C++ ABI. But there are quite a few difference between the debuginfo
> generated by g++ and xlc++. An new file named xlc-abi.c is what I could
> thought of at this time. It could verify my idea, and at the same time not
> impact the debugging of g++ code. If the changes is not big, maybe we could
> integrate them back into gnu-v3-abi.c at last.

If the debugging information is different, you will need changes in the
dwarf2 reader.  However, you will probably not need a new ABI file; the
gnu-v3-abi code should suffice.

> My manager are arranging this for me. Do I need to assign any document
> myself? If yes, I am very glad to do so.

I don't know.  Let's see what happens.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

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

[Daniel Jacobowitz]

On Mon, Apr 25, 2005 at 11:18:23PM -0400, Daniel Jacobowitz wrote:
> On Tue, Apr 26, 2005 at 10:53:03AM +0800, Wu Zhou wrote:
> > Hello Daniel and all,
> > 
> > I am recently running GDB testsuite against IBM's xlc compiler, and found
> > some problems with c++ testcases, especially while handling virtual-table
> > related stuff. After some analysis, I found there are some difference
> > between the debuginfo output between xlc++ and g++. The main difference I
> > noted now is that the class in xlc++ didn't depend on DW_TAG_containing_type
> > to find its virutal function table. Instead, every virtual class in xlc++
> > had its own "__vfp", which act the same role as "_vptr.CLASSNAME" in g++.
> > This will make gdb crash (SEGV) on quite a few c++ testcase.
> 
> I have some patches for this, originally developed for the ARM RVCT
> compiler.  I haven't had the time to clean them up and post them.
> They will probably be helpful to you.
> 
> If I haven't posted them by the end of this week, please, remind me.

You can find the patch, against current CVS GDB, at:
  http://return.false.org/~drow/gdb/combined-rvct-patches.diff

On i386-linux, using g++, it breaks a couple of gcj tests (hmm, I
thought I'd fixed that) and fixes a couple of C++ KFAILs.  For RVCT the
results are more dramatic.  It is going to be a long time before these
patches are all merged; there are 41 of them, some will require
discussion, and all will require me finding some time.  I'll go do the
first one now.

You should give these a try with xlc++ and see if they help.  If not,
we'll need to discuss the differences in xlc output.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

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

[Wu Zhou]

> Could you please respond to the list in the future?  Thanks in advance!

Sorry, I forgeted to cc the mail-list. Ever since I will do that as you
request.

> >
> > Daniel, I noticed that you also include some patches to completion.exp,
> > volatile.exp and gdb1355.exp. That is also what I wan to include.
Besides
> > these "long" or "long int", "unsigned short" or "short unsigned"
problem, I
> > also encounter one problem with "signed" while running volatile.exp with
xlc
> > compiler. xlc compiler take "signed" as the default. so in the outputed
> > debuginfo of function qux2:
> >
> > qux2 (volatile unsigned char vuc, const volatile int cvi,
> >       volatile short /*&*/vsr, volatile long *vlp, float *volatile fpv,
> >       const volatile signed char *const volatile cvscpcv)
> >
> > cvscpcv will be interpreted as "const volatile char *const volatile". Do
you
> > think that it is ok to also add a bracket around "signed" to let this
pass?
> > Thanks.
>
> Er... that is not OK.  If necessary we can add an XFAIL for xlc,
> though.  This is a bug in xlc; "signed char" and "char, defaulting to
> signed behavior" are not the same types in C.
>

OK. Maybe I could try to convince XLC guys to fix this first.

> > BTW: do you means that you sill have another 40(41 - 1) patches for RVCT
and
> > that this patch is only the first one? If it is like that, I am really
> > curious about how many codes you will add into GDB. :-)
>
> No, this is all 41 rolled up into one big diff :-)

Then, which part will get your first attention? I suggest you start with
eliminating the dependence on DW_TAG_containing_type first. Then XLC guys
could go on improving their debuginfo output. What is your point on this?
Please comment. Thanks.

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.

Cheers
- Wu Zhou

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

[Wu Zhou]

> 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>

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

[Daniel Jacobowitz]

On Fri, Apr 29, 2005 at 03:27:49PM +0800, Wu Zhou wrote:
> > 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!

I am afraid that I'm not going to have time to answer these questions
for a while :-(  I'll get back to you about them, but I wanted to let
you know that I did see them.  I'll have to dig my head back into this
code to answer them.


-- 
Daniel Jacobowitz
CodeSourcery, LLC