On Wed, May 18, 2022 at 9:53 AM David Blaikie <[email protected]> wrote: > > On Wed, May 18, 2022 at 4:16 AM Robinson, Paul <[email protected]> wrote: > > > > > Looks like gdb and lldb both have issues with C++ local types (either > > > types defined in anonymous namespaces, or otherwise localized - eg: a > > > non-local template with a local type or variable in one of its > > > parameters). > > > ... > > > So... what could/should we do about this? > > > > Do you have a strong argument for why these are not debugger bugs? > > It sounds to me like gdb/lldb are handling anonymous namespaces > > incorrectly, in effect treating their contents as global rather than > > CU-local. > > Oh, right, sorry forgot to include the trickier examples. > > So for a non-template this isn't especially burdensome (check for an > anonymous namespace in the parent scopes - it's language specific, but > not a ton of weird work to do) - for templates it's a bit harder (you > have to check every template parameter, and potentially arbitrarily > deep - eg: you might have a template parameter that's a function type > and one of the parameters is a pointer type and the type the pointer > points to is local - thus the template is local. That seems a bit more > of a stretch to ask the consumer to do totally reliably) - but the > worst case, that at the moment there's potentially no way to > disambiguate whether the type is local or not: A non-type template > parameter that points to a local variable. > > static int x = 3; > template<int *> struct t1 { }; > t1<&x> v; > > Currently both LLVM and GCC name this type "t1<&x>" and LLVM at least > puts a DW_AT_location on the DW_TAG_template_value_parameter which > points to the global variable (not the DW_TAG_variable, but to the > actual ELF symbol in the file) - though this choice has some negative > effects (causes the symbol to be "used" and linked in - which means > that enabling debug info can effect the behavior of the program > (global ctors in that file execute when they wouldn't've otherwise, > etc)). > > If the location is provided, arguably the consumer could lookup the > symbol and check its linkage (not always accurate - LTO might've > internalized a variable that wasn't actually internal in the original > source, for instance) - but when the location is not provided there's > no way to know whether "t1<&x>" is local or not.
Ping - anyone got further ideas about how to address this issue/encode this information? _______________________________________________ Dwarf-Discuss mailing list [email protected] http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
