[clang] Preferred name not generated nor used to declare variables in DWARF when used as template argument in code

[royitaqi]

Problem

TL;DR Compiling the following code generates an object file whose DWARF doesn't contain the preferred name. This is true when compiling with -ggdb and with -glldb. Inspecting the DWARF shows that the variable is declared as Foo<Foo<int> >. The preferred name, i.e. BarInt (case sensitive), is no where to be found in the DWARF.

Code:

template <typename T> struct Foo;

typedef Foo<int> BarInt;

template <typename T>
struct [[clang::preferred_name(BarInt)]] Foo{};

int main() {
  // BarInt barInt;
  Foo<BarInt> fooBarInt;
  return 0;
}

DWARF:

0x00000033:     DW_TAG_variable
                  DW_AT_location	(DW_OP_fbreg +11)
                  DW_AT_name	("fooBarInt")
                  DW_AT_decl_file	("/Users/royshi/demo/preferred_name/two.cpp")
                  DW_AT_decl_line	(10)
                  DW_AT_type	(0x00000043 "Foo<Foo<int> >")

So lldb cannot print the preferred name:

(lldb) p fooBarInt
(Foo<Foo<int> >)  {}

Repro

Use the above source code (call it two.cpp), then:

~/public_llvm/build/bin/clang -O0 -glldb -c two.cpp   # or -ggdb

dwarfdump two.o

# Note: For me, the above clang cannot link, so I used xcrun clang++. It shouldn't matter which one you use.
xcrun clang++ two.o

lldb a.out -o "b two.cpp:10" -o "r" -o "p fooBarInt"

See compilation, dwarfdump, and lldb output:

• -ggdb: https://gist.github.com/royitaqi/cbf7a4d038f5b73dc60e5932bb2b593d
• -glldb: https://gist.github.com/royitaqi/46af47f0472976eb94b9725c073668df

I tested these on macOS. Haven't tested on Linux.

Note: If we uncomment that line // BarInt barInt;, the preferred name will be generated for barInt (type = BarInt), but not for fooBarInt (type = Foo<Foo<int > >; I'm expecting Foo<BarInt>, since the type BarInt now exists).

--

cc @Michael137 , @clayborg

[llvmbot]

@llvm/issue-subscribers-debuginfo

Author: Roy Shi (royitaqi)

# Problem 1

Compiling the following code generates an object file whose DWARF doesn't contain the preferred name. This is true when compiling with -ggdb and with -glldb.

Inspecting the DWARF shows that the variable is declared as Foo<Foo<int> >. The preferred name, i.e. BarInt (case sensitive), is no where to be found in the DWARF.

Code:

template <typename T> struct Foo;

typedef Foo<int> BarInt;

template <typename T>
struct [[clang::preferred_name(BarInt)]] Foo{};

int main() {
  // BarInt barInt;
  Foo<BarInt> fooBarInt;
  return 0;
}

DWARF:

0x00000033:     DW_TAG_variable
                  DW_AT_location	(DW_OP_fbreg +11)
                  DW_AT_name	("fooBarInt")
                  DW_AT_decl_file	("/Users/royshi/demo/preferred_name/two.cpp")
                  DW_AT_decl_line	(10)
                  DW_AT_type	(0x00000043 "Foo<Foo<int> >")

So lldb cannot print the preferred name:

(lldb) p fooBarInt
(Foo<Foo<int> >)  {}

Repro

Use the above source code (call it two.cpp), then:

~/public_llvm/build/bin/clang -O0 -glldb -c two.cpp   # or -ggdb

dwarfdump two.o

# Note: For me, the above clang cannot link, so I used xcrun clang++. It shouldn't matter which one you use.
xcrun clang++ two.o

lldb a.out -o "b two.cpp:10" -o "r" -o "p fooBarInt"

See compilation, dwarfdump, and lldb output:

• -ggdb: https://gist.github.com/royitaqi/cbf7a4d038f5b73dc60e5932bb2b593d
• -glldb: https://gist.github.com/royitaqi/46af47f0472976eb94b9725c073668df

I tested these on macOS. Haven't tested on Linux.

Problem 2

If we uncomment the line // BarInt barInt;, the compiler can now generate typedef(s) for the preferred name.

For example, with -ggdb, we now see this typedef.

0x0000004d:   DW_TAG_typedef
                DW_AT_type	(0x00000055 "Foo<int>")
                DW_AT_name	("BarInt")
                DW_AT_decl_file	("/Users/royshi/demo/preferred_name/two.cpp")
                DW_AT_decl_line	(3)

Note: FWIW, -glldb generates one more typedef, I was told that this is by design.

