Code::Blocks Forums

hi,

I use c::b (svn 5616)  and in my c::b project I have defined a typdef like this:

typedef vector<string> vstr;

And use it like following:

--------------------------
vstr v;

v.push_back("bla bla");
---------------------------

Everything works fine.

But when I debug, I can not see in the  "Local variabel"  an "understandable" content of the string vector.

When I open the "local watches" I only see "_M_start"  and "_M_finish" etc. with a hex number.




The only thing which is working when I watch a concrete cell of the vector is:


Add watch -->v[0]


then I can see the string of the first element of the string vector.

Is there a way to see all strings of the string vector in the debugger? That would be great.

The "v[0]" (element view) works fine but it would be very convenient to see all strings in the string vector "en block".


Thanks for your help

Martin

I test your code, found it is even bad in my system(MinGW, WindowsXP), I can't view "v[0]".
See my screenshot


[attachment deleted by admin]

If v[0] works for you, you can try to watch v as array (add it to watch window, edit it and check watch as array).

Quote from: ollydbg on June 07, 2009, 08:45:44 AM
I test your code, found it is even bad in my system(MinGW, WindowsXP), I can't view "v[0]".
See my screenshot

You have to use the []-operator in your program, otherwise it gets not compiled in and therefore cannot be used by gdb.

@taram:
watching the variable as array does not work here.

Thanks Jens for your hints.

Here is a workaround.

#include <iostream>
#include <string>
#include <vector>

using namespace std;

typedef vector<string> vstr;

int main()
{
    vstr v;
    v.push_back("bla bla");
    string v0 = v[0];
    cout << "Hello world!" << endl;
    return 0;
}

I can only watch "v0" (see the screen shot)




[attachment deleted by admin]

Hi,

first of all, thank all for your help and replies to my question. Sorry for my delayed answer, but I am here in Calgary and -8h behind European time :)

However, here the code which I was using for testing:

#include <iostream>
#include <string>
#include <vector>

using namespace std;

typedef vector<string> vstr;

int main()
{
   vstr v;
   v.push_back("1. bla bla");
   v.push_back("2. bla bla");
   v.push_back("3. bla bla");

   int a[3] ={11, 22, 33};



   for (unsigned int f = 0; f<3; f++)
   {
       cout <<" a[" << f <<"] = " << a[f];
       cout << " and v[" << f << "] = " << v[f] << endl;
   }

   return 0;
}


I played around with "Add watches" and I was not able to get a similar debugger output of a string vector compared to the output of a normal array (see screen-shot-1.png).

The only thing which was working for the string vector was the "element view" i.e. "Add wachtes --> v[0] (see screen-shot-1.png).

