Showing vector elements in debugger

[oBFusCATed]

And "test[1]" is not a too complex expression ...

Why do you think this is not a complex expression?
Are you sure you're python scripts match the version of you c++ standard library you're using?

[nji]

No, I'm not sure at all if anything matches together. I just downloaded the "updates" as pointed to in http://forums.codeblocks.org/index.php/topic,21998.msg149716.html#msg149716.
Sigh ... do you need any more explanation why M$'s comm. ed. is so popular?
Do you want my opinion about a development chain where nothing fits together, and debugging vector[1] is impossible?
...
OK, if the python scripts have to match the c++ standard library ... I moved the original scripts (from mingw 4.9.2) back.
Effect: same effect.
Does gdb has to match too?
This becomes ridiculous and frustrating.

[oBFusCATed]

M$'s comm. ed.

Are you talking about visual studio?

Do you want my opinion about a development chain where nothing fits together, and debugging vector[1] is impossible?

This won't change anything. Patches improve the situation. Ranting is just ranting.

OK, if the python scripts have to match the c++ standard library ... I moved the original scripts (from mingw 4.9.2) back.
Effect: same effect.

Yes, they need to match, because the standard library changes its internals and the python script need to know the internals of the library.

Does gdb has to match too?

Only to the point that the Python APIs used in the scripts are compatible. But I think the gdb's python apis are relatively stable.

@bluehazzard: Does this example work for you?

[BlueHazzard]

ok, here is my full working setup:
gcc: TDM-gcc 4.9.2
gdb: http://sourceforge.net/projects/gdbmingw/files/gdb2016-01-30.zip/download

from ollydbg in http://forums.codeblocks.org/index.php/topic,11301.0.html

You must install Python 2.7.5 release 32bit version on your system, as my build was linked to this python release.

you need to install python 2.7.5: https://www.python.org/download/releases/2.7.5/

stl script in TDM-GCC-32\share\gcc-4.9.2\python\libstdcxx\v6 printers.py and xmethods.py are attached. I don't remember where i got them from (probably the svn tree)

i use a gdb file in TDM-GCC-32\bin\stl.gdb :

Code

python
import sys
sys.path.insert(0, 'TDM-GCC-32\share\gcc-4.9.2\python')
from libstdcxx.v6.printers import register_libstdcxx_printers
#register_libstdcxx_printers (None)
end

and in the debugger settings:
Settings->Debugger->GDB->Default->initialization commands:

Code

source TDM-GCC-32\bin\stl.gdb

if i debug this code:

Code

#include <iostream>
#include <vector>

using namespace std;

int main()
{
    vector<double> test;
    test.push_back( 22.44 );
    test.push_back( 1.3795933261199322e-306 );

    cout << "Hello world!" << endl;
    return 0;
}

i get this debugger log, and all works fine:

Code

Active debugger config: GDB/CDB debugger:Default
Building to ensure sources are up-to-date
Selecting target: 
Debug
Adding source dir: ****\
Adding source dir: ****\
Adding file: ****\bin\Debug\rerreer.exe
Changing directory to: ****.
Set variable: PATH=#######

[debug]Command-line: TDM-GCC-32\bin\gdb.exe -fullname -quiet -nx -args ****bin/Debug/rerreer.exe
[debug]Working dir : ****

Starting debugger: TDM-GCC-32\bin\gdb.exe -fullname -quiet -nx -args ****bin/Debug/rerreer.exe
done

[debug]> set prompt >>>>>>cb_gdb:
[debug]Skip initializing the scripting!

Setting breakpoints

[debug]Reading symbols from ****bin/Debug/rerreer.exe...done.
[debug](gdb) >>>>>>cb_gdb:
[debug]> show version
[debug]GNU gdb (GDB) 7.10.50.20160130-git
[debug]Copyright (C) 2016 Free Software Foundation, Inc.
[debug]License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
[debug]This is free software: you are free to change and redistribute it.
[debug]There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
[debug]and "show warranty" for details.
[debug]This GDB was configured as "mingw32".
[debug]Type "show configuration" for configuration details.
[debug]For bug reporting instructions, please see:
[debug]<http://www.gnu.org/software/gdb/bugs/>.
[debug]Find the GDB manual and other documentation resources online at:
[debug]<http://www.gnu.org/software/gdb/documentation/>.
[debug]For help, type "help".
[debug]Type "apropos word" to search for commands related to "word".
[debug]>>>>>>cb_gdb:
[debug]> set confirm off

