I added a bitset type of virable to watch When debugging but the output infomation is insufficient and not intuitive.
For example,somthing like this:
{
...
std::bitset<26> dictionary;
...
}
F8 start debugging it and add 'dictionary' to watch, the output is:
-dictionary
-<std::_Base_Bitset<1u>>
-M_w=8736 (when changed to binary,it shows: 10001000100000)
-<No data fields>
It can not show the detailed contents of bitset for me to debug it.Then let's look at the result in visual studio 2008 debugger window:
| watch1 | | | value | | [26]{0,0,1,1,0,0,1,1,0,0,1,1,0,0,1,1,0.......} | | false | | false | | true | | true | | false | | ... |
| | type | | std::bitset<26> | | bool | | bool | | bool | | bool | | bool | | ... |
|
|
It's intuitive and offers enough useful information for developers. Eclipse+cdt and codelite also have the same result with codeblocks. Then i installed wingdb (an application to use mingw/cygwin+gdb in visual studio) and tried visual studio again.This time it shows the same result with codeblocks. Is it gdb's fault?
I selected visual studio 2005/2008 compiler and cdb debugger in codeblocks to debug again,it still can not shows detailed contents.The result is:
dictionary = class std::bitset<26>
---_Array =[1]0x40f227
Now i am confused and not sure what is the culprit. Why codeblocks fails to show the detailed contents of bitset as visual studio does? ???
Quote from: hooluupog on March 31, 2012, 06:43:03 AM
It's intuitive and offers enough useful information for developers. Eclipse+cdt and codelite also have the same result with codeblocks. Then i installed wingdb (an application to use mingw/cygwin+gdb in visual studio) and tried visual studio again.This time it shows the same result with codeblocks. Is it gdb's fault?
You can run your debug session in the command line, and see whether gdb print right result.
Here, it works OK, mingw4.6.3 + gdb cvs + codeblocks debugger branch nightly build.
The sample code:
// bitset::test
#include <iostream>
#include <string>
#include <bitset>
using namespace std;
int main ()
{
bitset<5> mybits (string("01011"));
cout << "mybits contains:\n";
cout << boolalpha;
for (size_t i=0; i<mybits.size(); ++i)
cout << mybits.test(i) << endl;
return 0;
}
The result screen shot:
(http://i683.photobucket.com/albums/vv194/ollydbg_cb/2012-03-31145115.png)
Quote
I selected visual studio 2005/2008 compiler and cdb debugger in codeblocks to debug again,it still can not shows detailed contents.The result is:
dictionary = class std::bitset<26>
---_Array =[1]0x40f227
Now i am confused and not sure what is the culprit. Why codeblocks fails to show the detailed contents of bitset as visual studio does? ???
Code::blocks' debugger have better support on gdb than cdb, can you help to elaborate?
Quote from: ollydbg on March 31, 2012, 08:52:49 AM
Here, it works OK, mingw4.6.3 + gdb cvs + codeblocks debugger branch nightly build.
It does not work with default installation.
I guess you need pretty printers to make it work.
Quote from: ollydbg on March 31, 2012, 08:52:49 AM
The result screen shot:
(http://i683.photobucket.com/albums/vv194/ollydbg_cb/2012-03-31145115.png)
Hi,
it is strange. I am using 7790 debugger branch with latest version tdm-gcc. Here is my result:
click to zoom it.
hooluupog: Works for me, like in the screenshot from Ollydbg, but you need to install python enabled gdb and you need to have python pretty printers for gdb for the stl library.
See here: http://sourceware.org/gdb/wiki/STLSupport
p.s. Keep in mind that attaching images to the forum is not a really good idea, because the space is limited an when it is exhausted the admins delete attachments at random. A better idea is to paste as text (right click in the command line and mark) or use an image sharing service!
Quote from: oBFusCATed on March 31, 2012, 10:15:41 AM
hooluupog: Works for me, like in the screenshot from Ollydbg, but you need to install python enabled gdb and you need to have python pretty printers for gdb for the stl library.
See here: http://sourceware.org/gdb/wiki/STLSupport
p.s. Keep in mind that attaching images to the forum is not a really good idea, because the space is limited an when it is exhausted the admins delete attachments at random. A better idea is to paste as text (right click in the command line and mark) or use an image sharing service!
Thanks for clearing up my doubt. :) IMHO, it will be good to integrate pretty printers with codeblocks.
Why? Newer gccs have them integrated in the libstdc++ lib, although I don't know what is shipped with Mingw, but this is not our job, it is the job of Mingw developers to ship the printers with they stdc++ lib.
Quote from: oBFusCATed on March 31, 2012, 11:49:24 AM
Why? Newer gccs have them integrated in the libstdc++ lib, although I don't know what is shipped with Mingw, but this is not our job, it is the job of Mingw developers to ship the printers with they stdc++ lib.
I see both PCX and TDM's GCC 4.6.x have shipped python pretty printers for libstdc++. They are under
MinGWFolder/share/gcc4.6.x/python/libstdcxx
You are right ;D. Tdm-gcc has already had pretty-printers in it. Use gdb-python27.exe instead of gdb.exe in codeblocks debugger settings and it finally recognized the stl containers correctly.
how is this pretty printing story on linux ?
just did simple test on debugger branch on linux ==> no pretty printing,
bits --> std:;_Base_bitset , which can further expand to [1] ==> which says : no data fields.
EDIT : didn't we source in the past on linux some pretty printing scrips ? do we still do that ?
If you have python enabled gdb and gcc>=4.5 you should have the printers enabled by default.
Currently we have an option to disable the printer scripts in C::B, which should be enabled, so C::B would use normal print commands.
The old scripts are used, but they are no good enough, the pretty printers are way better, but parsing std::vector<std::vector>> is
not working correctly, nor any other nested structure. Unfortunately this could not be made to work.
GNU gdb (GDB) SUSE (7.4.50.20120120-78.3)
gcc (SUSE Linux) 4.6.2
so those should meet the criteria.
Maybe it is disabled in CB ? Where could it be disabled, at first glance I don't find anything.
There are the docs: http://sourceware.org/gdb/onlinedocs/gdb/Pretty-Printing.html
Have you tried the command line gdb, to see if it works there?
running 'info pretty-printer' in CB
info pretty-printer
objfile /usr/lib64/libstdc++.so.6 pretty-printers:
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::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::__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::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
when running gdb from shell (no application specified) : info pretty-printer ==> nothing
some more feedback
#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 :
> print bits
$1 = std::bitset = {
[0] = 1,
[5] = 1
}
> print /r bits
$2 = {
<std::_Base_bitset<1ul>> = {
_M_w = 33
}, <No data fields>}
so it seems CB is using the old "raw" style ...
Quote from: killerbot on April 02, 2012, 01:21:20 PM
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.
some more issues :
#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 :
> 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 ??? ) :
Couldn't find method std::map<std::basic_string .............................. and so on ....................................
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
QuoteAdd 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
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. :)
where's this option
QuoteAnd 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 ....
@killerbot, see screen shot:
(http://i683.photobucket.com/albums/vv194/ollydbg_cb/2012-04-02202656.png)
Quote from: oBFusCATed on April 02, 2012, 01:41:14 PM
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.
http://sourceware.org/gdb/current/onlinedocs/gdb/Auto_002dloading.html#Auto_002dloading
Quote from: oBFusCATed on April 02, 2012, 04:58:46 PM
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:
Quote
[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.
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).