About cb's debugger

[scarphin]

I've been experimenting with the debugger lately and the following issues(bugs?) and questions arose regarding my usage:
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.
2- I'm getting a double output on the debugger tab on 'logs & others', one preceded with '[debug]' and one not preceded as below:

Code

> print m_wireLen

[debug]> print m_wireLen
[debug]$1 = 193.59999999999999
[debug]>>>>>>cb_gdb:

$1 = 193.59999999999999

Is that intended, bug and/or configurable?
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

[ollydbg]

I've been experimenting with the debugger lately and the following issues(bugs?) and questions arose regarding my usage:
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.

From the document: https://sourceware.org/gdb/onlinedocs/gdb/Mode-Options.html

You can run GDB in various alternative modes—for example, in batch mode or quiet mode.

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

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.

How do you switch from different GDBs? Do you have many Config file settings for each GDB under the GDB setting dialog?

2- I'm getting a double output on the debugger tab on 'logs & others', one preceded with '[debug]' and one not preceded as below:

Code

> print m_wireLen

[debug]> print m_wireLen
[debug]$1 = 193.59999999999999
[debug]>>>>>>cb_gdb:

$1 = 193.59999999999999

Is that intended, bug and/or configurable?

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.

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

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. 

[oBFusCATed]

1. I don't know why this is done, but is been this way almost forever
2. Yes, this is the way it should look like. If you want to stop it disable the debug/full logging in the debugger setting.
3. I don't think this is useful, I always turn this option of in the Visual studio. Nothing bad will happen if you edit the source while debugging (except for the debugger jumping to the wrong lines).

[scarphin]

Thanks for the replies.
1- For my usage, gdbinit will only load the stl pretty-printers, I'm not sure how will this interract with cb's configuration of gdb. I might be wrong but if one needs to configure gdb from the command line with the same settings cb uses, I think gdbinit should be the proper way to load the pretty-printers. I guess I'll disable '-nx' from the code to see if everything works ok and I'll report it if anyone's interested. 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.

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:
a- Different libraries I use (qt, opencv, boost, eigen, mathgl even wxwidgets etc...) compiled with different compiler versions,
b- Lack of availability of prebuilt versions of these libraries for every compiler version,
c- My computer being way to slow to compile these when I need them.
So I switch from one version to another version of mingw according to the mingw versions of libraries used to compile them. Quite complicated unfortunately.

2- Problem solved.

3-

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

[oBFusCATed]

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.

[scarphin]

1- It maybe me recalling it incorrectly. I attached a patch to enable/disable the auto-inclusion of hardcoded parameters with a 'checkbox'. The patch also inserts these parameters to the 'arguments' textbox when disabled to offer the user an option to modify them. No default functionality is lost.

3- Any hints with disabling the editor during debugging?

[oBFusCATed]

Your patch is definitely unacceptable.
Why are you disabling the -quiet and -fullname?
Why do you want to append some options to the args list?
If you remove these two, I'll push the patch.

For the editors, take a look at the editormanager and cbeditor classes.

[scarphin]

Nothing is disabled, the patch removes the hardcoded arguments and inserts them into the user arguments to be executed and warns the user that these parameters may be vital to modify. The user may opt to modify them but if (s)he doesn't they are still executed. I was thinking in general but if you're extremely sure that '-quiet' and '-fullname' won't ever need modification, I'll provide a patch to just make '-nx' optional.

Edit: I haven't experienced any problems regarding to the autoloading of 'gdbinit', I'm not an advanced user though. I'll take a look at the files you pointed to disable the editor, thanks.

[scarphin]

Here is a patch to only enable/disable the '-nx' parameter.

[oBFusCATed]

In svn...thanks for the contribution.

[scarphin]

In pursuit of the 'additional shell commands' bug discussed below, I tried to see if they are actually executed by gdb.
http://forums.codeblocks.org/index.php/topic,19279.0.html
In file 'src/plugins/debuggergdb/gdb_driver.cpp' and inside the 'if' clause at line 285, I don't see any code to execute the 'additional shell commands' although they might be executed somewhere else. Assuming they are not executed elsewhere, this does look like they are not implemented at all and with my limited understanding of debuggers code structure, I don't see a reason why they shouldn't be implemented inside that 'if' clause either. I'll check that out when I find the time but again with my limited knowledge am I in the wrong direction or is there anything else to consider?

