How to load C++ pretty-printers

How to load C++ pretty-printers

[Eli Zaretskii]

I have a question regarding loading the C++ pretty-printers provided
by GCC.  This might be specific to MS-Windows, not sure.

So I have the C++ pretty-printers installed in
d:/usr/share/gcc-7.3.0/python/libstdcxx/v6.  I start GDB to debug
itself.  The "info pretty-printer" command says:

  (top-gdb) info pretty-printer
  global pretty-printers:
    builtin
      mpx_bound128
    objfile D:\gnu\gdb-8.2\gdb\gdb.exe pretty-printers:
    type_lookup_function

This doesn't seem to mention the GCC-provided C++ pretty-printers.  So
I start the inferior GDB running:

  (top-gdb) start --config

After that, "info pretty-printers" still shows no C++ pretty-printers.
OK, me thinks, this could be because libstdc++ is statically linked
into GDB, so I load the pretty-printers by hand:

  (top-gdb) source d:/usr/share/gcc-7.3.0/python/libstdcxx/v6/printers.py

But "info pretty-printers" command still doesn't show the C++
pretty-printers I just loaded.

What am I missing here?  How does one load and enable the C++
pretty-printers provided with GCC?  Do I need some magic in my
~/.gdbinit file to do that?

TIA

Re: How to load C++ pretty-printers

[asmwarrior]

On Sat Mar 16 2019 16:30:19 GMT+0800, Eli Zaretskii wrote:
> I have a question regarding loading the C++ pretty-printers provided
> by GCC.  This might be specific to MS-Windows, not sure.
> 
> So I have the C++ pretty-printers installed in
> d:/usr/share/gcc-7.3.0/python/libstdcxx/v6.  I start GDB to debug
> itself.  The "info pretty-printer" command says:
> 
>   (top-gdb) info pretty-printer
>   global pretty-printers:
>     builtin
>       mpx_bound128
>     objfile D:\gnu\gdb-8.2\gdb\gdb.exe pretty-printers:
>     type_lookup_function
> 
> This doesn't seem to mention the GCC-provided C++ pretty-printers.  So
> I start the inferior GDB running:
> 
>   (top-gdb) start --config
> 
> After that, "info pretty-printers" still shows no C++ pretty-printers.
> OK, me thinks, this could be because libstdc++ is statically linked
> into GDB, so I load the pretty-printers by hand:
> 
>   (top-gdb) source d:/usr/share/gcc-7.3.0/python/libstdcxx/v6/printers.py

Under My Windows 7 system, I'm using such commands(I put them in a my.gdb script file) to load and register the pretty printers.
I put the libstdcxx folder in the same folder as the my.gdb file.
 

set auto-load safe-path $debugdir;$datadir/auto-load
python
import sys
sys.path.insert(0, '')
from libstdcxx.v6.printers import register_libstdcxx_printers
# load other pretty printers
end


And here is the result of info pretty-printer command