But  with this method you have to be very carefully, since if you enter a element which does not exist i.e. out of array range, you will get a "segmentation signal" from Code::Blocks. (see v[3] in "wachtes in screen-shot-1.png and signal in screen-shot-2.png). So for me this "element view" method is not a 100% good way, it is more a 80% provisional solution :)

However, it would be very convenient if the debugger would show the string vector similar like the array (see "a" in watches --> screen-shot-1.png).

Thanks

Martin

PS: @ Jens
special thanks to you for providing debian-repository for Code::Blocks.
I use Debain Lenny, and this is a very convenient way to be up to date with Code::Blocks nightly builds.
Small suggestion for your page http://apt.jenslody.de/ :

instead of this line:

--------------------------------------------------------------------------------------------

...The best and easiest way to add my public-key to apt's trustdb is to install the package jens-lody-debian-keyring with your preferred package-manager or apt-get.  ....

--------------------------------------------------------------------------------------------

write it more explicitly like:

--------------------------------------------------------------------------------------------

... The best and easiest way to add my public-key to apt's trustdb is to install the package jens-lody-debian-keyring with

#apt-get-get install jens-lody-debian-keyring

or

#aptitude  install jens-lody-debian-keyring

--------------------------------------------------------------------------------------------

Since most people do not read a web page they skim it.


[attachment deleted by admin]

Here screen-shot 2, since max. attachment size is 128kb

Martin

[attachment deleted by admin]

Quote from: taram on June 07, 2009, 10:49:22 PM
However, it would be very convenient if the debugger would show the string vector similar like the array (see "a" in watches --> screen-shot-1.png).

You are right, but that seems to be a gdb issue and a workaround might not be so easy.

Quote from: taram on June 07, 2009, 10:49:22 PM
PS: @ Jens
special thanks to you for providing debian-repository for Code::Blocks.
I use Debain Lenny, and this is a very convenient way to be up to date with Code::Blocks nightly builds.
Small suggestion for your page http://apt.jenslody.de/ :

(Vielen Dank)
Thank you for the suggestion, I just changed my site.

Yes, it may be an GDB issue, but I have less knowledge about it.

However may be in a future nightly build this issue will be solved... may be this issue should be forwarded to a "GDB geek" of the Code::Blocks developer crew.

Cheers

Martin

may be these links help....

http://www.stanford.edu/~afn/gdb_stl_utils/

http://help.lockergnome.com/linux/GDB-capabilities-exploring-STL-classes--ftopict279673.html

but this is beyond my "doable", since I am a newbe to GBD. hope some of the C::B developers can use this

cheers

Martin

Quote from: taram on June 08, 2009, 02:59:59 AM
Also frisch ans Werk - lets start fresh....
[...]
@ Jens: Schön, daß Du meinen Vorschlag aufgegriffen hast bzgl. Deiner HP. 

Although we do have German admins please do *not* post in German anymore if there is no particular reason. This is and remains an english-only forum. Thanks.

?? I do not understand your concerns?? I know this fact, but there was no additional information in the German sentence and furthermore the translations was given directly behind it.

The other sentence was a thankful personal note to jens.

Further the complete discussion about the problem was/is done in English. If it would be done in German you would be right.

However, it was not my intention to disregard the forum rules, so I modified my entries above.

Cheers

Martin  

Quote from: taram on June 08, 2009, 02:59:59 AM
Yes, it may be an GDB issue, but I have less knowledge about it.

However may be in a future nightly build this issue will be solved... may be this issue should be forwarded to a "GDB geek" of the Code::Blocks developer crew.

Cheers

Martin

No, I doubt it.  The GDB geeks are another group of geeks entirely.  The geeks who develope C::B only use GCC, they don't develope it.  In short, your problem is strictly a GDB problem, not a C::B problem.

I noticed that you never mentioned which version of GCC (and therefore GDB) you are using.  It may be that a newer version has the features you need.

Ringo

thx ringo for your input. I use

- gcc version 4.3.2 (Debian 4.3.2-1.1,Target: i486-linux-gnu)   -- by $gcc -v

- GNU gdb 6.8-debian (This GDB was configured as "i486-linux-gnu".) -- by $gdb -v

I will try to find a deb package for debian lenny and then  update to GCC 4.3.3
   
http://gcc.gnu.org/gcc-4.3/

may be this solve the problem

cheers

Martin

Quote from: jens on June 07, 2009, 10:12:13 AM
You have to use the []-operator in your program, otherwise it gets not compiled in and therefore cannot be used by gdb.

Hi, Jens. Thanks for the reply.
I understand now. (Oh, My poor English, I need to read twice of these sentence to understand it's meaning :()
If I define v[0], then gdb can also understand v[1].  :D


#include <iostream>
#include <string>
#include <vector>

using namespace std;

typedef vector<string> vstr;

int main()
{
   vstr v;
   v.push_back("bla bla");
   v.push_back("abcdef");

   string v0 = v[0];
   cout << "Hello world!" << endl;
   return 0;
}


See my screen shot.

Edit:
Oh, taram has already mentioned that.

Edit2
If I just add "v" to "watch", then check on the "Watch as array" opiotion. I still can't view any contents. Seems GDB didn't regard "v" as an array beginning address.
We can only use "v[0], v[1]" instead. :D





[attachment deleted by admin]

while we are disliking GDB shortcomings.
Does anyone know how alive GDB is ? There are cvs updates, but real info seems to be real sparse or even completely hidden.
Basically, when will there be a next GDB, anyone any ideas ?

/Off
Here: http://sources.redhat.com/gdb/schedule/ there should have been a release already :-)

/On

I don't think, gdb is to blame here. The v is not an array, but a class, v._M_start is an array (or I think it is).
I've not tested, but the value in the watch should be v._M_start[0],
this way you are not depending on the operator[] being present.

Edit:
Here is the official info about C++ STL and gdb: http://sourceware.org/gdb/wiki/STLSupport

Thanks, I'm trying to use this way on MinGW.

http://www.yolinux.com/TUTORIALS/GDB-Commands.html#STLDEREF

Not sure how to add "gdbinit", so, still Googling :D

Edit1:
In my cb debug start up, it the command line ( I copied from debug log output)


Command-line: D:\MinGW\bin\gdb.exe -nx -fullname  -quiet -args bin/Debug/test_for_cb_forum.exe
Working dir : C:\test\test_for_cb_forum\


Seems there is default "-nx" options. :(

Edit2

I find in the "gdb_driver.cpp", these code "disable the .gdbinit related function".

wxString GDB_driver::GetCommandLine(const wxString& debugger, const wxString& debuggee)
{
    wxString cmd;
    cmd << debugger;
    cmd << _T(" -nx");          // don't run .gdbinit
    cmd << _T(" -fullname ");   // report full-path filenames when breaking
    cmd << _T(" -quiet");       // don't display version on startup
    cmd << _T(" -args ") << debuggee;
    return cmd;
}

wxString GDB_driver::GetCommandLine(const wxString& debugger, int pid)
{
    wxString cmd;
    cmd << debugger;
    cmd << _T(" -nx");          // don't run .gdbinit
    cmd << _T(" -fullname ");   // report full-path filenames when breaking
    cmd << _T(" -quiet");       // don't display version on startup
    cmd << _T(" -pid=") << wxString::Format(_T("%d"), pid);
    return cmd;
}

Hi, all, I can successfully view the vectors.

Here is the debug log output from "debugger (debug)" panel.

>>>>>>cb_gdb:
> pvector v
elem[0]: $1 = {
 static npos = 4294967295,
 _M_dataplus = {
   <std::allocator<char>> = {
     <__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>},
   members of std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_Alloc_hider:
   _M_p = 0x3247c "bla bla"
 }
}
elem[1]: $2 = {
 static npos = 4294967295,
 _M_dataplus = {
   <std::allocator<char>> = {
     <__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>},
   members of std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_Alloc_hider:
   _M_p = 0x324ac "abcdef"
 }
}
Vector size = 2
Vector capacity = 2
Element type = std::basic_string<char, std::char_traits<char>, std::allocator<char> > *




There are several steps:

1. copy the "stl-views-1.0.3.gdb (http://sourceware.org/gdb/wiki/STLSupport?action=AttachFile&do=view&target=stl-views-1.0.3.gdb)" file  to the project directory.( This directory serves as working directory as GDB.exe starts)

2. In the Menu->setting->compiler and debuggers dialog.

Add "source stl-views-1.0.3.gdb" to the debugger initialization command control.

3. start debugging!

4.In the Menu->debug->set user command to the debug dialog.
Enter " pvector v"

5, the v will be shown :D


By the way, I think the "set user command to the debug" dialog should be embeded in the "debugger(debug" panel, so, people don't need to open it again and again. (seems to annoying).

Yes, as discussed in the other thread.
I'll see if I can add it there tonight.

If you have more power and desire to hack the vector issue, can you try to use the pvector command in a debugger script (http://wiki.codeblocks.org/index.php?title=Debugger_scripts)?

Quote from: oBFusCATed on June 09, 2009, 01:45:09 PM
Yes, as discussed in the other thread.
I'll see if I can add it there tonight.

If you have more power and desire to hack the vector issue, can you try to use the pvector command in a debugger script (http://wiki.codeblocks.org/index.php?title=Debugger_scripts)?

Other thread? which thread?

For me, I think writeing a debugger_scripts is beyond my level. :D

Quote from: ollydbg on June 09, 2009, 04:03:17 PM
Other thread? which thread?

I was talking about this:

Quote from: ollydbg on June 09, 2009, 12:53:15 PM
By the way, I think the "set user command to the debug" dialog should be embeded in the "debugger(debug" panel, so, people don't need to open it again and again. (seems to annoying).

Quote from: ollydbg on June 09, 2009, 04:03:17 PM
For me, I think writeing a debugger_scripts is beyond my level. :D

Yes writing a debugger_script looks tough... have not tried it, just read the docs, thought.

Quote from: ollydbg on June 09, 2009, 04:03:17 PM

Quote from: oBFusCATed on June 09, 2009, 01:45:09 PM
Yes, as discussed in the other thread.
...

Other thread? which thread?

I guess he means this thread: http://forums.next.codeblocks.org/index.php/topic,10154.msg72880.html#msg72880 (http://forums.next.codeblocks.org/index.php/topic,10154.msg72880.html#msg72880)

guys, keep up the good work, I see an interesting patch being created.
This would really enhance the debugging experience in CB !!!

Here is the patch: http://forums.next.codeblocks.org/index.php/topic,10676.0.html

p.s. Sorry that I'm posting the same thing to multiple threads...

Quoteguys, keep up the good work, I see an interesting patch being created.
This would really enhance the debugging experience in CB !!!

QuoteHere is the patch: http://forums.next.codeblocks.org/index.php/topic,10676.0.html

p.s. Sorry that I'm posting the same thing to multiple threads...

Since I am a newbe to CB I am a little bit confused about the "debugger_script" thing and the "patch".

Do we have to install the patch manually or will it be implemented in one of the next nightly builds?

Or do I have to do this:

Quote from: ollydbg on June 09, 2009, 12:53:15 PM

There are several steps:

1. copy the "stl-views-1.0.3.gdb (http://sourceware.org/gdb/wiki/STLSupport?action=AttachFile&do=view&target=stl-views-1.0.3.gdb)" file  to the project directory.( This directory serves as working directory as GDB.exe starts)

2. In the Menu->setting->compiler and debuggers dialog.

Add "source stl-views-1.0.3.gdb" to the debugger initialization command control.

3. start debugging!

4.In the Menu->debug->set user command to the debug dialog.
Enter " pvector v"

5, the v will be shown :D

Sorry for this stupid question, but I am still learning.

Thanks

Taram

Quote from: taram on June 10, 2009, 07:18:30 AM

Quoteguys, keep up the good work, I see an interesting patch being created.
This would really enhance the debugging experience in CB !!!

QuoteHere is the patch: http://forums.next.codeblocks.org/index.php/topic,10676.0.html

p.s. Sorry that I'm posting the same thing to multiple threads...

Since I am a newbe to CB I am a little bit confused about the script thing and the patch.

Do we have to install the patch manually or will it be implemented in one of the next nightly builds?

Sorry for this stupid question, but I am still learning.

Thanks

Taram

Well, you need to build the whole CB yourself. See

http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_from_source_on_Windows

For other platforms, you can find similar wiki pages there. :D

For me, I just download the patch, then applied the path to my local source code of CB, then rebuild the CB.

It's not difficult.

Thx for your quick answer ollydbg. I do not use windows.

I am using Debian/Linux and Jens' unofficial debian-repository for Code::Blocks
http://apt.jenslody.de/

So will issue be implemented in a future SVN?  

I have Code::Blocks SVN 5616 right now.

This can then be updated easily by

#apt-get update
#apt-get upgrade

since I am using Jens' debian-repository for Code::Blocks.

Thanks

Taram

Any developer has the rights to add patch in the trunk(SVN repository).

So, if some dev was interested in this patch, and surely it will be add to trunk. :D

hehe, and the patch I was talking about and hoping to see, is that CB can/will display vectors without having the user to explicitly send a debug command to gdb, and preferably those scripts being active on the global level, and per project ;-)

You'll see it  :lol:

You're saying that C::B should ship with the stl.gdb script?
And you want to have a checkbox in the options "use stl debugging script"?

One options is to add a list with user/system defined gdb scripts and when we start the debugger we source the chosen scripts.

Quote from: oBFusCATed on June 10, 2009, 10:57:03 AM
You'll see it  :lol:

You're saying that C::B should ship with the stl.gdb script?
And you want to have a checkbox in the options "use stl debugging script"?

One options is to add a list with user/system defined gdb scripts and when we start the debugger we source the chosen scripts.

I would prefer to have it similar to the STL-string script, we already have to make STL-strings visible.
Sending commands directly to gdb, if I want to debug a vector and have the output inside gdb's logging window is possible, but not what I would expect.

This should be transparent, and only the values inside the vectors are of interest (normally) and not all the other stuff, we also get when using the script and the pvector command.

I think this should be possible, and I will try it, if I find the time.

Yes the value of the vector, show be visible in the watch window.
The user would not need to enter the pvector command.

But the script might not be possible without it. I'm not sure, though :(

I'm playing with the debug script for the vector class
And I need some help with the parse function.

Can someone explain what is the format of the string that the Parse_MyClass function should emit?
There are no docs and looking at the source of the parser won't help me match :(


keep your fingers crossed :)

OK, I've achieved 99% success.

0. Apply the script bindings patch (the patch adds the tointeger function)
1. Follow the steps in the ollydbg's post. You need working pvector command
2. Replace the gdb_types.script with the attached one
3. Have fun debugging vectors (see the main.cpp file for a working test case :) )

Known problem: does not work for vector< vector<int> > types.

[attachment deleted by admin]

Wonderful Job!!!!

I tested it and it can work on vector<int>.
Thank you very much!!!!!

Here is a screen shot.
(http://sites.google.com/site/studycodeblocks/Home/vector_int.png)

By the way, I'm not fully understand what the sentence means. :(

QuoteCan someone explain what is the format of the string that the Parse_MyClass function should emit?
There are no docs and looking at the source of the parser won't help me

Where is the term "Parse_MyClass" function?


Edit:
I can't upload attachment any more, because my upload folder is full. So I have to upload the image to an external site. :(

Quote from: ollydbg on June 11, 2009, 03:38:45 AM
Where is the term "Parse_MyClass" function?

This is fictional name, when you write a debug script you need to provide to functions Evaluate_MyClass and Parse_MyClass.

btw: It works on the vector<struct>, too :)

The vector<vector<> > case requires script binding for

local cmd_result = ExecuteDebuggerCmd("pvector $1");
or
local parsed_value = DebuggerEvaluateVariable("$1"); // $1 is a gdb variable I think

This way when I iterate the elements of the vector, I can evaluate and then parse them if they are complex

Quote from: oBFusCATed on June 10, 2009, 11:47:11 PM
OK, I've achieved 99% success.

Nice work! :-)

Anyways (taking the risk of nut-picking): Please name script bindings with names that really tell what they do. I have renamed the "tointeger" function intol "wxString_ToLong". Because that's what is actually happening. And only that.

No problem, my idea with the naming was to replicate the build-in tonumber function of squirrel. And I have no problems with the new name (except that it will be good if you sync the wxaui branch to trunk, because that is what I'm using).

What about the other two scripting functions that are required? Are they hard to implement?
The former will be used to implement squirrel version of the stl-views file, at the moment that is not possible.
The latter will be used in parsing of complex structures.

At the moment (I think) if the vector is part of a struct it won't be parsed, when the tree item of the struct is expanded:


struct
{
   std::string s;
   std::vector<int> v;
} a;

In the watches
a
|-- s   <--- not parsed as string
|-- v   <--- not parsed as vector


BTW: the std::list will require two commands to be parsed
1. plist list (to find its T type)
2. plist list T to get the structure

Quote from: oBFusCATed on June 11, 2009, 09:35:37 AM
No problem, my idea with the naming was to replicate [...]

I have updated the script binding even more. I had started to do it several month ago and had in mind to bind the wxString functions. If you want to, place your ToLong function into the "right" place now. ;-)

OK, but what revision is that ... I haven't seen it in the log on the site :(

@Morton

did you already add the apply/commit all those changes to have the vector debug support completely , that is the gdb_types.script ?

killerbot - my gdb_types.script file is just a test, a demonstration what can be done, it needs polishing  8)

