see content of a vector in debugging

[ollydbg]

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

[killerbot]

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

[oBFusCATed]

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.

[ollydbg]

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.

[killerbot]

Code Select Expand


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

[oBFusCATed]

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.

[killerbot]

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

[killerbot]

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

[killerbot]

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

Code Select Expand


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

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 ?

[oBFusCATed]

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?

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

[killerbot]

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

[killerbot]

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.

[oBFusCATed]

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?

[oBFusCATed]

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 "

[oBFusCATed]

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