Unable to get C++ gdb pretty printing going

[robinwhittle]

I have installed Codelite 5.4 with MinGW/TDD compiler, debugger, etc. as part of the one installation file, on a 64 bit Windows 7 machine. All is well. My test program is a C++ command line program with some containers library objects. It compiles and debugs normally.

I followed the steps at:

http://codelite.org/LiteEditor/GdbPrettyPrinting

(last update 2013-10-26) exactly, including downloading the specified new version of gdb (I am not sure of its version, from: http://sourceforge.net/projects/gdbming ... p/download ), and copying its three directories directories to C:\GDB-7.4.5\ to match the path in the screenshot of the Debugger Settings dialogue box. I followed all the instructions on that page, including installing Python 2.7.5 in the directory its installer suggested: C:\Python27\ .

When I try to debug a program, some things flash and nothing happens. I think the application DOS box appears briefly. I see no error messages. I rebooted, but the same thing happened. I noticed that the debugger path settings and the selection to enable pretty printing were not retained after I closed and opened Codelite. I can't find a log of what went wrong.

In Settings > Debugger Settings > GNU gdb debugger > Misc I set the flags for logging and showing the terminal, but I am not sure where to look for such logs.

I triple checked that I followed all the instructions. Maybe these instructions worked for a previous version of Codelite, gcc, gdb etc. Does the Python installation add something to the path env var? How does this gdb know where to run the Python interpreter?

Thanks for Codelite!

- Robin

[eranif]

Hello Robin,

To make sure that you have python enabled, do this:
Settings->GDB settings and tick the option 'enable python pretty printing

Next,
Settings->GDB settings-> startup commands

You should see a python code there.

Also enable the 'Settings->GDB Settings->Misc->Enable debugger full logging'

Try to debug something and paste the debugger output (from the 'Debugger View->Output' tab)
Eran

[robinwhittle]

Hi Eran,

I tried exactly the same procedure on a 32 bit Windows XP machine. The only difference is that I used the 32 bit Python installer. I was able to use the debugger, stop at a breakpoint and get some kind of pretty printing. For instance in a map I was able to see pairs of items for each element of the map. The key was a string, which was clearly visible. The value was a deque, and there was no way of seeing what was in each deque. I haven't looked at other container objects yet. I am not sure where to find descriptions of what this pretty printing should do, or where the actual Python code comes from or is located in a working system.

When I made the configuration for the new debugger (Settings > GDB Settings > GNU gdb debugger > General) such as the path for the debugger, and enabling pretty printing, I found a settings file at: C:\Documents and Settings\Robin\Application Data\CodeLite\config\debuggers.xml with these settings. When I closed Codelite, this remained. When I started Codelite again, it was as if these settings had not been made. When I closed Codelite a second time, a new debuggers.xml was written without the changes I had made. I suspect this is a bug in Codelite - not reading this xml file - at least for Windows, which is not necessarily related to the problem I have on 64 bit Windows 7 with not being able to debug at all, and as I mentioned having these settings disappear when Codelite is started again.

You wrote:

> Also enable the 'Settings->GDB Settings->Misc->Enable debugger full logging'
>
> Try to debug something and paste the debugger output (from the 'Debugger View->Output' tab)

On the 64 bit Windows 7 machine, there was no such Debugger View. Maybe one flashed up for a split second, but it disappeared. I tried again just now with a C++ GCC console new project, with a breakpoint in the Hello World program which the project starts with. The program runs on its own OK and debugs with the normal debugger, but when I set up the new debugger for pretty printing, exactly following the steps of the webpage (mentioned in my first message and below), I just get this flash of activity and no Debugger View. Is there somewhere I can look to find a log file which might tell my why gdb doesn't run properly?

I haven't looked into the nature of the debugger the page: http://www.codelite.org/LiteEditor/GdbPrettyPrinting suggests I download: http://sourceforge.net/projects/gdbming ... p/download . While this page gave an example of copying that debugger and its directories to C:\GDB-7.4.5\, I noticed in the Output tab of the Debugger window, that gdb identified itself as "GNU gdb (GDB) 7.6.50.20131004-cvs".

Do I need a 64 bit gdb to run and debug the 64 bit program on the Windows 7 machine?

Can you point me to where I can get a suitable gdb (package or sources) for this C++ pretty printing, for 64 bit Linux? (I am running Debian 7 with GCC 4.7.1 and I have another machine running Debian 8 Testing since this seemed like the easiest way of getting GCC 4.8.1.)

Are the pretty printing functions contained within the debugger I installed on Windows or are they part of Codelite? I see there are some Python files which look like they might be involved in two different locations:

C:\Documents and Settings\Robin\Application Data\CodeLite\gdb_printers (and sub-directories)
C:\GDB-7.4.5\share\gdb\python\gdb

- Robin

[eranif]

I tried exactly the same procedure on a 32 bit Windows XP machine. The only difference is that I used the 32 bit Python installer. I was able to use the debugger, stop at a breakpoint and get some kind of pretty printing. For instance in a map I was able to see pairs of items for each element of the map. The key was a string, which was clearly visible. The value was a deque, and there was no way of seeing what was in each deque. I haven't looked at other container objects yet. I am not sure where to find descriptions of what this pretty printing should do, or where the actual Python code comes from or is located in a working system.

Yes, this is the pretty printer in work ( you can always update the scripts by installing newer versions from the internet)

When I made the configuration for the new debugger (Settings > GDB Settings > GNU gdb debugger > General) such as the path for the debugger, and enabling pretty printing, I found a settings file at: C:\Documents and Settings\Robin\Application Data\CodeLite\config\debuggers.xml with these settings. When I closed Codelite, this remained. When I started Codelite again, it was as if these settings had not been made. When I closed Codelite a second time, a new debuggers.xml was written without the changes I had made. I suspect this is a bug in Codelite - not reading this xml file - at least for Windows, which is not necessarily related to the problem I have on 64 bit Windows 7 with not being able to debug at all, and as I mentioned having these settings disappear when Codelite is started again

This bug was introduced in 5.4 and was already reported and fixed.
https://github.com/eranif/codelite/comm ... daa6201fc0
To fix this: open the file "debuggers.xml" under CODELITE_INSTALLTION_FOLDER\config\debuggers.xml and update its property to "5.4"

On the 64 bit Windows 7 machine, there was no such Debugger View.

If you can't see it, try this:
- Perspetive->debugger.layout
- OR 'View->Debugger Pane'

and then look at the 'Output' tab in this pane

Do I need a 64 bit gdb to run and debug the 64 bit program on the Windows 7 machine?

If your compiler is 64 bit, then yes, you need 64 bit debugger. The debugger needs to be synchronized with your developed application not with your OS.
I am also running Windows 64 bit, however, I am using GCC/TDM-32bit so I need a 32 bit debugger

Are the pretty printing functions contained within the debugger I installed on Windows or are they part of Codelite?

No. codelite simplifies the pretty-printing for you by adding the 'startup commands' for you and it also installs the python scripts for you.
Other than that, all the pretty printing is done by the python script ( you can probably search and find an updated version for the script on the web )

Eran