Bug 20120 - multiple global blocks or broken global scope in GDB/Python
Summary: multiple global blocks or broken global scope in GDB/Python
Status: UNCONFIRMED
Alias: None
Product: gdb
Classification: Unclassified
Component: python (show other bugs)
Version: 7.11
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-05-19 14:53 UTC by Michael Lenz
Modified: 2023-12-16 14:20 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
MWE for this bug (1.74 KB, application/gzip)
2016-05-19 14:53 UTC, Michael Lenz
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Lenz 2016-05-19 14:53:02 UTC
Created attachment 9280 [details]
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
Comment 1 Hannes Domani 2023-12-16 14:20:29 UTC
(In reply to Michael Lenz from comment #0)
> 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 I understand it, that's exactly how it works.
So should this maybe be made clear in the docu?