User forums > Using Code::Blocks

see content of a vector in debugging

<< < (19/26) > >>

ollydbg:

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

--- End quote ---

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


--- End code ---

So the user can't mess things up.

ollydbg:

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


--- End code ---

So the user can't mess things up.

--- End quote ---

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

killerbot:

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

--- End code ---

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

Navigation

[0] Message Index

[#] Next page

[*] Previous page