Author Topic: About cb's debugger  (Read 16367 times)

Offline scarphin

  • Lives here!
  • ****
  • Posts: 644
About cb's debugger
« on: November 07, 2014, 02:53:40 pm »
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

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5915
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: About cb's debugger
« Reply #1 on: November 07, 2014, 03:18:29 pm »
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
Quote
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?


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

Quote

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.  :D
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: About cb's debugger
« Reply #2 on: November 07, 2014, 08:20:16 pm »
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).
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline scarphin

  • Lives here!
  • ****
  • Posts: 644
Re: About cb's debugger
« Reply #3 on: November 07, 2014, 10:15:45 pm »
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?

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: About cb's debugger
« Reply #4 on: November 08, 2014, 12:56:42 am »
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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline scarphin

  • Lives here!
  • ****
  • Posts: 644
Re: About cb's debugger
« Reply #5 on: November 08, 2014, 06:24:03 pm »
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?

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: About cb's debugger
« Reply #6 on: November 09, 2014, 12:51:56 am »
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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline scarphin

  • Lives here!
  • ****
  • Posts: 644
Re: About cb's debugger
« Reply #7 on: November 09, 2014, 09:52:24 am »
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.
« Last Edit: November 09, 2014, 10:00:51 am by scarphin »

Offline scarphin

  • Lives here!
  • ****
  • Posts: 644
Re: About cb's debugger
« Reply #8 on: November 09, 2014, 11:19:15 am »
Here is a patch to only enable/disable the '-nx' parameter.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: About cb's debugger
« Reply #9 on: November 09, 2014, 02:16:26 pm »
In svn...thanks for the contribution.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline scarphin

  • Lives here!
  • ****
  • Posts: 644
Re: About cb's debugger
« Reply #10 on: November 11, 2014, 05:01:30 pm »
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?

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: About cb's debugger
« Reply #11 on: November 11, 2014, 08:50:22 pm »
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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline scarphin

  • Lives here!
  • ****
  • Posts: 644
Re: About cb's debugger
« Reply #12 on: November 12, 2014, 01:15:09 am »
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.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5915
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: About cb's debugger
« Reply #13 on: November 12, 2014, 04:00:13 am »
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
Quote
-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.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline scarphin

  • Lives here!
  • ****
  • Posts: 644
Re: About cb's debugger
« Reply #14 on: November 12, 2014, 10:53:51 am »
@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!