Quote from: oBFusCATed on June 11, 2009, 12:15:20 PM
OK, but what revision is that ... I haven't seen it in the log on the site :(

Revision 5630 (trunk)
Revision 5638 (trunk)

Quote from: killerbot on June 11, 2009, 12:25:57 PM
did you already add the apply/commit [...] gdb_types.script ?

No. I haven't completely tried myself. So I didn't commit that part.

Quote from: oBFusCATed on June 11, 2009, 01:10:52 PM
killerbot - my gdb_types.script file is just a test, a demonstration what can be done, it needs polishing  8)

When could you have such a polished version. I would test it this weekend, and then commit it if all is ok.

Do you care for the vector<vector<T> > and vector<string> cases, at the moment?
Or you want to add the simple version and later improve the parsing?

What about large vectors? vectors with -> 1 000, 10 000, 100 000 or 1000 000 items?
Do we limit the watch to the first 10,20,100?
Or there is special syntax for the watches, as in Visual C++ (  "my_var,10" will show the first 10 items)?

Also what about other classes: list, deque, map, set, unordered_map, unordered_set and the multi versions (I've never used  :lol:) ?
And the various iterators?

p.s. what will happen if I have /usr/share/codeblocks/scripts/gdb_type.script and ~/.codeblocks/share/codeblocks/scripts/gdb_types.script simultaneously, which of the two will be used?

we care for the others too ;-)
But I think it is best to start with 1 at a time. Try that, when OK, commit.
Then the next one, and so one, in case something might be bad, we only have to take out the bad one, and the others, the working ones, are still present.

About which script will be use, dunno, no script expert :-(

OK, so we want to have vector<int>, vector<some_struct> and so on working on the basic level.
That is doable, I'll take a look at the item count problem tonight and clean the file, so it is ready for commit.

Can I ask some of you to sync the wxaui branch to trunk, because this way it will be easier for me (I'm using in the wxaui branch for everything)?

Quote from: oBFusCATed on June 11, 2009, 02:30:07 PM
Do you care for the vector<vector<T> > and vector<string> cases, at the moment?

These are the ones I personally use most. ;-)

Quote from: oBFusCATed on June 11, 2009, 02:30:07 PM
What about large vectors? vectors with -> 1 000, 10 000, 100 000 or 1000 000 items?
Do we limit the watch to the first 10,20,100?

I'd vote for that.

Quote from: oBFusCATed on June 11, 2009, 02:30:07 PM
Also what about other classes: list, deque, map, set, unordered_map, unordered_set and the multi versions (I've never used  :lol:) ?
And the various iterators?

Same thing... but enhancements can come with time...

OK, Here is the cleaned up version. (see the attachment)

But there is one very serious performance problem:
I've modified the main.cpp file and now the v vector has 1000 elements.
This means that the string returned from the pvector command is massive (10-20k characters).
And when I put the v variable in the watches pressing f7 causes 1-5 second of delay (the debugger toolbar is inactive for that period).
Putting return _T("") at the first line of Parse_StlVector doesn't help.
Executing "pvector v 0 20" instead of "pvector v" speeds things up, but doesn't work for vectors with less than 20 elements :(

p.s. If you are using trunk version of C::B replace tostring with the wxString_ToLong
p.s.s. I'm running a q6600 @ 3.4ghz, so on slower machines the problem will be bigger :(
p.s.s.s. I'll run C::B in the debugger to see what is happening, but any hints where to look at will be very welcome

[attachment deleted by admin]

I know for example that MSVC debugger warns about big arrays (saying it might take some time), and asks to go ahead.

We could do a similar things, question is what is big (above 20, above 50), maybe we could allow the user to choose how much elements at that time (we can already get the number of elements from GDB).

I will apply with the current situation, it is a start. With more feedback coming we will be pushed into the right direction ;-)

Quote
p.s. If you are using trunk version of C::B replace tostring with the wxString_ToLong

the script does not contain any "tostring", am I missing something ?

My mistake
replace tostring with tointeger in my post

Does someone has any idea, how can I profile the debugger plugin?

Quote from: oBFusCATed on June 11, 2009, 07:40:37 PM
OK, Here is the cleaned up version. (see the attachment)

BTW, this:

Quote1. copy the "stl-views-1.0.3.gdb" file  to the project directory.( This directory serves as working directory as GDB.exe starts)

Should be handled differently. Nobody should need copy the file to each and every project. I suggest a setting in the debugger's options. Probably this can be done through initialisation commands, is that possible?!

There is no requirement for stl-views-1.0.3.gdb to be in the project's directory.
Mine is somewhere in ~/projects/codeblocks.
We can put it in the share folder (/usr/share/codeblocks or ~/.codeblocks/share/codeblocks/ ) and put a checkbox in the debugger's options dialog to enable it ( "Debugging C++ STL classes" for example)

Question : why would one NOT want to be able to debug STL classes.
I would have it there, and if no one complains (why do I expect a comment from Thomas here ;-)  ) leave it there.

