[clang][DebugInfo] DW_AT_name of inheriting constructor is the base class name

[Michael137]

Given:

struct Foo {
  Foo(int) {}
};

struct Bar : public Foo {
  using Foo::Foo;
};

int main() {
  Bar b(5);
}

Clang produces following DWARF:

0x0000002a:   DW_TAG_structure_type
                DW_AT_calling_convention        (DW_CC_pass_by_value)
                DW_AT_name      ("Bar")
                DW_AT_byte_size (0x01)
                DW_AT_decl_file ("inherit.cpp")
                DW_AT_decl_line (5)

0x00000033:     DW_TAG_inheritance
                  DW_AT_type    (0x0000004a "Foo")
                  DW_AT_data_member_location    (0x00)

0x00000039:     DW_TAG_subprogram
                  DW_AT_name    ("Foo")
                  DW_AT_declaration     (true)
                  DW_AT_artificial      (true)
                  DW_AT_external        (true)

0x0000003e:       DW_TAG_formal_parameter
                    DW_AT_type  (0x0000009a "Bar *")
                    DW_AT_artificial    (true)

0x00000043:       DW_TAG_formal_parameter
                    DW_AT_type  (0x0000006b "int")

Note how the constructor DW_AT_name is Foo (despite the implicit this parameter being Bar).

GCC produces:

0x00000061:   DW_TAG_structure_type                                                                       
                DW_AT_name      ("Bar")                                                                   
                DW_AT_byte_size (1)                 
                DW_AT_decl_file ("inherit.cpp")                                         
                DW_AT_decl_line (5)                 
                DW_AT_decl_column       (8)                                                               
                DW_AT_sibling   (0x0000008a)      
                                                     
0x0000006b:     DW_TAG_inheritance                                                                        
                  DW_AT_type    (0x0000002a "Foo")                                                        
                  DW_AT_data_member_location    (0x00)       

0x00000071:     DW_TAG_subprogram        
                  DW_AT_external        (true)    
                  DW_AT_name    ("Bar")              
                  DW_AT_linkage_name    ("_ZN3BarCI43FooEi")                                              
                  DW_AT_artificial      (true)       
                  DW_AT_declaration     (true)
                  DW_AT_object_pointer  (0x0000007e) 
                                                                                                          
0x0000007e:       DW_TAG_formal_parameter                                                                 
                    DW_AT_type  (0x000000ba "Bar *")
                    DW_AT_artificial    (true)       
                                                     
0x00000083:       DW_TAG_formal_parameter                                                                 
                    DW_AT_type  (0x0000005a "int")                                                        

I'm not certain which of these is technically the correct representation here. Though for LLDB, GCC's DWARF is easier to handle because to know whether we're dealing with a constructor DIE we can just check function name == enclosing class name (came up in https://discourse.llvm.org/t/rfc-lldb-handling-abi-tagged-constructors-destructors-in-expression-evaluator/82816).

[llvmbot]

@llvm/issue-subscribers-debuginfo

Author: Michael Buch (Michael137)