However, this typedef is only used by the variable barInt, not by fooBarInt.

0x00000032:     DW_TAG_variable
                  DW_AT_location	(DW_OP_fbreg +11)
                  DW_AT_name	("barInt")
                  DW_AT_decl_file	("/Users/royshi/demo/preferred_name/two.cpp")
                  DW_AT_decl_line	(9)
                  DW_AT_type	(0x0000004d "BarInt")

0x0000003d:     DW_TAG_variable
                  DW_AT_location	(DW_OP_fbreg +10)
                  DW_AT_name	("fooBarInt")
                  DW_AT_decl_file	("/Users/royshi/demo/preferred_name/two.cpp")
                  DW_AT_decl_line	(10)
                  DW_AT_type	(0x00000062 "Foo<Foo<int> >")

See full output:

• -ggdb: https://gist.github.com/royitaqi/d2b6c7c9ca56f886f051479bb7edde90
• -glldb: https://gist.github.com/royitaqi/030ac6963d7696f4cc34bb826803e098

--

cc @Michael137 , @clayborg

[llvmbot]

@llvm/issue-subscribers-clang-codegen

Author: Roy Shi (royitaqi)

# Problem 1

Compiling the following code generates an object file whose DWARF doesn't contain the preferred name. This is true when compiling with -ggdb and with -glldb.

Inspecting the DWARF shows that the variable is declared as Foo<Foo<int> >. The preferred name, i.e. BarInt (case sensitive), is no where to be found in the DWARF.

Code:

template <typename T> struct Foo;

typedef Foo<int> BarInt;

template <typename T>
struct [[clang::preferred_name(BarInt)]] Foo{};

int main() {
  // BarInt barInt;
  Foo<BarInt> fooBarInt;
  return 0;
}

DWARF:

0x00000033:     DW_TAG_variable
                  DW_AT_location	(DW_OP_fbreg +11)
                  DW_AT_name	("fooBarInt")
                  DW_AT_decl_file	("/Users/royshi/demo/preferred_name/two.cpp")
                  DW_AT_decl_line	(10)
                  DW_AT_type	(0x00000043 "Foo<Foo<int> >")

So lldb cannot print the preferred name:

(lldb) p fooBarInt
(Foo<Foo<int> >)  {}

Repro

Use the above source code (call it two.cpp), then:

~/public_llvm/build/bin/clang -O0 -glldb -c two.cpp   # or -ggdb

dwarfdump two.o

# Note: For me, the above clang cannot link, so I used xcrun clang++. It shouldn't matter which one you use.
xcrun clang++ two.o

lldb a.out -o "b two.cpp:10" -o "r" -o "p fooBarInt"

See compilation, dwarfdump, and lldb output:

• -ggdb: https://gist.github.com/royitaqi/cbf7a4d038f5b73dc60e5932bb2b593d
• -glldb: https://gist.github.com/royitaqi/46af47f0472976eb94b9725c073668df

I tested these on macOS. Haven't tested on Linux.

Problem 2

If we uncomment the line // BarInt barInt;, the compiler can now generate typedef(s) for the preferred name.

For example, with -ggdb, we now see this typedef.

0x0000004d:   DW_TAG_typedef
                DW_AT_type	(0x00000055 "Foo<int>")
                DW_AT_name	("BarInt")
                DW_AT_decl_file	("/Users/royshi/demo/preferred_name/two.cpp")
                DW_AT_decl_line	(3)

Note: FWIW, -glldb generates one more typedef, I was told that this is by design.

However, this typedef is only used by the variable barInt, not by fooBarInt.

0x00000032:     DW_TAG_variable
                  DW_AT_location	(DW_OP_fbreg +11)
                  DW_AT_name	("barInt")
                  DW_AT_decl_file	("/Users/royshi/demo/preferred_name/two.cpp")
                  DW_AT_decl_line	(9)
                  DW_AT_type	(0x0000004d "BarInt")

0x0000003d:     DW_TAG_variable
                  DW_AT_location	(DW_OP_fbreg +10)
                  DW_AT_name	("fooBarInt")
                  DW_AT_decl_file	("/Users/royshi/demo/preferred_name/two.cpp")
                  DW_AT_decl_line	(10)
                  DW_AT_type	(0x00000062 "Foo<Foo<int> >")

See full output:

• -ggdb: https://gist.github.com/royitaqi/d2b6c7c9ca56f886f051479bb7edde90
• -glldb: https://gist.github.com/royitaqi/030ac6963d7696f4cc34bb826803e098

--

cc @Michael137 , @clayborg

[Michael137]

