About python gdb scirpt support

[ollydbg]

Hi, yesterday, I have found a new way to support the gdb debugging in cb. Here is the brief introduction.
GDB with Python support

If we add another python wxStuff support, note that the original file is:
wxStuff support python script

If you use wxWidgets 2.8.x version, you need to change this py file to some thin like:

Code

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

To load both the stl_print and wx_print python scirpt, I create a my.gdb file, like:

Code

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:

Code

// 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:


That's all, you can enjoying debugging!!!

[ollydbg]

Here is the test code:

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]

[reckless]

nice one olly

gonna try this out.

[ollydbg]

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:

Code

#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


 

[oBFusCATed]

As it seems there are some problems in the pretty printers in GDB and GCC as far as I know doesn't emit debug info for the status of the variable (initialized/non initialized).

So there are problems in both programs

[ollydbg]

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:

Code

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.

[ollydbg]

GCC as far as I know doesn't emit debug info for the status of the variable (initialized/non initialized).

I personally think that this "debug info" should exist in the function which exception handling is enabled. For example:

try
{

A a;
CallXXX();

B b;
CAllYYY();

}

At this time, the variables info (initialed or not) should be recorded in somewhere. Because exceptions can happens very where, the exception handler  need to call the "destruction of the already initialized object".

I guess there is a table to record this debug info...

[oBFusCATed]

ollydbg: you should read about the dwarf (the debug info format), I'm too lazy to read it myself.

Also keep in mind that the pretty printers are new feature and I suppose this is the beta testing period for it

[ollydbg]

ollydbg: you should read about the dwarf (the debug info format), I'm too lazy to read it myself.

Also keep in mind that the pretty printers are new feature and I suppose this is the beta testing period for it

Thanks, I have search that dwarf standard manual. and found there is a property named "DW_AT_start_scope". But it seems Currently,  GCC never generate this kind of debug information.

Here are the two reference:
http://gcc.gnu.org/ml/gcc/2007-04/msg00139.html

and, the updated gdb bug report:
http://sourceware.org/bugzilla/show_bug.cgi?id=11407


As a conclusion about this issue, I don't think I can help to solve. Because I have no idea about GCC and GDB source.
Even though the gue in the gcc maillist has point that adding debug infor is in
svn://gcc.gnu.org/svn/gcc/trunk/gcc/dwarf2out.c
and the  at the handling of VAR_DECL

[ollydbg]

@all
I have solved this problem, I have patch the gdb cvs code, it seems so nice. you can see the screen shot of CB when I'm debugging.

image1


image2


I will publish my patch to gdb maillist and gdb bug site.

asmwarrior


EDIT
The changed code of GDB source was published here:
http://sourceware.org/bugzilla/show_bug.cgi?id=11407#c33

[Loaden]

Great!!

[ollydbg]

Great!!

I forget to mention, Loaden has helped me a lot, especially to cross-build gdb on linux.

Thanks loaden, and also other Chinese guys.

[ollydbg]

The new gdb file has uploaded to
http://qp-gcc.googlecode.com/files/gdb7.1.50.20100623cvs.7z
And the new introduction wiki page:
http://code.google.com/p/qp-gcc/wiki/GDB


2010-09-22 updated to GDB 7.2, see here:
http://forums.codeblocks.org/index.php/topic,11301.msg77000.html#msg77000