Given: ``` struct Foo { Foo(int) {} };

struct Bar : public Foo {
using Foo::Foo;
};

int main() {
Bar b(5);
}

Clang produces following output:

0x0000002a: DW_TAG_structure_type
DW_AT_calling_convention (DW_CC_pass_by_value)
DW_AT_name ("Bar")
DW_AT_byte_size (0x01)
DW_AT_decl_file ("inherit.cpp")
DW_AT_decl_line (5)

0x00000033: DW_TAG_inheritance
DW_AT_type (0x0000004a "Foo")
DW_AT_data_member_location (0x00)

0x00000039: DW_TAG_subprogram
DW_AT_name ("Foo")
DW_AT_declaration (true)
DW_AT_artificial (true)
DW_AT_external (true)

0x0000003e: DW_TAG_formal_parameter
DW_AT_type (0x0000009a "Bar *")
DW_AT_artificial (true)

Note how the constructor `DW_AT_name` is `Foo` (despite the implicit `this` parameter being `Bar`).

GCC produces:

0x00000071: DW_TAG_subprogram
DW_AT_external (true)
DW_AT_name ("Bar")
DW_AT_linkage_name ("_ZN3BarCI43FooEi")
DW_AT_artificial (true)
DW_AT_declaration (true)
DW_AT_object_pointer (0x0000007e)

0x0000007e: DW_TAG_formal_parameter
DW_AT_type (0x000000ba "Bar *")
DW_AT_artificial (true)

0x00000083: DW_TAG_formal_parameter
DW_AT_type (0x0000005a "int")

I'm not certain which of these is technically the correct representation here. Though for LLDB, GCC's DWARF is easier to handle because it knows it's dealing with a constructor (came up in https://discourse.llvm.org/t/rfc-lldb-handling-abi-tagged-constructors-destructors-in-expression-evaluator/82816).
</details>

[Michael137]

If we just go off of what the Clang AST calls these constructors, it makes sense why Clang's DWARF looks this way:

|-CXXRecordDecl 0x3dfcfc30 <line:5:1, line:7:1> line:5:8 referenced struct Bar definition
...
| |-CXXConstructorDecl 0x2a0df520 <line:5:8> col:8 implicit Bar 'void ()' inline default_delete noexcept-unevaluated 0x2a0df520
| |-CXXConstructorDecl 0x2a0fd680 <col:8> col:8 implicit constexpr Bar 'void (const Bar &)' inline default trivial noexcept-unevaluated 0x2a0fd680
| | `-ParmVarDecl 0x2a0fd7a0 <col:8> col:8 'const Bar &'
| |-CXXConstructorDecl 0x2a0fd970 <col:8> col:8 implicit constexpr Bar 'void (Bar &&)' inline default trivial noexcept-unevaluated 0x2a0fd970
| | `-ParmVarDecl 0x2a0fda90 <col:8> col:8 'Bar &&'
| `-CXXConstructorDecl 0x2a0fdfc8 <line:6:14> col:14 implicit used Foo 'void (int) noexcept(false)' inline
|   |-ParmVarDecl 0x2a0fe0e8 <col:14> col:14 implicit 'int'
|   |-CXXCtorInitializer 'Foo':'Foo'
|   | `-CXXInheritedCtorInitExpr 0x2a0fe1b8 <col:14> 'Foo':'Foo'
|   `-CompoundStmt 0x2a0fe210 <col:14>

[pogo59]

Note how the constructor DW_AT_name is Foo (despite the implicit this parameter being Bar).

I only see one parameter in Clang's DWARF, the implicit this. Is there also an int parameter? If not, then Clang's DWARF is wrong; the Foo ctor takes an int parameter, as correctly described by GCC.

[llvmbot]

@llvm/issue-subscribers-clang-codegen

Author: Michael Buch (Michael137)

