[Bug python/20120] New: multiple global blocks or broken global scope in GDB/Python

["michael.lenz at udo dot edu" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=20120

            Bug ID: 20120
           Summary: multiple global blocks or broken global scope in
                    GDB/Python
           Product: gdb
           Version: 7.11
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: python
          Assignee: unassigned at sourceware dot org
          Reporter: michael.lenz at udo dot edu
  Target Milestone: ---

Created attachment 9280
  --> https://sourceware.org/bugzilla/attachment.cgi?id=9280&action=edit
MWE for this bug

I'm not quite sure whether this is a bug in GDB or in its Python API. I file it
under "Python", because that's how I have discovered it. Feel free to move it,
if it turns out to reside in GDB itself.

GDB/Python's API doc states "The outermost block is known as the global block.
The global block typically holds public global variables and functions."
(https://sourceware.org/gdb/onlinedocs/gdb/Blocks-In-Python.html)
>From the rest of the documentation, it's clear that one can traverse the block
hierarchy upwards into the global block, and that one can iterate a gbd.Block
to reveal its symbols.
However reality suggest that there is not one *truly global* block, but a
global block for each compilation unit, effectively reducing "global" to
"static".
As a result of this, iterating the block hierarchy and printing each block's
variables cannot yield "all global variables". That is unless the binary is
formed from a single CU, of course.

Attached to this bug report is a minimal working example demonstrating this
behaviour.
The global variable "foo_header_char" is declared as 'extern' within foo.hpp.
The variable's definition is in foo.cc.
main.cc and foo.cc include the header and thus have access to the variable.
When the inferior is stopped inside the main-CU, 'foo_header_char' is
completely invisible, whereas it can be seen from inside the foo-CU.
If the variable's definition is done within the main-CU, it's invisible from
the foo-CU, as one would expect.


| steps to reproduce
+--------------------
tar -vxzf mwe_global.tar.gz
./compile
gdb mwe_global
source get-vars.py
break main
run
get-vars
step 2 (the inferior now is inside foo.cc's foo())
get-vars
step 2 (the inferior is now back in main())
get-vars


| produced output
+--------------------
$ gdb mwe_global --quiet
Reading symbols from mwe_global...done.
(gdb) source get_vars.py
(gdb) break main
Breakpoint 1 at 0x40056e: file main.cc, line 20.
(gdb) run
Starting program:
/home/unrest/docs/studium/Bachelorarbeit/cppgdb/mwe_global_scope_problem/mwe_global

Breakpoint 1, main () at main.cc:20
20              foo_header_char++;
(gdb) get-vars
(gdb) step 2
foo () at foo.cc:7
7               foo_header_char='@';
(gdb) get-vars
"foo_header_char",0x6009d9,"char",1
(gdb) step
8       }
(gdb) get-vars
"foo_header_char",0x6009d9,"char",1
(gdb) step
main () at main.cc:22
22              for (unsigned i=0; i<42; i++) {
(gdb) get-vars
"i",0x7fffffffe22c,"unsigned int",4

---

I compiled the MWE with g++ 6.1.1 20160501 and tested with GDB 7.11

-- 
You are receiving this mail because:
You are on the CC list for the bug.