Sorry, can't get it to work.
I can not watch wxString in the dbg debugger output. In Locals I see the variable name of my wxString, but the column with the content stays empty. wxRect remains empty as well.
I am runnig Win7, x64 and I am using wxWidgets 2.9.3(which is unicode only), C::B 15.12. The project and all libs are 32bit.
Thats was the procedure:
1. Installed Installer V15.12. with MinGw (yield V4.9.2). Moved MinGw to C:\MinGw for easier handling
2. downloaded http://qp-gcc.googlecode.com/files/stdcxx_and_wx_pythonscript.7z, unzipped in MinGw/Bin/*.*
3. In Settings/Debugger/gdb/Default/InitCommands added the follwing and checked Enable Watch scripts. Unchecked
"Disable startup scripts"
source C:\MinGW\bin\stl.gdb
source C:\MinGW\bin\wx.gdb
4. downloaded http://sourceforge.net/projects/gdbmingw/files/gdb2014-05-23.zip/download and unzipped into C:/MinGw/
5.downloaded python from https://www.python.org/ftp/python/2.7.6/python-2.7.6.msi and installed it (I noted that the modified gdb only needs a "python27.dll" which was installed by the Python x86 version, but not by the x64 version).
6. Changed the following 2 lines of the file C:/MinGw/bin/libwx/v28/printer.py
val['m_pchData'].string() => val['m_impl']['_M_dataplus']['_M_p'].string()
return self.val['m_pchData'].string() => return self.val['m_impl']['_M_dataplus']['_M_p'].string()
According to what I found that should do it? But what did I forget, since the result is unchanged.
Since the pyEnabled failed to work without that dll expect that the GDB is python enabled indeed and should work (I tried all other versions of PythonEnabled gbd's I could find with no difference). In the debug output I can see the string data in the _M_dataplus _M_p structure, so dbg is reading the value OK, but its not printed out.
Seems that pretty printing generally is off? I am really bad with scripting, so I have no clue what the thing is doing :-[
Looking at the debug log the init commans do not create any error or unusual output:
[debug]>C:\MinGW\bin\stl.gdb
C:\MinGW\bin\wx.gdb
[debug]>>>>>cb_gdb:>>>>>>cb_gdb:
I do not know how I can find out wether or not pretty printers are actually working at all. Maybe I do not have
a problem with wxString but pretty printing.
Solving that issue would really make my day :-* . I am struggeling with that issue for ages and never got it really stable.
Regards,
Tiger
PS. I also tried with the MinGw-W64 32bit install with no other result.
it says:
[debug]global pretty-printers
[debug] .*
[debug] bound
[debug]>>>>>>>>>>cb_gdb:
Hm. Seems to mean that the pretty printers are working, right?
The advice lead me to the solution.
In the debug log you can execute the command "info pretty-printer". It will show you some output or an error.
Thanks a lot, oFBfusCATed -> you made my day 8).
So the procedure I followed was correct.
It showed me that I had been looking at the wrong end. Most of the versions I tried actually were python
enabled and worked fine with pretty-printing itself. Just I did not recognise. The problem was in my
manual script change in "http://qp-gcc.googlecode.com/files/stdcxx_and_wx_pythonscript.7z". The change
itself was syntactically correct but obviously I used a TAB somewhere. I just learned that python seems
to be pretty allergic against tabs - quite a surprise. I remove any tabs and, voila, my wxString content
printouts were there, wether or not _T("..") or "..".
So I learned for my procedure :
- check if the gdb base is ok: Run debug, enter in its command line "info pretty-printer". If you get
' Undefined info command: "pretty-printer".', you need another gdb or python or you would'nt see
a wxString output.
- Enable Settings/Debugger/Full log and look at the line where the source commands are executed.
The OK output shoudl be '>>>>>>cb_gdb:>>>>>>cb_gdb:'
- Only if both is OK, start looking at the syntax in the scripts
Now, I have two more things:
1) am intertested in thoughts on the following approach:
I have to use different version of gcc in some cases. Thus I install my compilers not in the C::B directory
but on the same level as C::B itself. I found that seems to work for the debugger as well. I just did
the setup today and need to work a bit still to see any side effects. Maybe someone else is already
working with that setup.
The setup looks like this
C:/
CodeBlocks/
Gdb_wxUnicode/
bin/
libstdcxx/
libwx/
include/
share/
Gdb_beforeUnicode/
MinGw4.62/
MinGw5.3/
MinGw64bit
The gdb bin only has a gdb.exe and a gdbserver.exe and the printer scripts including their subdirs. I was a
bit surprised that it does not require more resources of the MinGw directory, but so far works fine. The very
nice thing is that I can switch between gdb setups by only editing the C::B/Settings/Debugger/Default/
ExecutablePath. I could install/deinstall MinGw without the need to touch gdb again.
Maybe I overlooked something?
2) I think it would be nice to have an updated Zip file with that fully working setup. A python enabled gdb
and the script files with the changes (but without python installer) for convenience of others (an myself
in the future) with a link it in the post. I do not have any cloud space and also wouldn't think its good
to put it somewhere where the link dies when the provide company decide its time to change their
business model. There are too many dead links to interesting stuff in other forums I use. If someone
is willing to help me finding a place where to put it I can offer to prepare the package with instructions.
Maybe there is even a newer python enabled gdb than 23.05.2014. I did not find any links or hints
to the pything enabled gdbs on the MinGw website, but I probably just missed then.
Cheers,
Tiger