To reproduce compile the program (g++ -g -o main main.cpp): #include <iostream> #include <vector> int main() { std::vector<int> v = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}; for (auto i : v) { std::cout << i << std::endl; } return 0; } Run gdb: $ gdb -q -batch main -ex "b main.cpp:7" -ex "run" -ex "info locals" The output contains artificial symbols __for_range, __for_begin, __for_end: Breakpoint 1, main () at main.cpp:7 7 std::cout << i << std::endl; i = 1 __for_range = std::vector of length 10, capacity 10 = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10} __for_begin = 1 __for_end = 60721 v = std::vector of length 10, capacity 10 = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10} These symbols also returned when iterating over a block in python, and is_artificial is not exposed in python API. This was fixed for Ada, but not other languages in https://sourceware.org/bugzilla/show_bug.cgi?id=28180. I've noticed, that in python such symbols have the line=0. Is it correct to use this as a sign that the symbol is artificial?
I guess I take it back: `this` in c++ methods is also artificial and has line=0, but should be shown. I don't know if range-loop variables are shown by design or not.
(In reply to Dmitry Neverov from comment #1) > I don't know if range-loop variables are shown by design or not. Normally gdb just does what the compiler tells it. Ada is a bit special because it emits some forms of debuginfo via symbol names. By default there isn't much of this any more, but there are still a few cases that can't be avoided. It would be fine by me to give Python a way to detect artificiality. Omitting artificial variables via some option would also be fine. I suppose my view is that, overall, seeing these isn't too confusing, and might be helpful in some cases when debugging. It lets you inspect a compiler transform and see some objects that would otherwise be inaccessible -- like if you want to debug some iterator implementation.