Hmm - I guess one complication of only putting the mangling number on
the type, is that you need the scope of the lambda too... which is
tricky in this case:
extern int i;
int i = []{ return 3; }();
In this case, the lambda is mangled in the scope of the global
variable `i`: i::{lambda()#1}::operator()() const
(https://godbolt.org/z/15Eqa8ajT)
Oh, and I guess you can use a lambda without ever instantiating its
operator(), and for a generic lambda there's nothing to describe...
eg:
template<typename T>
void f1(const T&){}
inline void f2() {
f1([](auto){});
}
void f3() {
f2();
}
Clang's DWARF for the anonymous type is:
0x00000043: DW_TAG_class_type
DW_AT_calling_convention (DW_CC_pass_by_value)
DW_AT_byte_size (0x01)
DW_AT_decl_file
("/usr/local/google/home/blaikie/dev/scratch/test.cpp")
DW_AT_decl_line (4)
GCC's includes a dtor (called "~<lambda>") but the type just has size,
file, line, and column.
So we could avoid using the whole mangled name of the anonymous type
in some cases - maybe it's worth having features (like being able to
provide the mangling number in an attribute, maybe being able to scope
the type inside a variable DIE? though that sounds a bit frightening)
to help in those cases, even if in some of the worst cases we'd have
to use the mangled name to reassociate anonymous types?
- Dave
On Mon, Aug 22, 2022 at 12:44 PM David Blaikie <dblai...@gmail.com> wrote:
>
> Ping - any thoughts here?
>
> On Sun, Jul 24, 2022 at 9:08 PM David Blaikie <dblai...@gmail.com> wrote:
> >
> > Ping on this thread - would love to hear what ideas folks have for
> > addressing the naming of anonymous types (enums, structs/classes, and
> > lambdas) - especially if it'd make it easier to go back/forth between
> > the DW_AT_name of a template with an unnamed type as a parameter and
> > the actual DIEs describing the same parameter type.
> >
> > On Tue, Jun 14, 2022 at 1:02 PM David Blaikie <dblai...@gmail.com> wrote:
> > >
> > > Looks like https://reviews.llvm.org/D122766 (-ffile-reproducible) might
> > > solve my immediate issues in clang, but I think we should still consider
> > > moving to a more canonical naming of lambdas that, necessarily, doesn't
> > > include the file name (unfortunately). Probably has to include the lambda
> > > numbering/something roughly equivalent to the mangled lambda name - it
> > > could include type information (it'd be superfluous to a unique
> > > identifier, but I don't think it would break consistently naming the same
> > > type across CUs either).
> > >
> > > Anyone got ideas/preferences/thoughts on this?
> > >
> > > On Mon, Jan 24, 2022 at 5:51 PM David Blaikie <dblai...@gmail.com> wrote:
> > >>
> > >> On Mon, Jan 24, 2022 at 5:37 PM Adrian Prantl <apra...@apple.com> wrote:
> > >>>
> > >>>
> > >>>
> > >>> On Jan 23, 2022, at 2:53 PM, David Blaikie <dblai...@gmail.com> wrote:
> > >>>
> > >>> A rather common "quality of implementation" issue seems to be lambda
> > >>> naming.
> > >>>
> > >>> I came across this due to non-canonicalization of lambda names in
> > >>> template parameters depending on how a source file is named in Clang,
> > >>> and GCC's seem to be very ambiguous:
> > >>>
> > >>> $ cat tmp/lambda.h
> > >>> template<typename T>
> > >>> void f1(T) { }
> > >>> static int i = (f1([]{}), 1);
> > >>> static int j = (f1([]{}), 2);
> > >>> void f1() {
> > >>> f1([]{});
> > >>> f1([]{});
> > >>> }
> > >>> $ cat tmp/lambda.cpp
> > >>> #ifdef I_PATH
> > >>> #include <tmp/lambda.h>
> > >>> #else
> > >>> #include "lambda.h"
> > >>> #endif
> > >>> $ clang++-tot tmp/lambda.cpp -g -c -I. -DI_PATH && llvm-dwarfdump-tot
> > >>> lambda.o | grep "f1<"
> > >>> DW_AT_name ("f1<(lambda at ./tmp/lambda.h:3:20)>")
> > >>> DW_AT_name ("f1<(lambda at ./tmp/lambda.h:4:20)>")
> > >>> DW_AT_name ("f1<(lambda at ./tmp/lambda.h:6:6)>")
> > >>> DW_AT_name ("f1<(lambda at ./tmp/lambda.h:7:6)>")
> > >>> $ clang++-tot tmp/lambda.cpp -g -c && llvm-dwarfdump-tot lambda.o |
> > >>> grep "f1<"
> > >>> DW_AT_name ("f1<(lambda at tmp/lambda.h:3:20)>")
> > >>> DW_AT_name ("f1<(lambda at tmp/lambda.h:4:20)>")
> > >>> DW_AT_name ("f1<(lambda at tmp/lambda.h:6:6)>")
> > >>> DW_AT_name ("f1<(lambda at tmp/lambda.h:7:6)>")
> > >>> $ g++-tot tmp/lambda.cpp -g -c -I. && llvm-dwarfdump-tot lambda.o |
> > >>> grep "f1<"
> > >>> DW_AT_name ("f1<f1()::<lambda()> >")
> > >>> DW_AT_name ("f1<f1()::<lambda()> >")
> > >>> DW_AT_name ("f1<<lambda()> >")
> > >>>
> > >>> DW_AT_name ("f1<<lambda()> >")
> > >>>
> > >>> (I came across this in the context of my simplified template names work
> > >>> - rebuilding names from the DW_TAG description of the template
> > >>> parameters - and while I'm not rebuilding names that have lambda
> > >>> parameters (keep encoding the full string instead). The issue is if
> > >>> some other type depending on a type with a lambda parameter - but then
> > >>> multiple uses of that inner type exist, from different translation
> > >>> units (using type units) with different ways of naming the same file -
> > >>> so then the expected name has one spelling, but the actual spelling is
> > >>> different due to the "./")
> > >>>
> > >>> But all this said - it'd be good to figure out a reliable naming - the
> > >>> naming we have here, while usable for humans (pointing to surce files,
> > >>> etc) - they don't reliably give unique names for each lambda/template
> > >>> instantiation which would make it difficult for a consumer to know if
> > >>> two entities are the same (important for types - is some function
> > >>> parameter the same type as another type?)
> > >>>
> > >>> While it's expected cross-producer (eg: trying to be compatible with
> > >>> GCC and Clang debug info) you have to do some fuzzy matching (eg:
> > >>> "f1<int*>" or "f1<int *>" at the most basic - there are more
> > >>> complicated cases) - this one's not possible with the data available.
> > >>>
> > >>> The source file/line/column is insufficient to uniquely identify a
> > >>> lambda (multiple lambdas stamped out by a macro would get all the same
> > >>> file/line/col) and valid code (albeit unlikely) that writes the same
> > >>> definition in multiple places could make the same lambda have different
> > >>> names.
> > >>>
> > >>> We should probably use something more like the way various ABI
> > >>> manglings do to identify these entities.
> > >>>
> > >>> But we should probably also do this for other unnamed types that have
> > >>> linkage (need to/would benefit from being matched up between two CUs),
> > >>> even not lambdas.
> > >>>
> > >>> FWIW, at least the llvm-cxxfilt demanglings of clang's manglings for
> > >>> these symbols is:
> > >>>
> > >>> void f1<$_0>($_0)
> > >>> f1<$_1>($_1)
> > >>> void f1<f1()::$_2>(f1()::$_2)
> > >>> void f1<f1()::$_3>(f1()::$_3)
> > >>>
> > >>> Should we use that instead?
> > >>>
> > >>>
> > >>> The only other information that the current human-readable DWARF name
> > >>> carries is the file+line and that is fully redundant with
> > >>> DW_AT_file/line, so the above scheme seem reasonable to me. Poorly
> > >>> symbolicated backtraces would be worse in this scheme, so I'm expecting
> > >>> most pushback from users who rely on a tool that just prints the human
> > >>> readable name with no source info.
> > >>
> > >>
> > >> Yeah - you can always pull the file/line/col from the DW_AT_decl_*
> > >> anyway, so encoding it in the type name does seem redundant and
> > >> inefficient indeed (beyond/independent of the correctness issues).
> > >>>
> > >>> GCC's mangling's different (in these examples that's OK, since they're
> > >>> all internal linkage):
> > >>>
> > >>> void f1<f1()::'lambda0'()>(f1()::'lambda0'())
> > >>> void f1<f1()::'lambda'()>(f1()::'lambda'())
> > >>>
> > >>> If I add an example like this:
> > >>>
> > >>> inline auto f1() { return []{}; }
> > >>>
> > >>> and instantiate the template with the result of f1:
> > >>>
> > >>> void f1<f2()::'lambda'()>(f2()::'lambda'())
> > >>>
> > >>> GCC:
> > >>>
> > >>> void f1<f2()::'lambda'()>(f2()::'lambda'())
> > >>>
> > >>> So they consistently use the same mangling - we could use the same
> > >>> naming for template parameters?
> > >>>
> > >>> How should we communicate this sort of identity for unnamed types in
> > >>> the DIEs describing the types themselves (not just the string of a
> > >>> template name of a type instantiated with the unnamed type) so the
> > >>> unnamed type can be matched up between translation units.
> > >>>
> > >>> eg, if I have these two translation units:
> > >>> // header
> > >>> inline auto f1() { struct { } local; return local; }
> > >>> // unit 1:
> > >>> #include "header"
> > >>> auto f2(decltype(f1())) { }
> > >>> // unit 2:
> > >>> #include "header"
> > >>> decltype(f1()) v1;
> > >>>
> > >>> Currently the DWARF produced for this unnamed type is:
> > >>> 0x0000003f: DW_TAG_structure_type
> > >>> DW_AT_calling_convention (DW_CC_pass_by_value)
> > >>> DW_AT_byte_size (0x01)
> > >>> DW_AT_decl_file
> > >>> ("/usr/local/google/home/blaikie/dev/scratch/test.cpp")
> > >>> DW_AT_decl_line (1)
> > >>>
> > >>>
> > >>> is this the type of struct {}?
> > >>
> > >>
> > >> Yep. You'll get separate distinct descriptions that are essentially the
> > >> same - imagine if `f1` had two such types written as "struct {}" (say
> > >> they were used to instantiate two different templates - "struct {} a;
> > >> struct {} b; f_templ(a); f_templ(b);" - the DWARF will have two of those
> > >> unnamed DW_TAG_structure_types and two template specializations, etc -
> > >> but no way to know which of those unnamed types line up with uses in
> > >> another translation unit, in terms of overload resolution, etc.
> > >>>
> > >>> So there's no way to know if you see that structure type definition in
> > >>> two different translation units whether they refer to the same type
> > >>> because there may be multiple types that have the same DWARF
> > >>> description. (so no way to know if the DWARF consumer should allow the
> > >>> user to evaluate an expression `f2(v1)` or not, I think?)
> > >>>
> > >>>
> > >>> Does a C++ compiler usually treat structurally equivalent but
> > >>> differently named types as interchangeable?
> > >>
> > >>
> > >> No - given "struct A { int i; }; struct B { int i; }; void f1(A); ... "
> > >> - "f1(A())" is valid, but "f1(B())" is invalid and an error at
> > >> compile-time. https://godbolt.org/z/de7Yce1qW
> > >>
> > >>>
> > >>> Does a C++ compiler usually treat structurally equivalent anonymous
> > >>> types as interchangeable?
> > >>
> > >>
> > >> No, same rules apply as named types: https://godbolt.org/z/hxWMYbWc8
> > >>
> > >>>
> > >>>
> > >>> -- adrian
> > >>>
> > >>>
> > >>> I guess the only way to have an unnamed type with linkage is to use it
> > >>> inside an inline function - so within that scope you'd have to produce
> > >>> DWARF for any types consistently in all definitions of the function and
> > >>> then a consumer could match them up by counting (assuming the unnamed
> > >>> types were always emitted in the same order in the child DIE list)...
> > >>>
> > >>> But this all seems a bit subtle & maybe would benefit from a more
> > >>> robust/explicit description?
> > >>>
> > >>> Perhaps adding an integer attribute to number anonymous types? They'd
> > >>> need to differentiate between lambdas and other anonymous types, since
> > >>> they have separate numberings.
> > >>>
> > >>>
_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
