This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problems with breakpoints in constructors


Thanks for this valuable information.

I have removed my previous change and have done the following change:
--- dwarf2out.c.orig    2004-08-06 11:26:01.000000000 +0530
+++ dwarf2out.c 2004-08-06 11:28:54.000000000 +0530
@@ -10810,6 +10810,11 @@ gen_subprogram_die (tree decl, dw_die_re

       subr_die = new_die (DW_TAG_subprogram, context_die, decl);
       add_abstract_origin_attribute (subr_die, origin);
+      if (DECL_ASSEMBLER_NAME (decl) != DECL_NAME (decl))
+       {
+         add_AT_string (subr_die, DW_AT_MIPS_linkage_name,
+                        IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl)));
+       }
     }
   else if (old_die)
     {

With this change I get the dump attached herewith. Could you please look at it 
and let me know if it appears all right?

gdb can't use the information generated by this code correctly. That's because 
the MIPS_linkage doesn't go in class type definition, which is used by gdb to 
search for members matching the breakpoint name. I am trying to see whether I 
can change it to reach MIPS_linkage. I'll post more information hopefully 
with some code on the gdb mailing list when I fully understand the problem.

-Amit

On Thursday 05 Aug 2004 9:07 pm, Daniel Jacobowitz wrote:
> On Thu, Aug 05, 2004 at 08:19:13PM +0530, Amit S. Kale wrote:
> > Here they. There are two files dump.txt with my changes and dump.orig.txt
> > without them.
> >
> > I read the abbreviations related stuff from dwarf document. Also looked
> > at the gcc code that  generates abbreviations. The gcc code looks
> > correct.
>
> Let's take a look at the debug info for your test case.  Beforehand, in
> the debug information for MyClass are two declarations - one for
> MyClass(void) and one for MyClass(MyClass&).  Then outside of the class
> is a DIE for MyClass(void), without PC bounds - this uses
> DW_AT_specification.  Then there are two which reference the previous
> DIE using DW_AT_abstract_origin and have PC bounds.  This all makes
> sense.  There is no DIE for the copy constructor, which makes sense
> because there is no declaration.
>
> Your change adds to the class's members two additional copies of the
> void constructor, with linkage names.  It also adds two copies of the
> copy constructor, with linkage names.  The debug information now claims
> that the class has six member constructors.  The four new members have
> no explicit reference to the previous two, from which they are derived.
> The concrete DIEs for the clones reference the same abstract DIE they
> did before your change, not the new DIEs you have added.  This is not
> an improvement.
>
> If anything, it might be useful to add the linkage name to the concrete
> dies for the clones.
>
> > Something is messed up in the dwarfdump utility output. I can't find
> > correct abbreviations tags in debug_info. The dump_info records for 2
> > instances of MyClass and 1 instance of afun contain
> > DW_AT_MIPS_linkage_name attribute. Both of them point to the same
> > abbreviation entry. Yet when I debugged gdb's read_partial_die function,
> > I found that the abbreviation entry for afun and MyClass is different.
> > The afun entry contains 7 attributes, including DW_AT_MIPS_linkage_name
> > and MyClass entry contains 6 attributes, without the MIPS entry.
> >
> > How do I verify whether what dwarfdump output shows is incorrect or
> > whether gdb's interpretation of the dwarf data is incorrect?
>
> I don't know anything about dwarfdump.  But the dumps you sent did not
> show this.  Dwarfdump doesn't even print the abbreviation number used
> by a particular DIE in its output.

Attachment: dump.txt
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]