Given: ``` struct Foo { Foo(int) {} };

struct Bar : public Foo {
using Foo::Foo;
};

int main() {
Bar b(5);
}

Clang produces following DWARF:

0x0000002a: DW_TAG_structure_type
DW_AT_calling_convention (DW_CC_pass_by_value)
DW_AT_name ("Bar")
DW_AT_byte_size (0x01)
DW_AT_decl_file ("inherit.cpp")
DW_AT_decl_line (5)

0x00000033: DW_TAG_inheritance
DW_AT_type (0x0000004a "Foo")
DW_AT_data_member_location (0x00)

0x00000039: DW_TAG_subprogram
DW_AT_name ("Foo")
DW_AT_declaration (true)
DW_AT_artificial (true)
DW_AT_external (true)

0x0000003e: DW_TAG_formal_parameter
DW_AT_type (0x0000009a "Bar *")
DW_AT_artificial (true)

Note how the constructor `DW_AT_name` is `Foo` (despite the implicit `this` parameter being `Bar`).

GCC produces:

0x00000061: DW_TAG_structure_type
DW_AT_name ("Bar")
DW_AT_byte_size (1)
DW_AT_decl_file ("inherit.cpp")
DW_AT_decl_line (5)
DW_AT_decl_column (8)
DW_AT_sibling (0x0000008a)

0x0000006b: DW_TAG_inheritance
DW_AT_type (0x0000002a "Foo")
DW_AT_data_member_location (0x00)

0x00000071: DW_TAG_subprogram
DW_AT_external (true)
DW_AT_name ("Bar")
DW_AT_linkage_name ("_ZN3BarCI43FooEi")
DW_AT_artificial (true)
DW_AT_declaration (true)
DW_AT_object_pointer (0x0000007e)

0x0000007e: DW_TAG_formal_parameter
DW_AT_type (0x000000ba "Bar *")
DW_AT_artificial (true)

0x00000083: DW_TAG_formal_parameter
DW_AT_type (0x0000005a "int")

I'm not certain which of these is technically the correct representation here. Though for LLDB, GCC's DWARF is easier to handle because to know whether we're dealing with a constructor DIE we can just check `function name == enclosing class name` (came up in https://discourse.llvm.org/t/rfc-lldb-handling-abi-tagged-constructors-destructors-in-expression-evaluator/82816).
</details>

[Michael137]

Note how the constructor DW_AT_name is Foo (despite the implicit this parameter being Bar).

I only see one parameter in Clang's DWARF, the implicit this. Is there also an int parameter? If not, then Clang's DWARF is wrong; the Foo ctor takes an int parameter, as correctly described by GCC.

Good point, that was a bit misleading. I adjusted the description. Both GCC and Clang attach the int parameter. It's just that DW_AT_name differs

[dwblaikie]

Yeah, we should do the same thing GCC does.

Interestingly - for a default ctor, we do do the right thing:

struct base {
  base();
  base(int);
};
base::base() { }
base::base(int) {}
struct derived: base {
  using base::base;
};
int main() {
  derived d1(3);
  derived d2;
}

0x00000054:   DW_TAG_structure_type
                DW_AT_calling_convention        (DW_CC_pass_by_value)
                DW_AT_name      ("derived")
                DW_AT_byte_size (0x01)
                DW_AT_decl_file ("/usr/local/google/home/blaikie/dev/scratch/test.cpp")
                DW_AT_decl_line (7)

0x0000005a:     DW_TAG_inheritance
                  DW_AT_type    (0x0000002b "base")
                  DW_AT_data_member_location    (0x00)

0x00000060:     DW_TAG_subprogram
                  DW_AT_name    ("base")
                  DW_AT_declaration     (true)
                  DW_AT_artificial      (true)
                  DW_AT_external        (true)

0x00000062:       DW_TAG_formal_parameter
                    DW_AT_type  (0x000000de "derived *")
                    DW_AT_artificial    (true)

0x00000067:       DW_TAG_formal_parameter
                    DW_AT_type  (0x00000050 "int")

0x0000006c:       NULL

0x0000006d:     DW_TAG_subprogram
                  DW_AT_name    ("derived")
                  DW_AT_declaration     (true)
                  DW_AT_artificial      (true)
                  DW_AT_external        (true)

0x0000006f:       DW_TAG_formal_parameter
                    DW_AT_type  (0x000000de "derived *")
                    DW_AT_artificial    (true)

0x00000074:       NULL

0x00000075:     NULL

[Michael137]

Good catch, the AST looks as follows:

CXXRecordDecl 0x3c54cc90 <line:6:1, line:8:1> line:6:8 referenced struct Bar definition
|-DefinitionData pass_in_registers empty standard_layout trivially_copyable can_const_default_init
...
|-public 'Foo':'Foo'
|-CXXRecordDecl 0x3c54ce48 <col:1, col:8> col:8 implicit struct Bar
|-UsingDecl 0x3c54d358 <line:7:3, col:14> col:14 Foo::Bar
...
|-CXXConstructorDecl 0x3c56b5e0 <line:6:8> col:8 implicit used Bar 'void () noexcept(false)' inline default
| |-CXXCtorInitializer 'Foo':'Foo'
| | `-CXXConstructExpr 0x3c56c098 <col:8> 'Foo':'Foo' 'void ()'
| `-CompoundStmt 0x3c56c0f8 <col:8>
...
`-CXXConstructorDecl 0x3c56c250 <line:7:14> col:14 implicit used Foo 'void (int) noexcept(false)' inline
  |-ParmVarDecl 0x3c56c368 <col:14> col:14 implicit 'int'
  |-CXXCtorInitializer 'Foo':'Foo'
  | `-CXXInheritedCtorInitExpr 0x3c56c438 <col:14> 'Foo':'Foo'
  `-CompoundStmt 0x3c56c490 <col:14>

So the default constructor gets turned into a CXXConstructorDecl called Bar. Whereas the one with a parameter gets turned into a CXXConstructorDecl called Foo. Wonder if this is an intentional (@AaronBallman). There is this FIXME I found:

llvm-project/clang/lib/Sema/SemaDeclCXX.cpp

Lines 13955 to 13958 in 7844257

	// FIXME: Add a new kind of DeclarationName for an inherited constructor.
	// For now we use the name of the base class constructor as a member of the
	// derived class to indicate a (fake) inherited constructor name.
	DeclarationName Name = BaseCtor->getDeclName();

This is probably because we might have a constructor in the derived class too with the same arguments as the inherited constructor. In which case they couldn't have the same name for lookup purposes? Just a guess.