global pretty-printers:
  .*
    bound
  builtin
    mpx_bound128
  libstdc++-v6
    __gnu_cxx::_Slist_iterator
    __gnu_cxx::__7::_Slist_iterator
    __gnu_cxx::__7::__normal_iterator
    __gnu_cxx::__7::slist
    __gnu_cxx::__normal_iterator
    __gnu_cxx::slist
    __gnu_debug::_Safe_iterator
    std::_Deque_const_iterator
    std::_Deque_iterator
    std::_List_const_iterator
    std::_List_iterator
    std::_Rb_tree_const_iterator
    std::_Rb_tree_iterator
    std::__7::_Deque_const_iterator
    std::__7::_Deque_iterator
    std::__7::_List_const_iterator
    std::__7::_List_iterator
    std::__7::_Rb_tree_const_iterator
    std::__7::_Rb_tree_iterator
    std::__7::__cxx11::basic_string
    std::__7::basic_string
    std::__7::bitset
    std::__7::deque
    std::__7::forward_list
    std::__7::list
    std::__7::map
    std::__7::multimap
    std::__7::multiset
    std::__7::priority_queue
    std::__7::queue
    std::__7::set
    std::__7::shared_ptr
    std::__7::stack
    std::__7::tuple
    std::__7::unique_ptr
    std::__7::unordered_map
    std::__7::unordered_multimap
    std::__7::unordered_multiset
    std::__7::unordered_set
    std::__7::vector
    std::__7::weak_ptr
    std::__cxx11::basic_string
    std::__cxx1998::_Deque_const_iterator
    std::__cxx1998::_Deque_iterator
    std::__cxx1998::_List_const_iterator
    std::__cxx1998::_List_iterator
    std::__cxx1998::__7::_Deque_const_iterator
    std::__cxx1998::__7::_Deque_iterator
    std::__cxx1998::__7::_List_const_iterator
    std::__cxx1998::__7::_List_iterator
    std::__cxx1998::__7::bitset
    std::__cxx1998::__7::deque
    std::__cxx1998::__7::forward_list
    std::__cxx1998::__7::list
    std::__cxx1998::__7::map
    std::__cxx1998::__7::multimap
    std::__cxx1998::__7::multiset
    std::__cxx1998::__7::set
    std::__cxx1998::__7::unordered_map
    std::__cxx1998::__7::unordered_multimap
    std::__cxx1998::__7::unordered_multiset
    std::__cxx1998::__7::unordered_set
    std::__cxx1998::__7::vector
    std::__cxx1998::bitset
    std::__cxx1998::deque
    std::__cxx1998::forward_list
    std::__cxx1998::list
    std::__cxx1998::map
    std::__cxx1998::multimap
    std::__cxx1998::multiset
    std::__cxx1998::set
    std::__cxx1998::unordered_map
    std::__cxx1998::unordered_multimap
    std::__cxx1998::unordered_multiset
    std::__cxx1998::unordered_set
    std::__cxx1998::vector
    std::__debug::bitset
    std::__debug::deque
    std::__debug::forward_list
    std::__debug::list
    std::__debug::map
    std::__debug::multimap
    std::__debug::multiset
    std::__debug::priority_queue
    std::__debug::queue
    std::__debug::set
    std::__debug::stack
    std::__debug::unique_ptr
    std::__debug::unordered_map
    std::__debug::unordered_multimap
    std::__debug::unordered_multiset
    std::__debug::unordered_set
    std::__debug::vector
    std::__norm::_Deque_const_iterator
    std::__norm::_Deque_iterator
    std::__norm::_List_const_iterator
    std::__norm::_List_iterator
    std::basic_string
    std::bitset
    std::deque
    std::experimental::fundamentals_v1::__7::any
    std::experimental::fundamentals_v1::__7::basic_string_view
    std::experimental::fundamentals_v1::__7::optional
    std::experimental::fundamentals_v1::any
    std::experimental::fundamentals_v1::basic_string_view
    std::experimental::fundamentals_v1::optional
    std::forward_list
    std::list
    std::map
    std::multimap
    std::multiset
    std::priority_queue
    std::queue
    std::set
    std::shared_ptr
    std::stack
    std::tr1::__7::shared_ptr
    std::tr1::__7::unordered_map
    std::tr1::__7::unordered_multimap
    std::tr1::__7::unordered_multiset
    std::tr1::__7::unordered_set
    std::tr1::__7::weak_ptr
    std::tr1::shared_ptr
    std::tr1::unordered_map
    std::tr1::unordered_multimap
    std::tr1::unordered_multiset
    std::tr1::unordered_set
    std::tr1::weak_ptr
    std::tuple
    std::unique_ptr
    std::unordered_map
    std::unordered_multimap
    std::unordered_multiset
    std::unordered_set
    std::vector
    std::weak_ptr
  lookup_function

If I remember correctly, there used to be a function call register_libstdcxx_printers() like below:

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

But later, the "register_libstdcxx_printers (None)" is not needed any more.

Asmwarrior

Re: How to load C++ pretty-printers

[Eli Zaretskii]

> From: asmwarrior <asmwarrior@gmail.com>
> Date: Sat, 16 Mar 2019 20:41:13 +0800
> 
> Under My Windows 7 system, I'm using such commands(I put them in a my.gdb script file) to load and register the pretty printers.
> I put the libstdcxx folder in the same folder as the my.gdb file.
>  
> 
> set auto-load safe-path $debugdir;$datadir/auto-load
> python
> import sys
> sys.path.insert(0, '')
> from libstdcxx.v6.printers import register_libstdcxx_printers
> # load other pretty printers
> end

Thanks, but I don't think I understand which part(s) of this are
necessary in my case.  E.g., is the "set auto-load" command
needed/relevant?  And what is the my.gdb file, I don't think I have
such a file on my system.  The pretty-printers that came with GCC are
installed where the GCC installation puts them, and I'd prefer not to
change that if possible.

Also, which of the commands you've shown actually loads the
pretty-printers from their file?

Thanks again for your response.

Re: How to load C++ pretty-printers

[asmwarrior]

