dblaikie added a comment. In D153536#4475308 <https://reviews.llvm.org/D153536#4475308>, @cor3ntin wrote:
> In D153536#4475240 <https://reviews.llvm.org/D153536#4475240>, @dblaikie > wrote: > >> In D153536#4475199 <https://reviews.llvm.org/D153536#4475199>, @cor3ntin >> wrote: >> >>> In D153536#4474733 <https://reviews.llvm.org/D153536#4474733>, @dblaikie >>> wrote: >>> >>>> Maybe try testing with more different values, to demonstrate which >>>> entities the debugger is finding? >>>> >>>> int _ = 1; >>>> int _ = 2; >>>> { >>>> int _ = 3; >>>> int _ = 7; >>>> } >>>> >>>> Or something like that. But, honestly, if the point is that these >>>> variables should be unnameable - perhaps we shouldn't generate any DWARF >>>> for them? >>> >>> The variables should still be inspectable, ideally. It's true it makes no >>> sense to be able to use them in expressions, and maybe if lldb use clang to >>> evaluate expressions that would just work? >> >> I think that's going to be tricky - because we don't emit DWARF to say where >> one variable's lifetime starts compared to another in the same scope - so >> likely a debugger would just always show the first or last variable with the >> same name in a given scope (so in the above example you could probably only >> print {1,3} or {2,7}) - and getting it wrong is more likely and more >> problematic than existing cases of shadowed variables. If we can't get this >> right, which I don't think we can, practically speaking, at the moment (the >> DWARF feature we'd have to support to do this better would probably be >> `DW_AT_start_scope` to say at what instruction the lifetime of a variable >> starts) - it may be best not to include it at all? > > It doesn't seems to be confused on simple examples > > cpp > * thread #1, name = 'placeholder', stop reason = step in > frame #0: 0x0000555555555157 placeholder`main at > debug_placeholder.cpp:8:13 > 5 { > 6 int _ = 4; > 7 int _ = 5; > -> 8 int _ = 6; > 9 } > 10 } > (lldb) frame variable > (int) _ = 1 > (int) _ = 2 > (int) _ = 3 > (int) _ = 4 > (int) _ = 5 > (int) _ = -9432 > > That being said, if you think it's more prudent, I would not mind Huh, I guess maybe it's got some heuristics based on line number. Could probably thwart those by stamping this out with a macro (which would cause all code in the macro to be attributed to the line where the macro is named) - add some function calls in, so you can step back up from the call to get to more precise locations and you'd probably see some problems. That's probably a bit contrived (but maybe not - perhaps `_` would be more common in macros). *shrug* maybe it's OK enough. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D153536/new/ https://reviews.llvm.org/D153536 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