I think it is best to put it in /usr/share/codeblocks and the same for windows.

EDIT : now it is enabled by default right ?

EDIT 2 : /usr/local/share/codeblocks

Quote from: killerbot on June 12, 2009, 03:32:45 PM
Question : why would one NOT want to be able to debug STL classes.

The only thing I can imagine is if it really takes too long and "freezes" C::B therefore for large vectors. Otherwise I'd leave it enabled by default, too.

morten: It doesn't freeze the C::B, it's responsive, but the debugging UI is disabled

killerbot: The user should source the stl-views script, so it is disabled by default and watching vectors should be broken by default.

I suppose the plan should be something like:
1. adding an options which is off in the default config
2. giving it a bit of testing/improvements for couple of months
3. switching it on for all user/removing it

I think, I know why the watching of vector with 1000 elements is slow.

The pvector command emits a line for every element in the vector, this means that it emits 1000 + 3 (size, capacity, elem type).
I've added a logging line as follows:

void GDB_driver::ParseOutput(const wxString& output)
{
    m_pDBG->Log(wxString::Format(_("GDB_driver::ParseOutput output size: %d"), output.length()));


With this addition, when I add v as a watch, I get too many lines in the debugger pane that look the same:

GDB_driver::ParseOutput output size: 13
GDB_driver::ParseOutput output size: 15
GDB_driver::ParseOutput output size: 15
GDB_driver::ParseOutput output size: 15
GDB_driver::ParseOutput output size: 15
GDB_driver::ParseOutput output size: 15
GDB_driver::ParseOutput output size: 15
GDB_driver::ParseOutput output size: 15
GDB_driver::ParseOutput output size: 15


So, we are parsing the output from the debugger line by line (emiting 1002 pipe events more that we should).
And here is the proof:

In bool PipedProcess::HasInput() we have:

    if (IsInputAvailable())
    {
        cbTextInputStream sout(*GetInputStream());

        wxString msg;
        msg << sout.ReadLine();

CodeBlocksEvent event(cbEVT_PIPEDPROCESS_STDOUT, m_Id);
        event.SetString(msg);
wxPostEvent(m_Parent, event);
// m_Parent->ProcessEvent(event);

        return true;
    }


So, the question is can we replace the ReadLine method with ReadBuffer/ReadWholeData one?
What depends on the line by line parsing and what will break if we do the replacement?

p.s. I'm not sure how fast gdb runs the pvector script though

Hello again,

I've done a little experiment (see the patch):

Index: src/sdk/pipedprocess.cpp
===================================================================
--- src/sdk/pipedprocess.cpp    (revision 5643)
+++ src/sdk/pipedprocess.cpp    (working copy)
@@ -94,8 +94,8 @@
                if ( !m_input )
                    break;

-                if (EatEOL(c))
-                    break;
+//                if (EatEOL(c))
+//                    break;

                line += c;
            }


Removing the EOL checks makes the ReadLine method to read the whole input data that is available
(the debug output shows that strings of 1000+ character are read).
And the CB is interactive again if the Parse_StlVector looks like this:


function Parse_StlVector(a_str, start)
{
    // the whole processing not commented to test its speed
    ..... ....

    // put this before the first return, so the function doesn't produce big string result
   return "test-value";
}


With this setup the CB is quite interactive (less than a second, measured with my internal human clock :) ).

p.s. I've not tested for breakage of the compiler or so... just the debugger

Finally I got to trying the patch, but it doesn't work for me.

This is what I have done :

1) Put your gdb_types.script instead of the CB's official one (with the tointeger being replaced by the real supported command)
2) copied "stl-views-1.0.3.gdb" to /usr/local/share/codeblocks
3) compiler/debugger settings : added "source stl-views-1.0.3.gdb" to the "Debugger initiliazation commands"
4) created console app with your main.cpp
5) but both watches (v / vv) don't show anythin at al (not even the ... repitition of 0)
6) When I do manually "Send user command to debugger" : "pvector v" , then I can see in the debug log pane : "Undefined command: "pvector".  Try "help"."

What part am I missing ??


EDIT : the answer I saw in the debugger log pane was incorrectly copy/pasted in here : modified my post to contain the correct answer which is "Undefined command: "pvector".  Try "help"."
"

Quote from: killerbot on June 13, 2009, 09:06:26 PM
6) When I do manually "Send user command to debugger" : "pvector v" , then I can see in the debug log pane : "pvector v"

