User forums > Help
Can't see value of unicode strings while debugging
Ramazan Kartal:
Hi,
I think I found a solution. Could you please try the following:
1. Open the gdb_types.script file in "C:\Program Files\CodeBlocks\share\CodeBlocks\scripts". Your installation dir may be different so change the above path if necessary.
2. Find the function "Evaluate_wxString".
3. Now find the line containing:
local result = _T("output /c ") + a_str + oper + _T("c_str()[") + start + _T("]@");
And change it to:
local result = _T("output /c ") + a_str + oper + _T("m_pchData[") + start + _T("]@");
Note we are only changing "c_str()" to "m_pchData".
4. Now save this file, start debugging.
This worked for me, I hope it will work for you.
Regards,
Ramazan Kartal
marlo_nl:
Mandrav,
Thanks very much for your useful feedback.
I did not see a remark about the dependency on wxWidgets libraries in earlier threads.
--- Quote from: mandrav on November 04, 2007, 02:44:52 pm ---
--- Quote from: marlo on November 04, 2007, 12:33:05 pm ---- is the wxWidgets library used relevant (I’m currently using a static debug library: libwxmsw28ud.a)?
--- End quote ---
Yes. The linker strips code you never use from static libraries. In this case, wxString::c_str() is needed which you obviously don't use directly in your code (and so is being stripped off the resulting binary).
Evaluating wxStrings works fine with dll-based wx configurations because the aforementioned stripping does not take place.
--- End quote ---
Considering your remark above, can I translate this into a "general guideline" for wxWidgets debugging (gdb) within the CodeBlocks environment?
"For debugging it is strongly advised to use a Shared Debug version of wxWidgets library"
I can't recall having seen such a "guideline" in earlier readings.
In case the "guideline" above is valid then it might be useful (for other users) to document this guideline somewhere, for instance in:
http://wiki.codeblocks.org/index.php?title=Debugging_with_Code::Blocks
Ramazan Kartal,
I tried your suggestion and modified the "gdb_types.script" file.
I can confirm that changing the script-file has an influence on the behavior of wxString debugging within the CodeBlocks environment (with static wxWidgets debug library).
- It does not change the behavior of the "evaluate expression under cursor" CodeBlocks feature.
- It does change the behavior of a wxString variable added to the "Watch" window. If I select "Edit Watch" in the "right-click" pop-up menu of the Watch window and if I set the "Count" property to a non-zero value (even without the "watch as array" checkbox checked) I can recognize (part of) the actual string value during debugging.
Regards, Marlo
Ramazan Kartal:
Dear Marlo,
Could you please do the following:
1. Open the same gdb_types.script and find the same "Evaluate_wxString" function.
2. Locate and change the following line from this:
result = result + a_str + oper + _T("size()");
to this:
result = result + _T("((wxStringData*)") + a_str + oper + _T("m_pchData - 1)->nDataLength");
I hope this helps. If it works ok than I will propose a patch so that it will not be owerwritten with every nightly.
Regards,
Ramazan Kartal
marlo_nl:
Dear Ramazan Kartal,
I've changed the two lines in the gdb_types.script file as you suggested:
--- Quote from: Ramazan Kartal on November 04, 2007, 05:17:27 pm --- local result = _T("output /c ") + a_str + oper + _T("m_pchData[") + start + _T("]@");
--- End quote ---
--- Quote from: Ramazan Kartal on November 05, 2007, 03:52:09 pm --- result = result + _T("((wxStringData*)") + a_str + oper + _T("m_pchData - 1)->nDataLength");
--- End quote ---
I can confirm that this solves the wxString debug issue (when using the Static wxWidgets Debug library).
Both the "evaluate expression under cursor" CodeBlocks feature and the "Watch" window watching a wxString variable now operate as desired.
Thanks a lot for your help.
Please do propose the patch so that other users can also benefit from your work in case they use a Static wxWidgets Debug Library (maybe for no good or specific reason, just like me) in their CodeBlocks environment.
I'm still intrigued by Mandrav's remark about using a Static Debug Library and code stripping by the linker.
Can we better make use of Shared Debug Libraries for debugging, or is it fair to expect same behavior during debugging when we use Static Debug Libraries?
Remark: In the past I've used the MSVC environment and I can't recall seeing different behavior when debugging projects using Static or Shared MFC libraries.
Regards, Marlo
mandrav:
--- Quote ---Remark: In the past I've used the MSVC environment and I can't recall seeing different behavior when debugging projects using Static or Shared MFC libraries.
--- End quote ---
Ramazan's solution works and is even ok for wxString. But this can't be said about other libraries, especially STL. Its implementation is vendor specific and in order to access a container's contents we must use library exposed functions (if we want to be portable), like c_str() for strings.
While wxString does indeed have a m_pchData data member (from which we can directly read the string's value), the same can't be said about STL's std::string (or other STL containers)... Each vendor has a different implementation and accessing a data member just isn't gonna cut it for us. This is the major reason why we use the c_str() function for STL string too.
MSVC on the other hand, has no such issues: everything there is provided by the same vendor and so compatibility is a given between the libraries and the environment.
Now you see why C::B's multiple compiler support is both a blessing and a curse :).
--- Quote ---Can we better make use of Shared Debug Libraries for debugging, or is it fair to expect same behavior during debugging when we use Static Debug Libraries?
--- End quote ---
My suggestion is to use DLLs for debugging, not only for issues similar to the one you 're experiencing: if you work on an above-average sized project, DLLs will save you also because of the significantly smaller linking times.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version