Debugger name and version: GNU gdb (GDB) 7.10.50.20160130-git

[debug]>>>>>>cb_gdb:
[debug]> set width 0
[debug]>>>>>>cb_gdb:
[debug]> set height 0
[debug]>>>>>>cb_gdb:
[debug]> set breakpoint pending on
[debug]>>>>>>cb_gdb:
[debug]> set print asm-demangle on
[debug]>>>>>>cb_gdb:
[debug]> set unwindonsignal on
[debug]>>>>>>cb_gdb:
[debug]> set print elements 200
[debug]>>>>>>cb_gdb:
[debug]> set new-console on
[debug]>>>>>>cb_gdb:
[debug]> set disassembly-flavor att
[debug]>>>>>>cb_gdb:
[debug]> catch throw
[debug]Catchpoint 1 (throw)
[debug]>>>>>>cb_gdb:
[debug]> source TDM-GCC-32\bin\stl.gdb
[debug]> directory ****
[debug]>>>>>>cb_gdb:
[debug]> break "****main.cpp:12"
[debug]Source directories searched: ****/rerreer;$cdir;$cwd
[debug]>>>>>>cb_gdb:Breakpoint 2 at 0x4013ce: file ****\main.cpp, line 12.

Source directories searched: ****/rerreer;$cdir;$cwd

[debug]> run
[debug]>>>>>>cb_gdb:Starting program: ****\bin\Debug\rerreer.exe 
[debug]> info frame

Child process PID: 7276

[debug][New Thread 7276.0x16ec]
[debug]Breakpoint 2, main () at ****\main.cpp:12
[debug]****\main.cpp:12:187:beg:0x4013ce
[debug]>>>>>>cb_gdb:Stack level 0, frame at 0x28ff30:

At ****\main.cpp:12

[debug]> whatis test
[debug] eip = 0x4013ce in main (****\main.cpp:12); saved eip = 0x4010fd
[debug] source language c++.
[debug] Arglist at 0x28ff18, args: 
[debug] Locals at 0x28ff18, Previous frame's sp is 0x28ff30
[debug] Saved registers:
[debug]  ebx at 0x28ff0c, ebp at 0x28ff18, esi at 0x28ff10, edi at 0x28ff14, eip at 0x28ff2c
[debug]>>>>>>cb_gdb:type = std::vector<double>
[debug]> output test
[debug]>>>>>>cb_gdb:
[debug]> whatis test[2]
[debug]std::vector of length 2, capacity 2 = {22.440000000000001, 1.3795933261199322e-306}>>>>>>cb_gdb:type = double
[debug]> output test[2]
[debug]>>>>>>cb_gdb:
[debug]> whatis test[0]
[debug]-2.5301706769843864e-098>>>>>>cb_gdb:type = double
[debug]> output test[0]
[debug]>>>>>>cb_gdb:
[debug]> whatis test[1]
[debug]22.440000000000001>>>>>>cb_gdb:type = double
[debug]> output test[1]
[debug]>>>>>>cb_gdb:
[debug]> bt 30
[debug]1.3795933261199322e-306>>>>>>cb_gdb:#0  main () at ****\main.cpp:12
[debug]>>>>>>cb_gdb:

i know this is all frustrating, and as soon as we will find out what goes wrong i will try to create a wiki entry with the exact steps...

[Edit:] NOTE: i have altered all paths, so you have to use absolute paths for all path entries. I also don't use any white spaces or non ASCII characters in my paths

[Edit:] add python download link

[ollydbg]

@BlueHazzard, good job and good tutorial.

[nji]

Yes, I do agree! 

So I took my clean c:b 16.01 (with mingw 4.9.2) and retraced your steps.