So If I understand correctly, the pvector v command is emmiting something like (writting from memory because I'm not infront of my pc at the moment)


elem 0: $1 = 1
elem 0: $2 = 2
Vector size = 2
Vector capacity = 2
Element type int*


What gcc and gdb do you use?
I'm using gcc 4.3.3 and gdb 6.8 on gentoo amd64 bit
I think, I've read that the stl-views file has some modifications for gcc-4.3.x series.
If you are using older compiler, that might cause the problem. :(

I have a problem "Squirrel function call failed". As in the debuger (debug) panel, I can see the returned string from gdb. see the screen shot:

(http://sites.google.com/site/studycodeblocks/_/rsrc/1244949553645/imagescb/SquirrelFunction.png)

I edited my post above, I made a copy/paste error on what answer I see in the debug pan upon isseing "pvector v".
It is "Undefined command: "pvector".  Try "help"."

GCC: 4.3.1
GDB : 6.8

Quote from: killerbot on June 14, 2009, 10:23:12 AM
I edited my post above, I made a copy/paste error on what answer I see in the debug pan upon isseing "pvector v".
It is "Undefined command: "pvector".  Try "help"."

GCC: 4.3.1
GDB : 6.8

This means the extend gdb command script file was not load correctly.
"source stl-views-1.0.3.gdb"

If this file loaded correctly, you can type "pvector", then here is the log output.

> pvector
Prints std::vector<T> information.
Syntax: pvector <vector> <idx1> <idx2>
Note: idx, idx1 and idx2 must be in acceptable range [0..<vector>.size()-1].
Examples:
pvector v - Prints vector content, size, capacity and T typedef
pvector v 0 - Prints element[idx] from vector
pvector v 1 2 - Prints elements in range [idx1..idx2] from vector
>>>>>>cb_gdb:

how can I check if somethings is wrong in the first setup steps ??

Quote from: ollydbg on June 14, 2009, 10:31:47 AM
If this file loaded correctly, you can type "pvector", then here is the log output.

Code Select Expand

> pvector
Prints std::vector<T> information.
Syntax: pvector <vector> <idx1> <idx2>
Note: idx, idx1 and idx2 must be in acceptable range [0..<vector>.size()-1].
Examples:
pvector v - Prints vector content, size, capacity and T typedef
pvector v 0 - Prints element[idx] from vector
pvector v 1 2 - Prints elements in range [idx1..idx2] from vector
>>>>>>cb_gdb:

Hi, I am trying to learn debugging in Code::Blocks by reading this. I have also read a GDB tutorial.

Are you supposed to type in those commands in the "Debugger" tab? I have a sample program running in debug mode and stopped at a breakpoint (defined by clicking in the margin). But under "Watches" and "Local variables" it just says "No locals", which is obviously not the case. And the Debugger window (the Debugger tab in the Messages area) will not allow me to type in anything at all. So I am "blind".

What am I missing? The debugger is running, but I don't seem to be able to examine any variables at all, even simple integers. The debugger reports "Registering new type: wxString" and the same for STL String and Vector, so it appear sto be working.

There must be something simple I have not figured out.... but what?

Quote from: killerbot on June 14, 2009, 12:01:45 PM
how can I check if somethings is wrong in the first setup steps ??

The source command does not emit errors :(
Issuing the pvector command is the only way to debug it :(
I've lost 15 minutes myself debugging a typing error in the command.

Quote from: ollydbg on June 14, 2009, 05:25:33 AM
I have a problem "Squirrel function call failed". As in the debuger (debug) panel, I can see the returned string from gdb. see the screen shot:

What version of CB do you use? With tostring or with wxString_ToLong binding?
Open the script console, to see the script errors (view -> script console)

Quote from: oBFusCATed on June 14, 2009, 10:19:40 PM
What version of CB do you use? With tostring or with wxString_ToLong binding?
Open the script console, to see the script errors (view -> script console)

Firstly, Thanks for your reply!

I use the SVN 5645 CB and applied your patches(two patches, the debug command and STL vector).

I'm sorry, I'm not sure what's the difference between tostring or wxString_ToLong binding :(.

In my mind, I can only understand the wiki page of debug_script.
http://wiki.codeblocks.org/index.php?title=Debugger_scripts
Like the image

(http://sites.google.com/site/studycodeblocks/_/rsrc/1244949553645/imagescb/SquirrelFunction.png)

There are several steps:
1, send a command to GDB to query the variable type by  "whatis v"
2, GDB return the type = XXXXXXX
3, if the type string matches some Evaluate_XXX function, then the correct script will be called by squirrel to GDB for more details
4, the corresponding  Parse_XXXX function will be called to give the correct value the "watches panel"

So, what does the binding used for? :D

Here is my squirrel log output:

Welcome to the script console!

AN ERROR HAS OCCURED [the index 'tointeger' does not exist]

CALLSTACK
*FUNCTION [Parse_StlVector()] F:\cb_svn\src\output\share\codeblocks\scripts\gdb_types.script line [158]

LOCALS
[size_value] INSTANCE
[capacity_pos] 16
[vector_info_str] INSTANCE
[size_pos] 0
[start] 0
[a_str] INSTANCE
[this] TABLE


Seems I should use "tostring"? How can I do? Thanks.

Uf, I've swap tointeger with tostring again :(

The updated version of the gdb_types.script uses tointeger, but the function that should be called is wxString_ToLong (Morten likes that name more and modified my bindings patch)


AN ERROR HAS OCCURED [the index 'tointeger' does not exist]

CALLSTACK
*FUNCTION [Parse_StlVector()] F:\cb_svn\src\output\share\codeblocks\scripts\gdb_types.script line [158]


So on line 158, replace tointeger with wxString_ToLong and it will work

@killerbot, tonight I'll test "set debug on" or something like that for the source command

@oBFusCATed
Thanks!! replace that string can solve this problem. :D

By the way, I'm reading some code in "DebuggerState::AddBreakpoint", it seems the breakpoints were recorded in a List structure. I'm wondering if this structure can be saved to harddisk(like browsetracker plugin), and reloaded when a project opened. Seems too complex :(

Haha, While playing with the vectors I was wondering the same thing, we can start another thread where we can talk about that :)

I have carried out the same steps on my windows box and I run into the same issue.

Another wrap up of what I did, staring from rev 5649.

1) replaced  share\CodeBlocks\scripts\gdb_types.script with the one from the vector.zip file attached a few posts above
2) modified that file : tointeger->wxString_ToLong  (occured in 1 place)
3) copied the "stl-views-1.0.3.gdb" into "share\CodeBlocks"
4) debugger settings : init commands added : "source stl-views-1.0.3.gdb"

and I get ==> "Undefined command: "pvector".  Try "help"."


IMPORTANT : when I copied the 'stl-views-1.0.3.gdb" next to my cbp file it works.

So it seems we either don't put that file in the correct place in the share path, or so;e code does not try to retrieve it correctly !!!

Quote from: killerbot on June 15, 2009, 11:23:57 AM
3) copied the "stl-views-1.0.3.gdb" into "share\CodeBlocks"
4) debugger settings : init commands added : "source stl-views-1.0.3.gdb"

Try to use full path or path relative to the project's root

Quote from: oBFusCATed on June 15, 2009, 09:06:48 AM
The updated version of the gdb_types.script uses tointeger, but the function that should be called is wxString_ToLong (Morten likes that name more and modified my bindings patch)

Sorry for the inconvenience. I didn't think this would cause such trouble... :(

Quote from: MortenMacFly on June 15, 2009, 12:09:24 PM

Quote from: oBFusCATed on June 15, 2009, 09:06:48 AM
The updated version of the gdb_types.script uses tointeger, but the function that should be called is wxString_ToLong (Morten likes that name more and modified my bindings patch)

Sorry for the inconvenience. I didn't think this would cause such trouble... :(

I like wxString_ToLong too 8)

Quote from: oBFusCATed on June 15, 2009, 12:09:01 PM

Quote from: killerbot on June 15, 2009, 11:23:57 AM
3) copied the "stl-views-1.0.3.gdb" into "share\CodeBlocks"
4) debugger settings : init commands added : "source stl-views-1.0.3.gdb"

Try to use full path or path relative to the project's root

relative to project's root is no options, projects can be any where on the system.

FullPath might work.
@Yiannis : can we use macros there, eg CB install directory, data directory , ...  in the gdb init commands?

source $(CB-SOMETHING)/something-else/stl-views-1.0.3.gdb   ???

EDIT : or the debugger plug-in should try to look for those scripts in the CB data directory

EDIT2 : partially answered my own question (see a next post)

Don't worry about, that the source command will be executed by the debugger plugin internally or we can add a list with debugger files to be sourced...

I find a small hack.

http://sourceware.org/ml/gdb/2007-06/msg00091.html

We can get the gdb environment variables, then write a templary file.

type "show env" in GDB, it will show one variable :


APPDATA=F:\cb_svn\src\output\AppData


I'm wondering if we can use something like

$(APPDATA)/stl-views-1.0.3.gdb

Since the "source" command can't interpret the $(APPDATA) :(

well there are a few options I think :

1) specify in the source command some $CB macro [$DATAPATH] and have the debugger plugin, run macro replacement before creating debug commands from it
   // pass user init-commands
   wxString init = Manager::Get()->GetConfigManager(_T("debugger"))->Read(_T("init_commands"), wxEmptyString);
   // commands are passed in one go, in case the user defines functions in there
   // or else it would lock up...
   QueueCommand(new DebuggerCmd(this, init));


so this would result into :
   // pass user init-commands
   wxString init = Manager::Get()->GetConfigManager(_T("debugger"))->Read(_T("init_commands"), wxEmptyString);
   Manager::Get()->GetMacrosManager()->ReplaceMacros(init);
   // commands are passed in one go, in case the user defines functions in there
   // or else it would lock up...
   QueueCommand(new DebuggerCmd(this, init));