On Sat Mar 16 2019 20:58:22 GMT+0800, Eli Zaretskii wrote:
>> From: asmwarrior <asmwarrior@gmail.com>
>> Date: Sat, 16 Mar 2019 20:41:13 +0800
>>
>> Under My Windows 7 system, I'm using such commands(I put them in a my.gdb script file) to load and register the pretty printers.
>> I put the libstdcxx folder in the same folder as the my.gdb file.
>>  

The file "my.gdb" is a simple text script file, which contains the lines(commands) below

>>
>> set auto-load safe-path $debugdir;$datadir/auto-load
>> python
>> import sys
>> sys.path.insert(0, '')
>> from libstdcxx.v6.printers import register_libstdcxx_printers
>> # load other pretty printers
>> end


> Thanks, but I don't think I understand which part(s) of this are
> necessary in my case.  E.g., is the "set auto-load" command
> needed/relevant?  

Currently, I don't have an idea about whether "set auto-load" command is relevant or not. I use this script for several years.
I think for your original question, you need one line:

from libstdcxx.v6.printers import register_libstdcxx_printers

But you should let GDB know where the "libstdcxx" folder locates.

> Also, which of the commands you've shown actually loads the
> pretty-printers from their file?

I just type the command below:
source d:/path/to/my.gdb

Asmwarrior

Re: How to load C++ pretty-printers

[Simon Marchi]

On 2019-03-16 08:58, Eli Zaretskii wrote:
>> From: asmwarrior <asmwarrior@gmail.com>
>> Date: Sat, 16 Mar 2019 20:41:13 +0800
>> 
>> Under My Windows 7 system, I'm using such commands(I put them in a 
>> my.gdb script file) to load and register the pretty printers.
>> I put the libstdcxx folder in the same folder as the my.gdb file.
>> 
>> 
>> set auto-load safe-path $debugdir;$datadir/auto-load
>> python
>> import sys
>> sys.path.insert(0, '')
>> from libstdcxx.v6.printers import register_libstdcxx_printers
>> # load other pretty printers
>> end
> 
> Thanks, but I don't think I understand which part(s) of this are
> necessary in my case.  E.g., is the "set auto-load" command
> needed/relevant?  And what is the my.gdb file, I don't think I have
> such a file on my system.  The pretty-printers that came with GCC are
> installed where the GCC installation puts them, and I'd prefer not to
> change that if possible.
> 
> Also, which of the commands you've shown actually loads the
> pretty-printers from their file?
> 
> Thanks again for your response.

If it can help, I have something similar to that in my .gdbinit (whereas 
asmwarrior has put the same content in a separate file, my.gdb, which 
they then source by hand).

When libstdc++ is linked dynamically with a program and you debug that 
program, GDB will "auto-load" the file corresponding to the libstdc++ 
shared library.  In my case, it's at 
"/usr/share/gdb/auto-load/usr/lib/libstdc++.so.6.0.25-gdb.py".  This 
file tries to find where the GCC-provided libstdc++ pretty printers are 
installed, and adds this path to the Python import path.  It then calls 
register_libstdcxx_printers, a function provided by the libstdc++ pretty 
printers.

When libstdc++ is linked statically, the auto-load does not happen, as 
you mentioned.  So the idea here is to replicate what the auto-load 
script does, but by hand.

In my case, I have these lines to adjust the Python import path to add 
GCC's pretty printers directory:

   python import sys
   python sys.path.insert(0, '/usr/share/gcc-8.2.1/python')

And then I manually trigger the GDB auto-load script, that would 
normally be sourced automatically when loading the libstdc++ shared lib:

   source /usr/share/gdb/auto-load/usr/lib/libstdc++.so.6.0.25-gdb.py

The "set auto-load safe-path" line is to define it is safe to auto-load 
things from.  If you are missing something, you should know quickly 
enough, as GDB will print you a warning, saying it didn't auto-load X, 
because X is not in a safe path (as well as information about how to 
adjust it).

Hope this helps,

Simon

Re: How to load C++ pretty-printers

[Eli Zaretskii]

