09ff83af3c
When using gdb.lookup_static_symbol I think that GDB should find static symbols (global symbol with static linkage) from the current object file ahead of static symbols from other object files. This means that if we have two source files f1.c and f2.c, and both files contains 'static int foo;', then when we are stopped in f1.c a call to 'gdb.lookup_static_symbol ("foo")' will find f1.c::foo, and if we are stopped in f2.c we would find 'f2.c::foo'. Given that gdb.lookup_static_symbol always returns a single symbol, but there can be multiple static symbols with the same name GDB is always making a choice about which symbols to return. I think that it makes sense for the choice GDB makes in this case to match what a user would get on the command line if they asked to 'print foo'. gdb/testsuite/ChangeLog: * gdb.python/py-symbol.c: Declare and call function from new py-symbol-2.c file. * gdb.python/py-symbol.exp: Compile both source files, and add new tests for gdb.lookup_static_symbol. * gdb.python/py-symbol-2.c: New file. gdb/doc/ChangeLog: * python.texi (Symbols In Python): Extend documentation for gdb.lookup_static_symbol. gdb/ChangeLog: * python/py-symbol.c (gdbpy_lookup_static_symbol): Lookup in static block of current object file first. Also fix typo in header comment. Change-Id: Ie55dbeb8806f35577b46015deecde27a0ca2ab64 |
||
---|---|---|
.. | ||
.gitignore | ||
a4rc.sed | ||
agentexpr.texi | ||
all-cfg.texi | ||
annotate.texinfo | ||
ChangeLog | ||
doxy-index.in | ||
Doxyfile-base.in | ||
Doxyfile-gdb-api.in | ||
Doxyfile-gdb-xref.in | ||
Doxyfile-gdbserver.in | ||
fdl.texi | ||
filter-for-doxygen | ||
filter-params.pl | ||
gdb.texinfo | ||
gpl.texi | ||
guile.texi | ||
lpsrc.sed | ||
Makefile.in | ||
psrc.sed | ||
python.texi | ||
refcard.tex | ||
stabs.texinfo | ||
stack_frame.eps | ||
stack_frame.pdf | ||
stack_frame.png | ||
stack_frame.svg | ||
stack_frame.txt |