[oBFusCATed]

I doubt they are executed anywhere else. So if you can provide a tested patch this will be very welcome. I'm not sure when I'll find the time to fix this long standing problem.

[scarphin]

I added 'additional shell commands' code, tested and additional shell commands before and after both work fine. Patch is attached. I'm on Win7, I'm pretty sure they will on linux but they might need testing.

[ollydbg]

Hi, scarphin.

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:

You can use the auto-load feature of GDB to load the pretty printer for a specify dll.
For example, I am using OpenCV, and I have a dll named libopencv_core246d.dll. And I have put a file libopencv_core246d.dll-gdb.py in the same folder, so that if you enable the safe auto load path by the gdb command

-iex "set auto-load safe-path /"

, the python script can be loaded once the libopencv_core246d.dll is loaded.

I'm not sure it works for a release version of dll, such as libopencv_core246.dll, maybe, when gdb don't find debug information in the dll, it don't search for the associated python scripts.

[scarphin]

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

[ollydbg]

@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 and his recent post: Visualizing OpenCV Images on GDB
I'm also implementing one(but not finished yet, once finished, I will released it under some free software license), see related discussion: GDB cv::Mat python object issue when debugging a c++ program and Non blocking pyplot GUI for GDB python pretty printer.

With python support, I think we can do everything when debugging under GDB.

[scarphin]

Wow, those links are extremely useful. I always use 'imshow' to see the images but it's quite hard to debug using 'imshow'. But with those python scripts I think debugging opencv will be much easier. Thanks again for the information.

[oBFusCATed]

scarphin: Your patch is committed thanks for it...

[scarphin]

Glad it worked.

Another issue: I can't dereference a function argument (pointer type) in the 'watch list->function arguments'. I can dereference the same function argument if I add it to the watch list manually though. Is this a limitation of automatic function arguments, intended or a bug?

[oBFusCATed]

Intended. Or missing feature actually.
If you want to add this feature I'll happily look at the resulting patch

[scarphin]

Ok, thanks for the info. I believe it will be very challenging for me regarding my skills but I'll give it a try.

[oBFusCATed]

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.

[scarphin]

Sorry for the late reply, I don't and won't have access to my computer for a couple of days. I think the problem with dereferencing the function arguments or locals is they are implemented as properties of 'function arguments' and 'local variables' special watches respectively. So when one tries to dereference them cb acts like the right click menu for a property is clicked. I'm not sure how to fix that in a proper way. What I can come up with is to implement them as normal watches not properties of 'function arguments' and 'locals' but I can't find for sure where they are implemented in the code. Maybe it will be easier for someone more skilled than me to fix that. Any help or a better solution?

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.

[scarphin]

I can't find where in the source the locals and function arguments are inserted into the watch dialog, can anyone point me to the part of the code in question?

[Bat]

Here few entry point for searching

Add of "Dereference" context menu

Code

plugins\debuggergdb\debuggergdb.cpp
void DebuggerGDB::OnWatchesContextMenu(wxMenu &menu, const cbWatch &watch, wxObject *property, int &disabledMenus)

Entry is registered with a standard item,

Code

idMenuWatchDereference

that is defined in EVT_MENU at top of file

"Locals" and "functions arguments" are inserted in DebuggerGDB::DoWatches as special entries


Handling of watches (standard to all debugger plugins)

Code

src\watchesdlg.cpp

[oBFusCATed]

Hm, as I think about it more, I don't think it will be possible to implement it, because the info locals and info args commands don't print the types of the variables.
The type is used to decide if the variable is a pointer or not, and so controls if the dereference menu item should be shown or not.

You can always prove me wrong of course. 

[scarphin]

@bat: Thnx for the help but that wasn't what I was looking for.

@obfuscated: What I was going to try was to add them as normal watches not properties of 'Locals'/'Function arguments' so the right click menu would contain (to my understanding) a 'dereference' option. If you say the type information won't be available when implemented that way, well that's out of my league. It would be nice to have that feature implemented somehow though.

[oBFusCATed]

One thing that would be easy to implement it right click menu to add the selected local/arg variable as normal watch.
I don't think it will be easy to add the locals/args as separate watches. Also it will slow down stepping pretty significantly.