The fact the "unused" typedef doesnt get retained isn't specific to the preferred_name case though right? Is the suggestion that we do this specially for typedefs used as preferred_name?

[Michael137]

Also changing the DW_AT_name to contain the non-canonical typedef is probably not feasible (though I'd have to remind myself of that discussion): see discussion in #110767

[royitaqi]

The fact the "unused" typedef doesnt get retained isn't specific to the preferred_name case though right? Is the suggestion that we do this specially for typedefs used as preferred_name?

Pardon my lack of compilation knowledge. What do you mean by "unused"? The code does have Foo<BarInt> fooBarInt, so it seems to me the typedef BarInt is used and should be retained. Does the compiler first "flattens/inlines" all typedefs to find the "raw" type for the variable, and that's not Foo<int>, so it's thinking BarInt isn't useful to be emitted?

[Michael137]

The fact the "unused" typedef doesnt get retained isn't specific to the preferred_name case though right? Is the suggestion that we do this specially for typedefs used as preferred_name?

Pardon my lack of compilation knowledge. What do you mean by "unused"? The code does have Foo<BarInt> fooBarInt, so it seems to me the typedef BarInt is used and should be retained. Does the compiler first "flattens/inlines" all typedefs to find the "raw" type for the variable, and that's not Foo<int>, so it's thinking BarInt isn't useful to be emitted?

Yea it's more unused in quotes. AFAICT, it's just a consequence of how we canonicalise TemplateSpecializationTypes:

llvm-project/clang/lib/CodeGen/CGDebugInfo.cpp

Line 3945 in e07aef9

T = Spec->desugar();

Here Foo<BarInt> gets desugared into Foo<Foo<int>>.

This dates back to:

commit 0f139a1df11e6f3936f62f71d176b6642cee2b8b
Author: Douglas Gregor <dgregor@apple.com>
Date:   Mon Dec 21 20:18:30 2009 +0000

    Improve on my previous fix for debug information. Rather than
    recursing in CGDebugInfo::CreateTypeNode, teach
    CanonicalizeTypeForDebugInfo---now called UnwrapTypeForDebugInfo---to
    keep unwrapping the type until we hit something that can be
    represented by debug information. Thanks to Anders for pointing this out!
    
    llvm-svn: 91840

Prior to that it looked like this:

   case Type::TemplateSpecialization:
    // DWARF can't represent template specialization types; instead,
    // we drill down to the canonical type, which will be a record type.
    return CreateType(cast<RecordType>(CGM.getContext().getCanonicalType(Ty)),
                      Unit);

I'm not sure I understand that comment tbh. @dwblaikie @adrian-prantl do you know the history on this? And why we need to canonicalise the template specialisation types? Is it because otherwise we wouldn't be able to distinguish two specialisations. Canonicalising makes them trivially de-dupable?

[dwblaikie]

I'm not sure I understand that comment tbh. @dwblaikie @adrian-prantl do you know the history on this? And why we need to canonicalise the template specialisation types? Is it because otherwise we wouldn't be able to distinguish two specialisations. Canonicalising makes them trivially de-dupable?

So... I wrote like 10 paragraphs that were a bit unwieldy, so trying again - but a caveat that there's a lot of dimensions in this area so it's a bit complex - can talk more in person over the LLVM dev meeting, perhaps.

1. at a basic level, DW_AT_name (+ DW_AT_name of parent scopes) as a unique/canonical name is important for DWARF consumers

2. except for/prior to preferred_name, the non-canonical-ness could be produced very locally (eg: typedef int x; std::vector<x> - and someone else using std::vector<y> - that's no good, we need identical names)

3. Template parameter printing (especially for more interesting things like function pointer types, etc) between producers isn't entirely identical and consumers do varying amounts of work to try to canonicalize over those differences

4. Simplified Template Names leans into this recanonicalization more heavily (though it bails out in cases where DWARF doesn't have enough information) - though it doesn't look through typedefs I don't think, because it wasn't necessary because producers don't produce DWARF like that

5. We could use preferred_names for types in the implementation of templates (eg: for the value of DW_TAG_template_type_parameter, for the DW_AT_type of local/member variables inside templates, etc) - though using it in DW_TAG_template_type_parameter (or further/indirectly inside it) would need fixes to Simplified Template Names handling to look through the typedefs to come up with the canonical name.
   This would produce the opposite effect where the preferred name would be used even if the user never named it (eg: user writes Foo<Foo<int>> but still gets a template with a T parameter that renders as Foo<int> (whether or not the /type/ renders as Foo<Foo<int>> or Foo<BarInt> would depend on how the consumer canonicalizes things)