see content of a vector in debugging

[ollydbg]

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

[killerbot]

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)

[oBFusCATed]

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

[ollydbg]

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 :

Code Select Expand


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)

[killerbot]

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

Code Select Expand

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

Code Select Expand

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

[MortenMacFly]

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

[ollydbg]

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


@oBFusCATed
This is what I get to view "vv".

[oBFusCATed]

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.

[killerbot]

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.

[mandrav]

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

[ollydbg]

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

[killerbot]

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 ;-)

[oBFusCATed]

source command might not support variable expansion at all:

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

[Jenna]

does anyone know of such commands ?

Quote from gdb documentation:

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

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

[oBFusCATed]

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

Code Select Expand


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