User forums > Using Code::Blocks

see content of a vector in debugging

<< < (16/26) > >>

ollydbg:

--- Quote from: MortenMacFly on June 15, 2009, 12:09:24 pm ---
--- Quote from: oBFusCATed on June 15, 2009, 09:06:48 am ---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)

--- End quote ---
Sorry for the inconvenience. I didn't think this would cause such trouble... :(

--- End quote ---
I like wxString_ToLong too 8)

killerbot:

--- Quote from: oBFusCATed on June 15, 2009, 12:09:01 pm ---
--- Quote from: killerbot on June 15, 2009, 11:23:57 am ---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"

--- End quote ---

Try to use full path or path relative to the project's root

--- End quote ---

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: ---APPDATA=F:\cb_svn\src\output\AppData

--- End code ---

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: ---    // 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 this would result into :

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

--- End code ---


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 ?

Navigation

[0] Message Index

[#] Next page

[*] Previous page