Hi, yesterday, I have found a new way to support the gdb debugging in cb. Here is the brief introduction.
GDB with Python support (http://forums.codeblocks.org/index.php/topic,11301.msg86240.html#msg86240)
If we add another python wxStuff support, note that the original file is:
wxStuff support python script (http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/misc/gdb/print.py)
If you use wxWidgets 2.8.x version, you need to change this py file to some thin like:
class wxStringPrinter:
def __init__(self, val):
self.val = val
def to_string(self):
return self.val['m_pchData'].string()
#return '"' + self.val['m_impl']['_M_dataplus']['_M_p'].string() + '"'
def display_hint(self):
return 'string'
Note that, if you use 2.9.x version of wxWidgets, you can use the original py script. More details can be found in:
wxBlog: Pretty printing wxStuff in gdb (http://wxwidgets.blogspot.com/2009/01/pretty-printing-wxstuff-in-gdb.html)
To load both the stl_print and wx_print python scirpt, I create a my.gdb file, like:
python
import sys
sys.path.insert(0, 'C:\stl_python')
from libstdcxx.v6.printers import register_libstdcxx_printers
register_libstdcxx_printers (None)
execfile("f:/cb/wx_print.py")
end
Then, I suggest that you don't need the gdb.script to register several types, so, it is saft to comment them, because python scirpt works better!!!
Open the file like F:\cb\cb_ccbranch\src\output\share\CodeBlocks\scripts\gdb_types.script
Then, comment the file like:
// Registers new types with driver
function RegisterTypes(driver)
{
// signature:
// driver.RegisterType(type_name, regex, eval_func, parse_func);
// wxString
// driver.RegisterType(
// _T("wxString"),
// _T("[^[:alnum:]_]*wxString[^[:alnum:]_]*"),
// _T("Evaluate_wxString"),
// _T("Parse_wxString")
// );
// STL String
// driver.RegisterType(
// _T("STL String"),
// _T("[^[:alnum:]_]*string[^[:alnum:]_]*"),
// _T("Evaluate_StlString"),
// _T("Parse_StlString")
// );
// STL Vector
// driver.RegisterType(
// _T("STL Vector"),
// _T("[^[:alnum:]_]*vector<.*"),
// _T("Evaluate_StlVector"),
// _T("Parse_StlVector")
// );
Log(_T("Registering types for the debugger."));
}
And finally, you need to add the gdb scirpt file in the debugger starting command, like:
(http://forums.codeblocks.org/index.php?action=dlattach;topic=11301.0;attach=4739;image)
That's all, you can enjoying debugging!!! :D
Here is the test code:
#include <iostream>
#include <vector>
#include <string>
using namespace std;
main()
{
vector<string> SS;
SS.push_back("The number is 10");
SS.push_back("The number is 20");
SS.push_back("The number is 30");
cout << "Loop by index:" << endl;
int ii;
for(ii=0; ii < SS.size(); ii++)
{
cout << SS[ii] << endl;
}
cout << endl << "Constant Iterator:" << endl;
vector<string>::const_iterator cii;
for(cii=SS.begin(); cii!=SS.end(); cii++)
{
cout << *cii << endl;
}
cout << endl << "Reverse Iterator:" << endl;
vector<string>::reverse_iterator rii;
for(rii=SS.rbegin(); rii!=SS.rend(); ++rii)
{
cout << *rii << endl;
}
cout << endl << "Sample Output:" << endl;
cout << SS.size() << endl;
cout << SS[2] << endl;
swap(SS[0], SS[2]);
cout << SS[2] << endl;
}
You can add the variable SS to watch window, and see how good it works. and it works really badly if python gdb scirpt is not enabled.
see the screen shot below:
[attachment deleted by admin]
there is only one problems when using the python script for wxStuff and stl.
When we are using "info local" command to let the gdb show all the local variables, we may meet some problem.
eg:
#include <wx/wx.h>
#include <string>
#include <map>
#include <list>
#include <stack>
#include <vector>
int main() {
int x;
wxString wxStr(L"wxString");
wxStr += L" Value";
std::string stdStr("std::string");
stdStr.append(" value");
std::map<int, std::string> m;
m[0] = "000";
m[1] = "111";
wxString& wxStrRef = wxStr;
wxStrRef += L" Ref";
std::string& stdStrRef = stdStr;
stdStrRef += " Ref";
std::list<std::string> l = {"a", "b", "c"};
std::vector<std::string> v = {"a", "b", "c"};
std::stack<std::string> s;
s.push("a");
s.push("b");
wxArrayString arr;
arr.Add(_T("arr1"));
arr.Add(_T("arr2"));
arr.Add(_T("arr3"));
arr.Add(_T("arr4"));
return 0;
}
If you set a breakpoint in the first line "int x", then, you have "info local" enabled in your debugger setting dialog. You will get the gdb crashed, or python will generate many Errors.
that's because, at this moment, all the local variables were not initialized. I'm not sure how to solve this kind of problem, is it related to GCC? GDB? or only python script?
Here is a discussion on gdb:
http://sourceware.org/bugzilla/show_bug.cgi?id=11407
How does gdb know some local variables are already initialized or not?
Maybe, the GCC can add some extra instructions after a local variable initialization.
like:
int main() {
int x;
wxString wxStr(L"wxString"); [gcc add some extra information here, that indicate the wxStr is ready now]
wxStr += L" Value";
std::string stdStr("std::string"); [gcc add some extra information here, that indicate the stdStr is ready now]
stdStrRef += " Ref";
Then, GDB can check these debug information generated by GCC, then every thing will be OK.
Also, I have found another way, that is something like" lazy show watches", that is to say: if a variable would like to be shown in the watch window for the first time, then it will be delayed after some children of this variable is changes. Follow this rule, I think we can workaround this issue.
Another way is: We need to handle the excpetions in both python and gdb , like if the string length is too long, we should believe the variable is not initialized, so we just print some word like " out of scope" or "not initialized"..
Many IDEs like Kdevelopers and Qtcreater may meet this kind of problems either. I'm not sure how they solve them.