dblaikie added a comment. In D123319#3506745 <https://reviews.llvm.org/D123319#3506745>, @shafik wrote:
>> Any update/further details here? > > David, apologies for not getting back to you sooner. The context is D105564 > <https://reviews.llvm.org/D105564> which I started working on again recently. > I was having difficulties finding a solution that also worked for local > lambdas. But what I don't understand is what makes local lambdas special. You can produce the same DWARF (so far as I can think of - maybe there's some distinction I'm missing?) without lambdas: void f1() { auto x = [](){ return 3; }; x(); } void f2() { struct t1 { auto operator()() { return 3; } }; t1 v1; v1(); } $ clang++-tot test.cpp -g -c && llvm-dwarfdump-tot test.o | grep "DW_TAG\|DW_AT_type\|DW_AT_name" | sed -e "s/^...........//" ... DW_TAG_subprogram DW_AT_name ("f1") DW_TAG_variable DW_AT_name ("x") DW_AT_type (0x0000003a "class ") DW_TAG_class_type DW_TAG_subprogram DW_AT_name ("operator()") DW_AT_type (0x00000050 "int") DW_TAG_formal_parameter DW_AT_type (0x00000054 "const class *") ... DW_TAG_subprogram DW_AT_specification (0x0000003f "operator()") DW_TAG_formal_parameter DW_AT_name ("this") DW_AT_type (0x000000cc "const class *") DW_TAG_subprogram DW_AT_name ("f2") DW_TAG_variable DW_AT_name ("v1") DW_AT_type (0x00000090 "t1") DW_TAG_structure_type DW_AT_name ("t1") DW_TAG_subprogram DW_AT_name ("operator()") DW_AT_type (0x000000a6 "auto") DW_TAG_formal_parameter DW_AT_type (0x000000a8 "t1 *") DW_TAG_subprogram DW_AT_type (0x00000050 "int") DW_AT_specification (0x00000096 "operator()") DW_TAG_formal_parameter DW_AT_name ("this") DW_AT_type (0x000000d1 "t1 *") DW_TAG_pointer_type DW_AT_type (0x00000059 "const class ") DW_TAG_pointer_type DW_AT_type (0x00000090 "t1") So if there's particularly an issue with lambdas, it's probably also with the above local type example. > I discovered eventually that what I had worked with debug-info that gcc > generated Yep, at least testing GCC 11 just now - it seems GCC doesn't use "auto" for local types, be they named or unnamed. > and realized that gcc was not emitting `auto` for lambdas and decided to > match gcc's behavior here since we often do that. I think that's only a really sound argument when it's GDB compatibility/somewhat outside our control on the consumer side. I'm not sure there's a good argument for doing this for lldb when we can fix lldb to handle the right DWARF instead. > I think an alternative approach would have been to emit `DW_AT_linkage_name` > for local lambdas but when I dug into that it looked like we were dropping > the linkage name several step before where would emit `DW_AT_linkage_name` > and it was not clear to me how easy a fix that was. What does the linkage name do for your use case? Which cases are missing linkage names/where do they go missing? > I am happy to consider other approaches as well to solving lookup for local > lambdas for D105564 <https://reviews.llvm.org/D105564>. Let me know what you > think. Why does the return type help perform lookup? What kind of lookup? (again, my take is that "auto" return types probably shouldn't be described at all - we should just not describe functions where we don't know their return types because they're not very useful to know about (overload resolution, yes, but then you can't call them anyway) - but that's a broader argument to make/change to make) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D123319/new/ https://reviews.llvm.org/D123319 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