> Date: Sat, 16 Mar 2019 10:25:43 -0400
> From: Simon Marchi <simon.marchi@polymtl.ca>
> Cc: asmwarrior <asmwarrior@gmail.com>, gdb@sourceware.org
> 
> If it can help, I have something similar to that in my .gdbinit (whereas 
> asmwarrior has put the same content in a separate file, my.gdb, which 
> they then source by hand).
> 
> When libstdc++ is linked dynamically with a program and you debug that 
> program, GDB will "auto-load" the file corresponding to the libstdc++ 
> shared library.  In my case, it's at 
> "/usr/share/gdb/auto-load/usr/lib/libstdc++.so.6.0.25-gdb.py".  This 
> file tries to find where the GCC-provided libstdc++ pretty printers are 
> installed, and adds this path to the Python import path.  It then calls 
> register_libstdcxx_printers, a function provided by the libstdc++ pretty 
> printers.
> 
> When libstdc++ is linked statically, the auto-load does not happen, as 
> you mentioned.  So the idea here is to replicate what the auto-load 
> script does, but by hand.
> 
> In my case, I have these lines to adjust the Python import path to add 
> GCC's pretty printers directory:
> 
>    python import sys
>    python sys.path.insert(0, '/usr/share/gcc-8.2.1/python')
> 
> And then I manually trigger the GDB auto-load script, that would 
> normally be sourced automatically when loading the libstdc++ shared lib:
> 
>    source /usr/share/gdb/auto-load/usr/lib/libstdc++.so.6.0.25-gdb.py

Ah, thanks, this script was the missing piece.  In the MinGW GCC
distribution it installs into lib/gcc/mingw32/VERSION/, where VERSION
is the GCC version.  The script is also named differently, due to the
MS-Windows .dll.a import library.

So, for the record, I now have this in my ~/.gdbinit

  python import sys
  python sys.path.insert(0, 'd:/usr/share/gcc-7.3.0/python')
  source d:/usr/lib/gcc/mingw32/7.3.0/libstdc++.dll.a-gdb.py

(The last line both imports the function register_libstdcxx_printers,
and calls that function.)

> The "set auto-load safe-path" line is to define it is safe to auto-load 
> things from.  If you are missing something, you should know quickly 
> enough, as GDB will print you a warning, saying it didn't auto-load X, 
> because X is not in a safe path (as well as information about how to 
> adjust it).

Yes, I already have auto-load safe-path set to not get in the way.

Thanks.

Re: How to load C++ pretty-printers

[asmwarrior]

On Sun Mar 17 2019 00:00:29 GMT+0800, Eli Zaretskii wrote:
> So, for the record, I now have this in my ~/.gdbinit
> 
>   python import sys
>   python sys.path.insert(0, 'd:/usr/share/gcc-7.3.0/python')
>   source d:/usr/lib/gcc/mingw32/7.3.0/libstdc++.dll.a-gdb.py
> 
> (The last line both imports the function register_libstdcxx_printers,
> and calls that function.)

Thanks Eli and Simon.

I think I have followed this wiki page: https://sourceware.org/gdb/wiki/STLSupport
And I just the svn command to check-out the latest Python libstdc++ printers in GCC trunk.
So, that page should be updated, at least we can teach people how to use the python printer bundled with their GCC release.

Asmwarrior

Re: How to load C++ pretty-printers

[Joel Brobecker]

Hello Asmwarrior,

On Sun, Mar 17, 2019 at 09:47:35AM +0800, asmwarrior wrote:
> On Sun Mar 17 2019 00:00:29 GMT+0800, Eli Zaretskii wrote:
> > So, for the record, I now have this in my ~/.gdbinit
> > 
> >   python import sys
> >   python sys.path.insert(0, 'd:/usr/share/gcc-7.3.0/python')
> >   source d:/usr/lib/gcc/mingw32/7.3.0/libstdc++.dll.a-gdb.py
> > 
> > (The last line both imports the function register_libstdcxx_printers,
> > and calls that function.)
> 
> Thanks Eli and Simon.
> 
> I think I have followed this wiki page: https://sourceware.org/gdb/wiki/STLSupport
> And I just the svn command to check-out the latest Python libstdc++
> printers in GCC trunk.  So, that page should be updated, at least we
> can teach people how to use the python printer bundled with their GCC
> release.

It is a fair comment. Would you volunteer to help us update it?

-- 
Joel

Re: How to load C++ pretty-printers

[Philippe Waroquiers]

On Sun, 2019-03-17 at 07:03 -0400, Joel Brobecker wrote:
> Hello Asmwarrior,
> 
> On Sun, Mar 17, 2019 at 09:47:35AM +0800, asmwarrior wrote:
> > On Sun Mar 17 2019 00:00:29 GMT+0800, Eli Zaretskii wrote:
> > > So, for the record, I now have this in my ~/.gdbinit
> > > 
> > >   python import sys
> > >   python sys.path.insert(0, 'd:/usr/share/gcc-7.3.0/python')
> > >   source d:/usr/lib/gcc/mingw32/7.3.0/libstdc++.dll.a-gdb.py
> > > 
> > > (The last line both imports the function register_libstdcxx_printers,
> > > and calls that function.)
> > 
> > Thanks Eli and Simon.
> > 
> > I think I have followed this wiki page: https://sourceware.org/gdb/wiki/STLSupport
> > And I just the svn command to check-out the latest Python libstdc++
> > printers in GCC trunk.  So, that page should be updated, at least we
> > can teach people how to use the python printer bundled with their GCC
> > release.
> 
> It is a fair comment. Would you volunteer to help us update it?
Note that even with pretty printers working, c++ debugging stays a mystery
for me (probably highly linked to my poor knowledge of C++):