2) just specify the file to source with no extra path and have the command interpreter check in case the command is 'source' to check for the file in the current working directory, and in case not found there, check in the CB app directory (needs to know where that app/data directory is.

Option 1 seems the most easiest and quickest, but maybe not the most user friendliest.

QUESTION : does anyone see a negative side effect of issuing a macro replacement on those debugger init commands ?

Quote from: oBFusCATed on June 15, 2009, 12:39:14 PM
Don't worry about, that the source command will be executed by the debugger plugin internally or we can add a list with debugger files to be sourced...

So...I tried again and... failed. Let me put the output here (this is what happens if I hover over "vv" of the sample):
> whatis vv
type = vector<std::vector<int, std::allocator<int> >,std::allocator<std::vector<int, std::allocator<int> > > >
>>>>>>cb_gdb:
> output &vv
(vector<std::vector<int, std::allocator<int> >,std::allocator<std::vector<int, std::allocator<int> > > > *) 0x22ff10>>>>>>cb_gdb:
> pvector vv
elem[0]: $1008 = {
 <_Vector_base<int,std::allocator<int> >> = {
   _M_impl = {
     <allocator<int>> = {
       <new_allocator<int>> = {<No data fields>}, <No data fields>},
     members of _Vector_base<int,std::allocator<int> >::_Vector_impl:
     _M_start = 0x3f4210,
     _M_finish = 0x3f4214,
     _M_end_of_storage = 0x3f4214
   }
 }, <No data fields>}
elem[1]: $1009 = {
 <_Vector_base<int,std::allocator<int> >> = {
   _M_impl = {
     <allocator<int>> = {
       <new_allocator<int>> = {<No data fields>}, <No data fields>},
     members of _Vector_base<int,std::allocator<int> >::_Vector_impl:
     _M_start = 0x3f4230,
     _M_finish = 0x3f4238,
     _M_end_of_storage = 0x3f4238
   }
 }, <No data fields>}
elem[2]: $1010 = {
 <_Vector_base<int,std::allocator<int> >> = {
   _M_impl = {
     <allocator<int>> = {
       <new_allocator<int>> = {<No data fields>}, <No data fields>},
     members of _Vector_base<int,std::allocator<int> >::_Vector_impl:
     _M_start = 0x3f42e8,
     _M_finish = 0x3f42f4,
     _M_end_of_storage = 0x3f42f4
   }
 }, <No data fields>}
Vector size = 3
Vector capacity = 4
Element type = vector<int,std::allocator<int> > *
>>>>>>cb_gdb:
Script exception: SquirrelFunction<> call failed

I did use the script provided here:
http://forums.next.codeblocks.org/index.php/topic,10667.msg73171.html#msg73171
And setup the bindings correctly, sourced the gdb script correctly, verified pvector is working and really use wxString_ToLong (which is also present - I checked that, too).

I don't exactly get what function call failed though...

Funnily, in the "watches" window I only get the "old" output...?!

Quote from: killerbot on June 15, 2009, 01:09:52 PM


QUESTION : does anyone see a negative side effect of issuing a macro replacement on those debugger init commands ?

Nice work, I'm testing it now! I'll give a report then.

Edit:
Works quite well! No side effect :D


@oBFusCATed
This is what I get to view "vv".
(http://sites.google.com/site/studycodeblocks/imagescb/vv.png)

Morten: check you script console and show the output here

ollydgb: this is a known bug, I've written about it before and it was decided that we will have the simple version (vector<int>) working first and then we'll extend it.

my "Manager::Get()->GetMacrosManager()->ReplaceMacros(init);"/ "source $DATAPATH/stl-views-1.0.3.gdb" addition works.

However the main question remains to the other developers : does anyone expect side effects.

Quote from: killerbot on June 15, 2009, 02:49:55 PM
However the main question remains to the other developers : does anyone expect side effects.

It mostly depends on whether gdb init commands may have valid $something commands that should NOT be expanded by C::B...

Quote from: mandrav on June 15, 2009, 04:03:41 PM

Quote from: killerbot on June 15, 2009, 02:49:55 PM
However the main question remains to the other developers : does anyone expect side effects.

It mostly depends on whether gdb init commands may have valid $something commands that should NOT be expanded by C::B...

We can have two edit controls. One for expanded, the other then directly passed to GDB :D

Quote from: mandrav on June 15, 2009, 04:03:41 PM

Quote from: killerbot on June 15, 2009, 02:49:55 PM
However the main question remains to the other developers : does anyone expect side effects.

It mostly depends on whether gdb init commands may have valid $something commands that should NOT be expanded by C::B...

does anyone know of such commands ?
My knowledge of gdb is not that big, so because I don't know any is not good enough for a general conclusion ;-)

source command might not support variable expansion at all:

http://sourceware.org/ml/gdb/2006-06/msg00092.html (http://sourceware.org/ml/gdb/2006-06/msg00092.html)

Quote from: killerbot on June 15, 2009, 04:19:41 PM
does anyone know of such commands ?

Quote from gdb documentation:

Quote from: gdb-docuYou can use the string '$cdir' to refer to the compilation directory (if one is
recorded), and '$cwd' to refer to the current working directory. '$cwd' is not
the same as '.'—the former tracks the current working directory as it changes
during your gdb session, while the latter is immediately expanded to the current
directory at the time you add an entry to the source path.

There seem to be some more:

Quote from: gdb documentation's index$  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
$$ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
$_ and info breakpoints . . . . . . . . . . . . . . . . . . . . 40
$_ and info line . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
$_, $__, and value history . . . . . . . . . . . . . . . . . . . . 81
$_, convenience variable . . . . . . . . . . . . . . . . . . . . . . 89
$__, convenience variable . . . . . . . . . . . . . . . . . . . . . 89
$_exitcode, convenience variable . . . . . . . . . . . . . 90
$bpnum, convenience variable . . . . . . . . . . . . . . . . . . 38
$cdir, convenience variable . . . . . . . . . . . . . . . . . . . 71
$cwd, convenience variable . . . . . . . . . . . . . . . . . . . . 71
$tpnum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
$trace_file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
$trace_frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
$trace_func . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
$trace_line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
$tracepoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Does that apply to the source command? Can you give a link for the excerpt from the gdb docs?


(gdb) source $cwd/test.gdb
$cwd/test.gdb: No such file or directory.


Quote from: oBFusCATed on June 15, 2009, 06:59:27 PM
Can you give a link for the excerpt from the gdb docs?

see GDB manual Index
http://sources.redhat.com/gdb/current/onlinedocs/gdb_40.html#cp_$ (http://sources.redhat.com/gdb/current/onlinedocs/gdb_40.html#cp_$)

Little wrap up of from what I have seen passing by in the posts :

- there are gdb commands with $variable; so CB shouldn't expand them, there are 2 cases
         + $variable is unknown to CB, will it remain $variable then
         + $variable is known to CB maybe with a different meaning then what it means to gdb
- it seems the source command might NOT support $variable [!!! or does it mean the source command does not support all $variable, but just the ones gdb knows of ??]


If the source command does not support ANY $variable at all; we can hack :-( , only replace in case of source command; but then the init commands should only consist of a source commands ...

So it seems we might have to look for another solution in case the $variable-substitution is unacceptable.

Note : the list with $variable that are supported by gdb is rather limited, so we could try it out our macro replacement until we see someone runs into trouble ;-)

But why do we care, we won't place the source stl-views.gdb command in the initial commands list.

We'll do something like:


    m_Types.Clear();
    InitializeScripting();

    if(stl_debugging_enabled)
             QueueCommand(new DebuggerCmd(this, _T("source fullpath/stl-views.gdb")));

    // pass user init-commands
    wxString init = Manager::Get()->GetConfigManager(_T("debugger"))->Read(_T("init_commands"), wxEmptyString);
    // commands are passed in one go, in case the user defines functions in there
    // or else it would lock up...
    QueueCommand(new DebuggerCmd(this, init));



So the user can't mess things up.

Quote from: oBFusCATed on June 16, 2009, 08:53:11 AM
But why do we care, we won't place the source stl-views.gdb command in the initial commands list.

We'll do something like:

Code Select Expand



    m_Types.Clear();
    InitializeScripting();

    if(stl_debugging_enabled)
             QueueCommand(new DebuggerCmd(this, _T("source fullpath/stl-views.gdb")));

    // pass user init-commands
    wxString init = Manager::Get()->GetConfigManager(_T("debugger"))->Read(_T("init_commands"), wxEmptyString);
    // commands are passed in one go, in case the user defines functions in there
    // or else it would lock up...
    QueueCommand(new DebuggerCmd(this, init));



So the user can't mess things up.

:lol:, this is better than other ways we discussed.


   if(stl_debugging_enabled)
            QueueCommand(new DebuggerCmd(this, _T("source fullpath/stl-views.gdb")));


great I will do it that way, but then we the $variable and MacroManager.

Can at this moment anyone try it out without the if test and with NO fullpath/stl-views.gdb present !! What's the outcome ?
In case there's no harm/crash when that file is not there, I can already apply this to trunk.
Later on I will added the stl-views.gdb to trunk and make sure it is copied along during the build (make/cbp[win/linux])...

Another thought that have come to my mind is that we need to skip the registration of the "Stl Vector debugger script" when the stl_debugging_enabled is false, so the user won't see the squirrel execution error or something similar.

well I would try without the enable flag at first, when it is working ok (in future that script will be present), I don't think we should make it enable/disable. Since for real debugging you want this. Other IDE's show the vectors out of the box, they also don't allow to enable/disable. We just have to make sure it does not have negative side effects ;-)

When it works this is the things to adjust in CB :
1) new debugger script
2) add the .gdb file
3) change the code to source it
...
...
4) further improve on the offered functionalities :-)

