Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

About python gdb scirpt support

<< < (2/3) > >>

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";
--- End code ---

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:

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

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


--- Quote ---try
{

A a;
CallXXX();

B b;
CAllYYY();

}

--- End quote ---

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... :D

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:

--- Quote from: oBFusCATed on June 18, 2010, 11:21:22 am ---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 :)

--- End quote ---

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

Navigation

[0] Message Index

[#] Next page

[*] Previous page