User forums > Using Code::Blocks
see content of a vector in debugging
mgpensar:
--- Quote from: drac on September 21, 2009, 09:29:18 am ---You might find this blog entry interesting. It's about STL Visualisation from one of the KDevelop developers.
--- End quote ---
Thank you for the post drac, very informative. It seems that nice visualization of STL containers is finally taking its first steps to become wide available.
ollydbg:
--- Quote from: ollydbg on June 07, 2009, 10:43:26 am ---Thanks Jens for your hints.
Here is a workaround.
--- Code: ---#include <iostream>
#include <string>
#include <vector>
using namespace std;
typedef vector<string> vstr;
int main()
{
vstr v;
v.push_back("bla bla");
string v0 = v[0];
cout << "Hello world!" << endl;
return 0;
}
I can only watch "v0" (see the screen shot)
--- End code ---
--- End quote ---
hello, I found in the latest svn rev 5826, the debugger watch works badly with the test code above. see my screen shot. can someone find the bug? Thanks.
oBFusCATed:
I think, this is known bug... will look at it tonight
Update: yes known bug...
Here is the output of the whatis command:
--- Code: ---> whatis v_str
type = std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >,std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >
--- End code ---
And this line matches the regexp for std::string and so the script for std::string is used instead of the one for the vector.
Here is a patch that fixes the problem (not tested extensively)
--- Code: ---
Index: src/plugins/debuggergdb/gdb_commands.h
===================================================================
--- src/plugins/debuggergdb/gdb_commands.h (revision 5826)
+++ src/plugins/debuggergdb/gdb_commands.h (working copy)
@@ -702,6 +702,8 @@
m_watch->GetSymbol(symbol);
m_watch->GetType(type);
+ type.Trim(true);
+ type.Trim(false);
m_Cmd = static_cast<GDB_driver*>(m_pDriver)->GetScriptedTypeCommand(type, m_ParseFunc);
if (m_Cmd.IsEmpty())
{
@@ -798,7 +800,7 @@
// m_pWatch(watch)
m_watch(watch)
{
- m_Cmd << _T("whatis ");
+ m_Cmd << _T("whatis &");
// m_Cmd << m_pWatch->keyword;
wxString symbol;
m_watch->GetSymbol(symbol);
@@ -813,6 +815,7 @@
// type = bool
wxString tmp = output.AfterFirst(_T('='));
+ tmp = tmp.substr(0, tmp.length() - 1);
// actually add this watch with high priority
// m_pDriver->QueueCommand(new GdbCmd_Watch(m_pDriver, m_pDTree, m_pWatch, tmp), DebuggerDriver::High);
wxString old_type;
@@ -850,6 +853,8 @@
m_Type(w_type),
m_Address(address)
{
+ m_Type.Trim(true);
+ m_Type.Trim(false);
m_Cmd = static_cast<GDB_driver*>(m_pDriver)->GetScriptedTypeCommand(w_type, m_ParseFunc);
if (m_Cmd.IsEmpty())
{
Index: src/scripts/gdb_types.script
===================================================================
--- src/scripts/gdb_types.script (revision 5826)
+++ src/scripts/gdb_types.script (working copy)
@@ -24,7 +24,7 @@
// STL String
driver.RegisterType(
_T("STL String"),
- _T("[^[:alnum:]_]*string[^[:alnum:]_]*"),
+ _T("^std::basic_string<.*>$"),
_T("Evaluate_StlString"),
_T("Parse_StlString")
);
@@ -32,7 +32,7 @@
// STL Vector
driver.RegisterType(
_T("STL Vector"),
- _T("[^[:alnum:]_]*vector<.*"),
+ _T("^std::vector<(.*)>$"),
_T("Evaluate_StlVector"),
_T("Parse_StlVector")
);
--- End code ---
The patch includes a fix for another problem:
--- Code: ---> whatis gdb_type
Attempt to take contents of a non-pointer value.
>>>>>>cb_gdb:
> whatis &gdb_type
type = const wxString &*
>>>>>>cb_gdb:
--- End code ---
That thing is caused by the command "source stl-views-1.0.3.script", and unfortunately, I've not reported it to gdb upstream, will do so someday...
The patch evaluates the type of the address of the watched variable and then strips the * at the end of the result.
Testing is welcome.
p.s. the patch is agains the wxpropgrid_debugger branch, if you have problems applying it, I'll produce one against trunk
ollydbg:
@oBFusCATed
Thanks, but the patch failed appling in the trunk code :(. Would you supply a patch for the trunk?
MortenMacFly:
--- Quote from: ollydbg on October 02, 2009, 06:26:31 am ---Thanks, but the patch failed appling in the trunk code :(. Would you supply a patch for the trunk?
--- End quote ---
I believe it's for the debugging branch.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version