see content of a vector in debugging

[killerbot]

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"."
"

[oBFusCATed]

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)

Code

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.

[ollydbg]

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:

[killerbot]

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

[ollydbg]

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.

Code

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

[killerbot]

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

[cacb]

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

Code

> 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?

[oBFusCATed]

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.

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)

[ollydbg]

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



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?

Here is my squirrel log output:

Code

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.


 

[oBFusCATed]

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)

Code

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

[ollydbg]

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

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

[oBFusCATed]

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

[killerbot]

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 !!!

[oBFusCATed]

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

[MortenMacFly]

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