First try I left the two original files __init__.py (empty) and printers.py.
As I don't have any stl.gdb file anywhere, I inserted the init code as
"Debugger initialization commands"

Code

python
import sys
sys.path.insert(0, 'C:\Program Files (x86)\CodeBlocks\MinGW\share\gcc-4.9.2\python/libstdcxx/v6')
from printers import register_libstdcxx_printers
register_libstdcxx_printers (None)
end

Also "Enable watch script" disabled.

When I try to debug your code it doesn't work:
Message (translated from German by me):

Code

"gdb.exe - systemerror.
The program cannot be startet, as python27.dll is missing on your computer."

And indeed, I searched for the file: it is nowhere.
Looks like you have done some extra steps ... ?
(I checked: When I change back to original gdb debugger works fine again.
Without pretty printing of course)

[BlueHazzard]

from ollydbg in http://forums.codeblocks.org/index.php/topic,11301.0.html

You must install Python 2.7.5 release 32bit version on your system, as my build was linked to this python release.

so you need to install python 2.7.5
I probably had installed it previously...

[nji]

In the link you provided in http://forums.codeblocks.org/index.php/topic,21998.msg149716.html#msg149716
it was not necessary to install python?
As the the missing file is included in there...
But ... as it seems ... that way didn't work ... at least at me.
What I mean: If one installs c:b ... is it necessary to install python before, if gdb is python-enabled?
(To my experience it's best to install as few as possible)
Questions over questions ... 

[BlueHazzard]

What I mean: If one installs c:b ... is it necessary to install python before, if gdb is python-enabled?

codeblocks does not need python... gdb needs python. This are two separate projects. Codeblocks can not provide support for all things... And if codeblocks has to ship dlls for all possibly needed additional programs, the purpose of dlls is circumvented...

I had python installed previously for using it to program in python, so i don't had to install it. A bit of self thinking and googling solves this kind of problems in 2 sek.

i updated my previous post.

[nji]

You're so right ... and a bit of self thinking and read what I wrote would keep you from being impolite.

[BlueHazzard]

But ... as it seems ... that way didn't work ... at least at me.

does it work after installing python? If not what is the error you are getting?

[nji]

I won't install python. (Reason for this ... see above).

If someone is trying to get rid of the M$ trap, you may tell him:
No, the debugger doesn't work at codeblock.
This is not our problem.
But you can try to install this & that to your system, and see what it makes to it.

This thinking is exactly what makes M$ success. Greetings.

[BlueHazzard]

@ollydbg:
does it make sense to provide the python dll within your gdb download? Are there dependencies to other dlls (from python27.dll to other) too?
What if there is a python27.dll in the bin folder and one in the system folder? What version gets picked?
I see the frustration of the OP and i would like to do something against it...

[nji]

Thank you for that. 

You're right ... frustration ... but not mainly because I can't see this f*** test[1],
but because it seems so clear to me that it has to be some kind of "convenient" to have any chance.
That was (to my opinion) the ONLY reason why M$ overcame Linux in the 80ies.
Not quality (for sure), not safety (2xsure), ... but convenience.

See it as learning.. If you know the things behind all this you will get a better programmer

I firmly disagree to that.
I want to focus on my problem, not on the internals of my tools.
To my experience it even keeps you from doing good work if you have to dig too much into side things.

[Edit: Not to talk about the deterent effect on potential beginners]

Please take this thread as my (small) contribution to help.
As long as I'm a newbie.

[Edit:
P.S.
Still one can use printf for debugging.
In times when Radeon RX 470 GPUs are used for making Bitcoins,
with c:b we are practicising ... no, not agile ...but ... amish software development and toolchain config.   
SCNR. NOT meant to offend.]

[nji]

One should hope, that in the next release of c:b debugging will work.
As in the actual one (16.01) in the packaged mingw the gdb was not python enabled, but in the actual tdm package it is, with everything included that is in need.
So hopefully the devolopers of c:b will have a look that this chain will work, without having to install this and that, patching here and there.
Does this message reach them?