Re: Problems with breakpoints in constructors

["Amit S. Kale" <amitkale at linsyssoft dot com>]

On Tuesday 03 Aug 2004 8:01 pm, Daniel Jacobowitz wrote:
> On Tue, Aug 03, 2004 at 07:58:30PM +0530, Amit S. Kale wrote:
> > On Tuesday 06 Jul 2004 12:03 pm, Jason Merrill wrote:
> > > On Tue, 6 Jul 2004 11:24:37 +0530, "Amit S. Kale"
> > > <amitkale@linsyssoft.com>
> >
> > wrote:
> > > > Mangled names are emitted in debugging information generated in the
> > > > function add_name_and_src_coords_attributes. They are emitted as
> > > > attribute DW_AT_MIPS_linkage_name. This attribute is emitted for all
> > > > member functions except for constructors. It's not emitted when
> > > > DECL_ABSTRACT is true, which applies to constructors.
> > >
> > > ...which applies to the abstract instance of constructors.  This should
> > > in turn be referenced by two concrete instances, which should have
> > > DW_AT_MIPS_linkage_name.
> > >
> > > > This hack generates DW_AT_MIPS_linkage_name for only one attribute.
> > > > add_name_and_src_coords_attributes is not called for second instance
> > > > of the constructor since both these constructors are instance of an
> > > > abstract declaration, for which add_name_and_src_coords_attributes
> > > > has been called at the time of first instance.
> > >
> > > That's a bug; since we (correctly) aren't attaching the linkage name to
> > > the abstract instance, we need to attach it to the concrete instances.
> >
> > I found that the generation of a die for default constructors (any
> > members that have an abstract origin) is suppressed in gen_member_die. I
> > did the change given below and could get DW_TAG_subprogram for both
> > default constructors. The die included DW_AT_MIPS_linkage_name attrib
> > also.
>
> Shouldn't the DW_AT_MIPS_linkage_name appear with the DIE for the
> concrete instance - which is already emitted with the code for the
> concrete instance?  They shouldn't be inside the class.

I believe I got DW_AT_MIPS_linkage_name in concrete instance by doing this.

I defined class as follows
class MyClass  { public:
	MyClass(void);
	void afun(void); };
MyClass::MyClass(void) { }
void MyClass::afun(void) { }

This is followed by empty definitions for the two member functions.

I got the mips linkage names in concrete definitions in .debug_info section as 
shown by dwarfdump utility:

<2><  181>	DW_TAG_subprogram
		DW_AT_sibling               <205>
		DW_AT_external              yes(1)
		DW_AT_name                  MyClass
		DW_AT_decl_file             1 /home/amitkale/tmp/prog.C
		DW_AT_decl_line             4
		DW_AT_MIPS_linkage_name     _ZN7MyClassC2Ev
		DW_AT_declaration           yes(1)
<3><  198>	DW_TAG_formal_parameter
		DW_AT_type                  <256>
		DW_AT_artificial            yes(1)

This appears similar to the definition for afun
<2><  229>	DW_TAG_subprogram
		DW_AT_external              yes(1)
		DW_AT_name                  afun
		DW_AT_decl_file             1 /home/amitkale/tmp/prog.C
		DW_AT_decl_line             5
		DW_AT_MIPS_linkage_name     _ZN7MyClass4afunEv
		DW_AT_declaration           yes(1)
<3><  242>	DW_TAG_formal_parameter
		DW_AT_type                  <256>
		DW_AT_artificial            yes(1)

Isn't this a concrete definition?

Looking at the dump output further reveals that my change didn't cause a 
DW_AT_MIPS_linkage to appear in .debug_abbrev  section. I see 6 instances of 
DW_AT_MIPS_linkage attributes in .debug_info section, whereas there are only 
4 instances in .debug_abbrev section.

Does .debug_abbrev contain abstract definitions?

-Amit