E.g.  p current_program_space->added_solibs
 pretty printing works and gives:
      $11 = std::vector of length 13, capacity 16 = {0x56275a765a60,  ...

But then:
    p current_program_space->added_solibs[0]
    One of the arguments you tried to pass to operator[] could not be converted to what
    the function wants.
(why is then GDB not telling me what the function wants ?).
I am finally doing
   p (*(struct so_list*)0x56275a765a60)

But that all looks like a 'backward' user experience:
  I have to explain to GDB what to do, instead of GDB just working,
  or at least GDB explaining me more clearly what I am doing wrong.

Philippe

Re: How to load C++ pretty-printers

[Eli Zaretskii]

> From: Philippe Waroquiers <philippe.waroquiers@skynet.be>
> Cc: Eli Zaretskii <eliz@gnu.org>, Simon Marchi <simon.marchi@polymtl.ca>, 
> 	gdb@sourceware.org
> Date: Sun, 17 Mar 2019 13:39:52 +0100
> 
> But then:
>     p current_program_space->added_solibs[0]
>     One of the arguments you tried to pass to operator[] could not be converted to what
>     the function wants.
> (why is then GDB not telling me what the function wants ?).
> I am finally doing
>    p (*(struct so_list*)0x56275a765a60)
> 
> But that all looks like a 'backward' user experience:

Is that a problem with GDB or with the pretty-printer?  If the latter,
it might be worth telling this to the GCC folks.

Thanks.

Re: How to load C++ pretty-printers

[Philippe Waroquiers]

On Sun, 2019-03-17 at 17:30 +0200, Eli Zaretskii wrote:
> > From: Philippe Waroquiers <philippe.waroquiers@skynet.be>
> > Cc: Eli Zaretskii <eliz@gnu.org>, Simon Marchi <simon.marchi@polymtl.ca>, 
> > 	gdb@sourceware.org
> > Date: Sun, 17 Mar 2019 13:39:52 +0100
> > 
> > But then:
> >     p current_program_space->added_solibs[0]
> >     One of the arguments you tried to pass to operator[] could not be converted to what
> >     the function wants.
> > (why is then GDB not telling me what the function wants ?).
> > I am finally doing
> >    p (*(struct so_list*)0x56275a765a60)
> > 
> > But that all looks like a 'backward' user experience:
> 
> Is that a problem with GDB or with the pretty-printer?  If the latter,
> it might be worth telling this to the GCC folks.
I think it is a GDB problem: same behaviour with pretty printers
disabled:

(top-gdb) p current_program_space->added_solibs
$4 = {<std::_Vector_base<so_list*, std::allocator<so_list*> >> = {
    _M_impl = {<std::allocator<so_list*>> = {<__gnu_cxx::new_allocator<so_list*>> = {<No
data fields>}, <No data fields>}, _M_start = 0x563c90cb1140, 
      _M_finish = 0x563c90cb1190, 
      _M_end_of_storage = 0x563c90cb11c0}}, <No data fields>}
(top-gdb) p current_program_space->added_solibs[0]
One of the arguments you tried to pass to operator[] could not be converted to what the
function wants.
(top-gdb) 

Another strange thing in this area: with pretty printers disabled,
 doing
  ptype current_program_space->added_solibs
gives first a python error:
Python Exception <class 'gdb.error'> No type named so_list*.: 
type = class std::vector<so_list*, std::allocator<so_list*> > 
    [with _Tp = so_list *, _Alloc = std::allocator<so_list*>] 

while ptype so_list*
tells it is a known type:
(top-gdb) ptype so_list*
type = struct so_list {
    so_list *next;
    lm_info_base *lm_info;
    char so_original_name[512];
    char so_name[512];
    program_space *pspace;
    bfd *abfd;
    char symbols_loaded;
    objfile *objfile;
    target_section *sections;
    target_section *sections_end;
    CORE_ADDR addr_low;
    CORE_ADDR addr_high;
} *

That also looks like a GDB problem
(maybe ptype is missing the logic to consider so_list as
a struct ?).

Maybe there is a link between the 2 problems ?

Philippe