now I have something really strange.
I removed my previous code (the code from yesterday, now on my linux box), the v vector is shown (only 200 entries), but when I issue manually pvector, it claims the command is unknown. Strange ...

results of my latest experiment.

* in CB debugger settings : no source init commands anymore
* mofdified "gdb_types.script"
* stl-views-1.0.3.gdb  @ /usr/local/share/codeblocks
* code change in gdbdriver.cpp::GDB_driver::Prepare()

    // define all scripted types
    m_Types.Clear();
    InitializeScripting();

    wxString StlDebugCommand(_T("source $DATAPATH/stl-views-1.0.3.gdb"));
    Manager::Get()->GetMacrosManager()->ReplaceMacros(StlDebugCommand);
    QueueCommand(new DebuggerCmd(this, StlDebugCommand));

    // pass user init-commands


==> works, I see 200 entries of the vector v. And when I send manually the "pvector v" command to gdb, I see all 1000 entries.

One strange thing :

elem[997]: $998 = 997
elem[998]: $999 = 998
elem[999]: $1000 = 999
Vector size = 1000
Vector capacity = 1024
Element type = int *

element type --> int * , shouldn't this be int ?

Quote from: killerbot on June 16, 2009, 12:23:22 PM
results of my latest experiment.
...
==> works, I see 200 entries of the vector v. And when I send manually the "pvector v" command to gdb, I see all 1000 entries.

Hm, that's strange, what is the "[size] = ???" value in the watch?

Quote from: killerbot on June 16, 2009, 12:23:22 PM
One strange thing :

Code Select Expand


elem[997]: $998 = 997
elem[998]: $999 = 998
elem[999]: $1000 = 999
Vector size = 1000
Vector capacity = 1024
Element type = int *

element type --> int * , shouldn't this be int ?

Yes, this seems to be a bug in the script

Quote from: oBFusCATed on June 16, 2009, 12:49:20 PM

Quote from: killerbot on June 16, 2009, 12:23:22 PM
results of my latest experiment.
...
==> works, I see 200 entries of the vector v. And when I send manually the "pvector v" command to gdb, I see all 1000 entries.

Hm, that's strange, what is the "[size] = ???" value in the watch?

It doesn't show the size, shows only

• to [199] !!!
  

another experiment. I renamed (alias for remove ;-)  ) the "stl-views-1.0.3.gdb" which resided in the CB-data directory.
Result on the test case (the v vector)

* still see 200 entries !!!!!!!!!!
* pvector unknown command

When giving it back the original name :
* still see 200 entries !!!!!!!!!!
* pvector known command, and pvector v prints out all 1000 entries


Is there something magical in the debugger script ??


Question :
- can that debugger script be finalized and if possible the bug fixed where the type (int* where i should be int) be fixed, then I would commit it, together with the change in gdbdriver.cpp.
Later on I will add that 'stl-views-1.0.3.gdb file.

That is the problem line:

line 94:      whatis $arg0._M_impl._M_start

It shows what _M_start is ... an array, but do we care for it? We don't show it in the watch, but we can and we can remove the * from it in the squirrel script.

About you problems:
1. what gcc and gdb you are using? (mine gcc 4.3.3 and gdb 6.8, if you gcc is older or newer that might cause problems (I'll try to test it with my other gcc, version 4.1.2)
2. in gdb_types.script on line 169 add "Log(_T("size is " + size);" and look in the log if for "size is 200" strings.

Edit: gcc 4.1.2 works

Edit2: how many stl-views files do you have on your machine?

Quote from: oBFusCATed on June 16, 2009, 10:57:14 PM
That is the problem line:

line 94:      whatis $arg0._M_impl._M_start

Found a solution -> the line should be "whatis *$arg0._M_impl._M_start "

I've modified gdb_types.script:

1. The element type is show for vectors.
2. tointeger is replaced with wxString_ToLong, so no modifications are needed
3. removed a debugging Log call

here is the patch: http://smrt.is-a-geek.org/codeblocks/gdb_types.script (http://smrt.is-a-geek.org/codeblocks/gdb_types.script)

I found out what my issue of yesterday was, the original CB gdb_types.script was back instead of the patched one  :oops:

Just tested the latest script : everything show fines now, though it still says type is "int*"

Quote from: killerbot on June 17, 2009, 08:06:12 AM
I found out what my issue of yesterday was, the original CB gdb_types.script was back instead of the patched one  :oops:

Just tested the latest script : everything show fines now, though it still says type is "int*"

Did you change
line 94:      whatis $arg0._M_impl._M_start 
to whatis *$arg0._M_impl._M_start 

in stl-views-1.0.3.gdb.

Works fine here in TDM-GCC
(http://img30.imageshack.us/img30/6853/intc.png)
By ollydbg (http://profile.imageshack.us/user/ollydbg) at 2009-06-16

ok, I thought it was a line in our script :-)

EDIT : confirmed it works

Quote from: killerbot on June 17, 2009, 08:29:14 AM
ok, I thought it was a line in our script :-)

At first, I also thought it was in "gdb_types.script"   :D, but didn't find "Line 94" there. So...

alright ..................  THANKS to everyone who helped out in writing, testing , commenting the improvements resulting in the ability to see the contents of a vector :-)

I have committed to svn : revision 5653.


But this is just the start ... ;-)

Much much more to think of : vector of vector, list, map, showing std::string / wxString in all cases (I think now there's a difference between member variable, local variable or program argument but  I forgot why ...)

Once more : good job and cheers to all who helped out.

Great, thank you for the time too :)

Next step in my TODO (not a real todo list thought) for the debugger is  to find why it is so slow.
I've some clues and I've found some hot spots (fixed one in a previous post in this thread).
Should I start a new thread or to post here?

p.s. I'll test it myself when it reaches the wxaui branch

Hi all.

Seems there is a bug, a function name will be recognized as a vector name. See the screen shot:

(http://img35.imageshack.us/img35/7692/ccfunction.png)

OK, here is a little patch


Index: src/scripts/gdb_types.script
===================================================================
--- src/scripts/gdb_types.script        (revision 5731)
+++ src/scripts/gdb_types.script        (working copy)
@@ -164,9 +164,12 @@
     local element_type_value = vector_info_str.Mid(capacity_end_pos + 15,
                                                    vector_info_str.length() - capacity_end_pos - 15);

-    local result = _T("[size] = ") + size_value + _T("\n");
-    result += _T("[capacity] = ") + capacity_value + _T("\n");
-    result += _T("[element type] = ") + element_type_value + _T("\n");
+    local result = _T("[size] = ") + size_value + _T(",\n");
+    result += _T("[capacity] = ") + capacity_value + _T(",\n");
+    result += _T("[element type] = ") + element_type_value;
+
+    if(size > 0)
+        result += _T(",\n");

     local value_str = a_str;
     for(local item = 0; item < size; item += 1)
@@ -185,8 +188,12 @@
             local equal_pos = elem_value.Find(_T(" = "));
             if(equal_pos >= 0)
                 elem_value.Remove(0, equal_pos + 3);
+            if(item > 0)
+                result += _T(",");
             result += _T("[") + item + _T("] = ") + elem_value + _T("\n");
         }
