[Bug c++/18623] MI -var-update problems with vector of vectors

["rw at firstpr dot com.au" <sourceware-bugzilla at sourceware dot org>]

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

--- Comment #2 from Robin Whittle <rw at firstpr dot com.au> ---
This message concerns the configuration items for building this particular gdb
executable, and the printers.py arrangements. "show configuration" returns
(spaces edited and/or removed by this Bugzilla system - I wish programs would
not steal my spaces!):

==

~"This GDB was configured as follows:\n configure
--host=x86_64-unknown-linux-gnu --target=x86_64-unknown-linux-gnu\n"

~" --with-auto-load-dir=$debugdir:$datadir/auto-load\n
--with-auto-load-safe-path=$debugdir:$datadir/auto-load\n"
~" --with-expat\n"
~" --with-gdb-datadir=/usr/local/share/gdb (relocatable)\n"
~" --with-jit-reader-dir=/usr/local/lib/gdb (relocatable)\n"
~" --without-libunwind-ia64\n"
~" --without-lzma\n"
~" --with-python=/usr\n"
~" --without-guile\n"
~" --with-separate-debug-dir=/usr/local/lib/debug (relocatable)\n"
~" --without-babeltrace\n"
~"\n(\"Relocatable\" means the directory can be moved with the GDB
installation\ntree, and GDB will still find it.)\n"

==

I was not able to use .configure so as to build a gdb which returns
"--with-python=/usr/bin", which is where the python executables are. Googling
indicates this is the most common arrangement. I tried no equals sign and
"=yes", "=/usr/bin/", "--with-python=/usr/bin/python" and
"=/usr/bin/python2.7".

There are several python executables in /usr/bin and the python symlink there
points to python2.7.

As far as I know, everything is correct with printers.py, though when I attach,
in a later message, an HTML file with instructions on reproducing the problem,
you will see gdb at startup complaining about some python things. I have not
tried to understand this, and I suspect it is nothing to worry about, since gdb
is perfectly able to navigate the structure of this vector of vectors (using
the CLI command "print"), displaying all the leaf node contents, and can do the
same for lists, maps and a struct of three elements, each with an int, a vector
of strings and a map of string-float pairs.

I have just attached the printers.py I am using. It is a 41,551 printers.py
which is identical to the one which applies to this version of libstdc++:

https://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch/libstdc++-v3/python/libstdcxx/v6/printers.py

To ensure the command line instance of gdb (with which I am reproducing the
problems) is operating in the same way as the one Codelite runs, I run it while
Codelite is running its instance, and use the same configuration arrangements.
At startup, Codelite copies a printers.py which the Codelite installer
supplies:

/usr/share/codelite/gdb_printers/libstdcxx/v6/printers.py

to the the user directory:

/home/robin/.codelite/gdb_printers/libstdcxx/v6/printers.py

(I think this is a bad idea, since it frustrates a user who customizes this
file in this location.) Current release versions of Codelite use an earlier
printers.py, but the version I am using, as updated recently by Eran Ifran,
uses the 41,551 version which is appropriate for the libstdc++ 4.9 I am using.
(This would not suit all Codelite users - no particular printers.py will
necessarily suit all Codelite users, and one user might, in principle, require
different printers.py files if they are compiling with different versions of
libstdc++.)

Then Codelite generates an init file: /tmp/codelite_gdbinit.txt :

==

python
import sys
sys.path.insert(0, '/home/robin/.codelite/gdb_printers')

from libstdcxx.v6.printers import register_libstdcxx_printers
register_libstdcxx_printers (None)

from qt4 import register_qt4_printers
register_qt4_printers (None)

from wx import register_wx_printers
register_wx_printers (None)

from boost.printers import register_printer_gen
register_printer_gen(None)

end

==

At the start of a debugging session, Codelite runs gdb with the following
command line, which causes it to use this init file and therefore load the
41551 byte printers.py. If this file is not in my user directory, then gdb is
incapable of pretty printing even a vector of ints.

gdb --command="/tmp/codelite_gdbinit.txt" --tty=/dev/pts/6 --interpreter=mi
"./02_STL_PP"

For my command line testing, I use the same as this, without the tty option.

Codelite, when it first runs gdb, somehow causes a printers.pyc file to appear
in /home/robin/.codelite/gdb_printers/libstdcxx/v6/ I am not sure how relevant
that is, but gdb behaves the same way on the command line without this .pyc
file.

I am confident that all is well with printers.py - but perhaps someone has
insight as to how there might be a problem, such as python versionitis, which
explains the trouble I am reporting.

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