The output infomation of std:bitset is insufficient when debugging.

[killerbot]

some more feedback

Code Select Expand


#include <iostream>
#include <bitset>


int main()
{
    std::bitset<10> bits;
    bits[0] = true;
    bits[5].flip();
    std::cout << bits << std::endl;
    return 0;
}


within CB sending commands to gdb :

Code Select Expand


> print bits
$1 = std::bitset = {
  [0] = 1,
  [5] = 1
}

Code Select Expand


> print /r bits
$2 = {
  <std::_Base_bitset<1ul>> = {
    _M_w = 33
  }, <No data fields>}

so it seems CB is using the old "raw" style ...

[oBFusCATed]

when running gdb from shell (no application specified) : info pretty-printer  ==> nothing

This is expected as gdb  searches for pretty printers next to the binaries/shared objects.

[killerbot]

some more issues :

Code Select Expand


#include <iostream>
#include <bitset>
#include <map>
#include <string>


int main()
{
   std::bitset<10> bits;
   bits[0] = true;
   bits[5].flip();


   std::map<std::string, int> foo;
   foo["hello"] = 3;
   foo["world"] = 5;


   std::cout << bits << std::endl;
   return 0;
}


in CB send gdb command manually :

Code Select Expand


> print foo
$1 = std::map with 2 elements = {
 ["hello"] = 3,
 ["world"] = 5
}

But when 'added as watch' we get something like this (even worse then a raw print, well maybe raw print and failure in parsing ??? ) :

Code Select Expand


Couldn't find method std::map<std::basic_string .............................. and so on ....................................


[ollydbg]

Under Windows, I need to manually load the python pretty printer script for libstdc++. So I have some custom.gdb file to run after gdb started under C::B. I believe gdb have no idea to automatically load the python scripts (How does gdb know the path you install libstdc++'s scripts?).

As under Linux, I see:
http://sourceware.org/gdb/wiki/STLSupport

Add the following to your ~/.gdbinit. The path needs to match where the python module above was checked-out. So if checked out to: /home/maude/gdb_printers/, the path would be as written in the example:

    python
    import sys
    sys.path.insert(0, '/home/maude/gdb_printers/python')
    from libstdcxx.v6.printers import register_libstdcxx_printers
    register_libstdcxx_printers (None)
    end

[oBFusCATed]

Please post the full log from the session.

Also as far as I can see we don't use /r anywhere in our plugin.
Full log again will reveal what is happening.
And make sure you've disabled the option for the old scripts!

ollydbg: on linux gdb is smart and loads it by correctly if the printers are next to the bin/so file. Read the gdb docs for details, I'm sure they've documented it there.

[killerbot]

where's this option

And make sure you've disabled the option for the old scripts!

??


EDIT : FOUND IT : Enable watch scripts ===> disabled it, CB is now nicely showing the stuff :-)

..... it WORKS ....

[ollydbg]

@killerbot, see screen shot:

[ollydbg]

ollydbg: on linux gdb is smart and loads it by correctly if the printers are next to the bin/so file. Read the gdb docs for details, I'm sure they've documented it there.

@OBF
I have scan the gdb document and still can't find about how to automatically load stdc++'s python script, can you show me where can I find it.

BTW: I have tested under windows, that the stdc++ python script does not automatically loaded by gdb.

[oBFusCATed]

http://sourceware.org/gdb/current/onlinedocs/gdb/Auto_002dloading.html#Auto_002dloading

[ollydbg]

http://sourceware.org/gdb/current/onlinedocs/gdb/Auto_002dloading.html#Auto_002dloading

Thanks. It looks like gdb will automatically load a python script which name matches a shared library/object file.

I just tried under c::b's debugger plugin's command line:

[debug]> info auto-load-scripts
[debug]No auto-load scripts.

Maybe, I'm using a static libstdc++ mingw(PCX's 4.6.3), so I don't have such dll for libstdc++. Not tried other mingw package.

[oBFusCATed]

ollydbg:
You have to talk to the people porting your gdb/gcc to windows. I think they have to do it properly in order to get support for it.
The printers can be embedded in the debug info and I guess this is how it is done in linux (just a guess of course).