+        else
+            break;

         value_str.Remove(0, elem_end);
     }



It does two things:
1. Add , at the end of every item/line, so the output more like the one emitted from GDB (not readly needed in trunk, but in my local patch)
2. Fixes an almost infinite loop if the vector is not initialized.



     std::vector<int> v; // <- if you break here and add v to the watches, C::B freezes, because vector.size is very big number (in my case, but it could be anything)
     v.push_back(1);



Best regards...

Quotestd::vector<int> v; // <- if you break here and add v to the watches, C::B freezes, because vector.size is very big number (in my case, but it could be anything)

the vector size should be 0, according to the standard, right ?

If you break on the next line, yes, the size should be 0...
But on the first line the c-tor have not run and the pvector command calculates the size incorrectly... don't know exactly why... 8)

Hi,

I cannot even see v[0] in debugger. I keep getting a "kernel event / debug exception message". Please see attached image.

I am using:
Windows Vista (not by my choice)
C::B 8.02
mingw 5.1.4
gdb 5.2.1-1

Any suggestions ?

Thank you in advance for your attention !

Quote from: jens on June 07, 2009, 10:12:13 AM

Quote from: ollydbg on June 07, 2009, 08:45:44 AM
I test your code, found it is even bad in my system(MinGW, WindowsXP), I can't view "v[0]".
See my screenshot

You have to use the []-operator in your program, otherwise it gets not compiled in and therefore cannot be used by gdb.

@taram:
watching the variable as array does not work here.

[attachment deleted by admin]

your gdb is way too old. Try to upgrade to for example GDB 6.8

Quote from: killerbot on September 03, 2009, 11:06:54 PM
your gdb is way too old. Try to upgrade to for example GDB 6.8

And the changesdiscussed in this thread are in trunk and not in the 8.02 release.
If you need them, you should download a recent nighly build, or you have to wait for the next release.

I will download gdb and trunk and give it a try.
Thank you very much !

Quote from: jens on September 03, 2009, 11:24:23 PM

Quote from: killerbot on September 03, 2009, 11:06:54 PM
your gdb is way too old. Try to upgrade to for example GDB 6.8

And the changesdiscussed in this thread are in trunk and not in the 8.02 release.
If you need them, you should download a recent nighly build, or you have to wait for the next release.

You might find this blog entry (http://vladimir_prus.blogspot.com/2009/06/stl-visualization.html) interesting. It's about STL Visualisation from one of the KDevelop developers.

Quote from: drac on September 21, 2009, 09:29:18 AM
You might find this blog entry (http://vladimir_prus.blogspot.com/2009/06/stl-visualization.html) interesting. It's about STL Visualisation from one of the KDevelop developers.

Thank you for the post drac, very informative. It seems that nice visualization of STL containers is finally taking its first steps to become wide available.

Quote from: ollydbg on June 07, 2009, 10:43:26 AM
Thanks Jens for your hints.

Here is a workaround.

Code Select Expand


#include <iostream>
#include <string>
#include <vector>

using namespace std;

typedef vector<string> vstr;

int main()
{
   vstr v;
   v.push_back("bla bla");
   string v0 = v[0];
   cout << "Hello world!" << endl;
   return 0;
}

I can only watch "v0" (see the screen shot)




hello, I found in the latest svn rev 5826, the debugger watch works badly with the test code above. see my screen shot. can someone find the bug? Thanks.

(http://i683.photobucket.com/albums/vv194/ollydbg_cb/2009-09-30144254.png)

I think, this is known bug... will look at it tonight

Update: yes known bug...

Here is the output of the whatis command:

> whatis v_str
type = std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >,std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >


And this line matches the regexp for std::string and so the script for std::string is used instead of the one for the vector.

Here is a patch that fixes the problem (not tested extensively)


Index: src/plugins/debuggergdb/gdb_commands.h
===================================================================
--- src/plugins/debuggergdb/gdb_commands.h      (revision 5826)
+++ src/plugins/debuggergdb/gdb_commands.h      (working copy)
@@ -702,6 +702,8 @@

             m_watch->GetSymbol(symbol);
             m_watch->GetType(type);
+            type.Trim(true);
+            type.Trim(false);
             m_Cmd = static_cast<GDB_driver*>(m_pDriver)->GetScriptedTypeCommand(type, m_ParseFunc);
             if (m_Cmd.IsEmpty())
             {
@@ -798,7 +800,7 @@
//            m_pWatch(watch)
             m_watch(watch)
         {
-            m_Cmd << _T("whatis ");
+            m_Cmd << _T("whatis &");
//            m_Cmd << m_pWatch->keyword;
             wxString symbol;
             m_watch->GetSymbol(symbol);
@@ -813,6 +815,7 @@
             // type = bool

             wxString tmp = output.AfterFirst(_T('='));
+            tmp = tmp.substr(0, tmp.length() - 1);
             // actually add this watch with high priority
//            m_pDriver->QueueCommand(new GdbCmd_Watch(m_pDriver, m_pDTree, m_pWatch, tmp), DebuggerDriver::High);
             wxString old_type;
@@ -850,6 +853,8 @@
             m_Type(w_type),
             m_Address(address)
         {
+            m_Type.Trim(true);
+            m_Type.Trim(false);
             m_Cmd = static_cast<GDB_driver*>(m_pDriver)->GetScriptedTypeCommand(w_type, m_ParseFunc);
             if (m_Cmd.IsEmpty())
             {
Index: src/scripts/gdb_types.script
===================================================================
--- src/scripts/gdb_types.script        (revision 5826)
+++ src/scripts/gdb_types.script        (working copy)
@@ -24,7 +24,7 @@
     // STL String
     driver.RegisterType(
         _T("STL String"),
-        _T("[^[:alnum:]_]*string[^[:alnum:]_]*"),
+        _T("^std::basic_string<.*>$"),
         _T("Evaluate_StlString"),
         _T("Parse_StlString")
     );
@@ -32,7 +32,7 @@
     // STL Vector
     driver.RegisterType(
         _T("STL Vector"),
-        _T("[^[:alnum:]_]*vector<.*"),
+        _T("^std::vector<(.*)>$"),
         _T("Evaluate_StlVector"),
         _T("Parse_StlVector")
     );


The patch includes a fix for another problem:

> whatis gdb_type
Attempt to take contents of a non-pointer value.
>>>>>>cb_gdb:
> whatis &gdb_type
type = const wxString &*
>>>>>>cb_gdb:

That thing is caused by the command "source stl-views-1.0.3.script", and unfortunately, I've not reported it to gdb upstream, will do so someday...
The patch evaluates the type of the address of the watched variable and then strips the * at the end of the result.

Testing is welcome.

p.s. the patch is agains the wxpropgrid_debugger branch, if you have problems applying it, I'll produce one against trunk

@oBFusCATed
Thanks, but the patch failed appling in the trunk code :(. Would you supply a patch for the trunk?

Quote from: ollydbg on October 02, 2009, 06:26:31 AM
Thanks, but the patch failed appling in the trunk code :(. Would you supply a patch for the trunk?

I believe it's for the debugging branch.

Quote from: MortenMacFly on October 02, 2009, 06:31:06 AM

Quote from: ollydbg on October 02, 2009, 06:26:31 AM
Thanks, but the patch failed appling in the trunk code :(. Would you supply a patch for the trunk?

I believe it's for the debugging branch.

Thanks for the hint, Yes, he said:

Quotep.s. the patch is agains the wxpropgrid_debugger branch, if you have problems applying it, I'll produce one against trunk

:D

Quote from: ollydbg on October 02, 2009, 06:37:05 AM
Thanks for the hint, Yes, he said:

Quotep.s. the patch is agains the wxpropgrid_debugger branch, if you have problems applying it, I'll produce one against trunk

:D

Nargh... it's very early in the morning here... ;-)