> print m_wireLen
[debug]> print m_wireLen
[debug]$1 = 193.59999999999999
[debug]>>>>>>cb_gdb:
$1 = 193.59999999999999
I've been experimenting with the debugger lately and the following issues(bugs?) and questions arose regarding my usage:From the document: https://sourceware.org/gdb/onlinedocs/gdb/Mode-Options.html
1- I remember a setting where the debugger command line parameters could be edited a couple of versions(years?) ago but I can no longer find that setting except an empty argument setting. The reason that I look for that setting is to get rid of the '-nx' argument as I want gdb to automatically load stl pretty-printers for the compiler I use for the project. Why is that argument hardcoded in the first place? Some incompatibility with cb's interface, secuity or some other reason? I can't use the initialization commands on debugger settings because I have many different mingw installations to point to each compiler's own stl pretty-printers.
You can run GDB in various alternative modes—for example, in batch mode or quiet mode.I think we use the nx option here is that C::B need to configure GDB manually, such as C::B need to change the prompt to something like ">>>>>>cb_gdb", or other things, so if the gdbinit is automatically run when GDB started, C::B may not work correctly when communicated with GDB.
-nx
-n
Do not execute commands found in any initialization file. There are three init files, loaded in the following order:
system.gdbinit
This is the system-wide init file. Its location is specified with the --with-system-gdbinit configure option (see System-wide configuration). It is loaded first when GDB starts, before command line options have been processed.
~/.gdbinit
This is the init file in your home directory. It is loaded next, after system.gdbinit, and before command options have been processed.
./.gdbinit
This is the init file in the current directory. It is loaded last, after command line options other than -x and -ex have been processed. Command line options -x and -ex are processed last, after ./.gdbinit has been loaded.
For further documentation on startup processing, See Startup. For documentation on how to write command files, See Command Files.
2- I'm getting a double output on the debugger tab on 'logs & others', one preceded with '[debug]' and one not preceded as below:Intended, the line begin with [debug] is the raw message sent from GDB, you can disable it by uncheck the "Full (debug) log" option in the Debugger's setting dialog, in common panel.CodeIs that intended, bug and/or configurable?> print m_wireLen
[debug]> print m_wireLen
[debug]$1 = 193.59999999999999
[debug]>>>>>>cb_gdb:
$1 = 193.59999999999999
This could be a feature request, but I don't need this feature, because when debugging, I always add some C++ style comments when I step over some codes. :D
3- Is it possible to prevent the editor from editing during a debugging session or can it be implemented without much effort? I think that would be a nice feature if it that was possible as I sometimes try to edit the code during debugging (my bad ;)).
Win7 x64
How do you switch from different GDBs? Do you have many Config file settings for each GDB under the GDB setting dialog?Yes, I have different config settings for different architectures that use specific gdbs built for them. But the problem here is not the embedded gdbs but different mingw versions I have. I even use tdm for cb and only for cb. I have only one debugger config for all my mingw installations and I couldn't find a suitable and proper way (that is the least error-prone way) to load the stl pretty-printers for the target compiler version (or type). The reasons behind these many different mingw installations are:
(except for the debugger jumping to the wrong lines).That is the exact reason why I need the editor disabled. Can someone please guide me if that's possible by tweaking the code if not that hard?
Nevertheless I believe the old way as I recall it (command line arguments were editable in the 'arguments' editbox in 'debugger options' defaulting to the hardcoded ones) were better.I don't think C::B has ever had such a feature. But if you provide a patch which adds a setting to enable/disable loading of .gdbinit I'll happily apply it.
Yes, I have different config settings for different architectures that use specific gdbs built for them. But the problem here is not the embedded gdbs but different mingw versions I have. I even use tdm for cb and only for cb. I have only one debugger config for all my mingw installations and I couldn't find a suitable and proper way (that is the least error-prone way) to load the stl pretty-printers for the target compiler version (or type). The reasons behind these many different mingw installations are:
-iex "set auto-load safe-path /", the python script can be loaded once the libopencv_core246d.dll is loaded.
@ollydbg: Thanks for the info, much appreciated. Out of curiosity what pretty-printers do you use for OpenCV? I didn't know there existed any!There are many: renatoGarcia/gdb-imshow (https://github.com/renatoGarcia/gdb-imshow) and his recent post: Visualizing OpenCV Images on GDB (http://renatogarcia.blog.br/en/posts/visualizing_opencv_images_on_gdb.html)
I don't think so. It should be pretty easy to add. Almost all of the code should be there you just have to re-arrange it a bit. :)'Easy for you' means at most 'possible' for me btw. ;)
plugins\debuggergdb\debuggergdb.cpp
void DebuggerGDB::OnWatchesContextMenu(wxMenu &menu, const cbWatch &watch, wxObject *property, int &disabledMenus)
idMenuWatchDereferencesrc\watchesdlg.cpp